Comparison of the RFID-based architectural patterns (italic values signal a limit for this architectural pattern)
1. Introduction
RFID provides a way to connect the real world to the virtual world. An RFID tag can link a physical entity like a location, an object, a plant, an animal, or a human being to its avatar which belongs to a global information system. For instance, let's consider the case of an RFID tag attached to a tree. The tree is the physical entity. Its avatar can contain the type of the tree, the size of its trunk, and the list of actions a gardener took on it.
When designing an RFID-based application, a system architect must choose between three locations to store the information: a centralized database, a database locally attached to the device hold by each user of the application, or the tag itself. Each location leads to an RFID-based architectural pattern . An. architectural. pattern. is. a. description. of. element. and. relation. types. together. with. a. set. of. constraints. on. how. they. may. be. used. [1].
The state of the art does not bring satisfactory answers. Indeed, when an article describes a RFID-based architectural pattern, it does not mention the application attributes which lead to choose this architectural pattern. On the other hand, some books or articles present the qualities of architectural patterns. But they do not take into account specificities of RFID. For instance, EPCglobal provides a standardized answer [2]: the centralized architectural pattern. A mobile device, NFC-enabled for example, reads an identifier on the RFID tag, then sends a message to a server which associates the identifier to the avatar stored in a central database. Thanks to its simplicity, this architectural pattern is used by several applications. But, it requires a global computer network: Such requirement increases operational costs. Moreover, it does not withstand an important number of simultaneous RFID read operations. Thus this pattern does not fit all RFID-based applications. [3] presents the stakes of introducing RFIDs inside an enterprise. But it does not contain any system architecture thoughts. In a survey about RFID in pervasive computing, [4] presents several application examples. Depending on the application, avatars are stored either in a central database or in the tags themselves. But the authors do not give any clues on why an application has chosen to store its avatars in a given location. On the other hand, [1] lists the attributes which must be accommodated in a system architecture. Above all, there are the functionalities which are required from the system. Then, orthogonal to these functionality attributes, there are quality attributes. The authors distinguish system quality attributes (availability, modifiability, performance, scalability, security, testability, and usability), business qualities (time to market, cost and benefits, and projected lifetime), and qualities about the architecture itself (e.g. conceptual integrity). But the authors do not focus on RFID specific features.
So we have analyzed several existing industrial or experimental RFID-based applications. Moreover, we have developed RFID-based applications. From this experience, we identify the relevant attributes to compare RFID-based architectural patterns. We present them in section 2. With these identified attributes and their different aspects, we analyze four RFID-based architectural patterns, used by applications to access the avatar of a tagged entity. In the
2. Architecture attributes and RFID technology
Relying on the experience gained by analyzing existing RFID-based applications and by developing RFID-based applications, we outline three architecture attributes among the attributes presented in [1]: (i) functionality, (ii) scalability, and (iii) cost. For each attribute, we present its different aspects which are influenced by the use of RFID technology.
2.1. Functionality attribute
Functionality is the ability of the system to do the work for which it was intended.
All architectural patterns give the ability to read/write the avatar of a read tag.
A first aspect of the functionality attribute is to check how the application behaves when it queries the avatar of a read tag. Is it guaranteed that the returned avatar has indeed the value which was last written? In other words, is there a staleness issue of avatar of a read tag?
The second aspect concerns the possibility of knowing the value (or having an order of idea of the value) of the avatar of a remote tag. By “remote”, we mean that the user is not physically near the tag: The user is not able to put her reader on the tag. All she has is the identifier of the remote tag.
The third aspect is the staleness issue of the avatar of a remote tag. If the user is able to know the avatar of a remote tag, is it guaranteed that the returned avatar has indeed the last values associated to the tag?
2.2. Scalability attribute
The scalability criteria category evaluates how each architectural pattern behaves when there are numerous tags or numerous readers.
Its first aspect is the maximum number of tags which can be handled by the architectural pattern.
The second aspect characterizes the sensitivity of the architectural pattern to the number of simultaneous RFID tag read operations.
2.3. Cost attribute
The cost attribute groups all of the aspects which have an influence on the installation costs or the operational costs of the RFID-based application.
The first cost aspect concerns the requirement for a global network: do RFID readers have to be able to access at any time and any place to a specific computing machine (for instance, a server in the case of the centralized architectural pattern)? To fulfill this requirement, the readers may be equipped with a wired connection. In that case, the mobility of the readers is limited. The readers may also rely on Bluetooth® or Wi-Fi gateways. Both of these gateways may introduce installation costs. Moreover some readers may not be Wi-Fi enabled. For instance, the Nokia 6212 mobile phone is NFC-enabled, but has no Wi-Fi capabilities. Finally the reader may rely on a mobile data connection (e.g. UMTS, HSDPA, etc.). Such solution introduces operational costs because of data plans.
The second cost aspect concerns the RAM requirement on each tag. The more RAM there is on the tag, the more expensive the tag is. Notice that RAM may actually be prohibited on tags for technical reasons and not for cost reasons. For instance, application may require the use of low-frequency tags (e.g. 125 kHz), so that readers can interact with tags even though there is a liquid between tags and readers. In this case, the throughput is too low for a tag to host information other than its identifier.
The third cost aspect concerns the introduction of a new tag in the environment. For each architectural pattern, we determine the sequence of operations which is required in order to introduce a new tag in the environment. Knowing this sequence, we can determine how long this sequence lasts. Because this initialization procedure is executed by a human or a robot operator, its cost is proportional to the time spent.
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 of each session, all of the tags must be reinitialized.
In this section, we have defined different aspects of three architecture attributes: (i) functionality, (ii) scalability, and (iii) cost. These aspects are influenced by the use of RFID technology. We use them to compare the behavior of four RFID-based architectural patterns. We start by analyzing centralized architectural pattern.
3. Centralized architectural pattern
This architectural pattern is often used by manufacturing applications. It has been standardized 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 Figure 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 identifier of the tag. The machine queries its database and returns the avatar (for instance, the contents of the hexagon in the database in Figure 1).
Next section gives examples of this architectural pattern.
3.1. Examples
Aspire RFID is an Open Source middleware which is compliant to the specifications of EPCglobal [8]. It proposes several examples of industrial applications for tracking goods.
Next paragraphs present products or prototypes developed according to centralized architectural pattern, but without being compliant to EPCglobal.
[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.
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 central database. Let
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 other hand, this architectural pattern only needs to read an identifier on the tag. And this identifier 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 database. It sets each avatar to its new value.
This section has analyzed centralized architectural pattern according to the attributes presented 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 requirement for a global computer network and reduces sensitivity to the number of simultaneous reads.
4. Semi-distributed architectural pattern
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 propagated to the central database at the next synchronization.
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 application [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.
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
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 central database and in the local copy of this database. Let
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 reinitialized, 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.
5. Distributed architectural pattern
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.
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
In fact, it is thanks to this Smart Posters specification that any NFC phone can exploit Touchatag 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
Once again, it is the Smart Posters specification which is used by
[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
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.
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 mechanisms take into account elapsed time in order to automatically reset data. In Roboswarm application (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 deterioration 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 presented 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-distributed 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 application 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 corresponding to the last version of the avatar which the tag or the device has learnt about (this is why [25] gives the name
Next section presents an example of this architectural pattern.
6.1. Example
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 stored on the tag, the value read on the tag is the most up-to-date. Or, the tag has not been already 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
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 required 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 avatar 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
When tags must be reinitialized, a program
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 network. 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 experiences 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.
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.
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 aspects 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.
Staleness of locally read tag | No |
|
No | No |
Avatar of remote tag | Yes | Yes |
|
Yes |
Staleness of remote read tag | No |
|
n.a. |
|
Maximum number of tags | Scentral/s | Slocal/s | Infinite |
|
Sensitivity to number of simultaneous reads |
|
Medium | None | Medium |
Network required |
|
No | No | No |
RAM required on tag | No | No |
|
|
Cost of introducing a tag (most costly operation) | Link tag to physical entity | Link tag to physical entity | Link tag to physical entity | Link tag to physical entity |
Cost of reinit. Tags (most costly operation) | Reinit. Database | Sync. Database |
|
Sync. database |
If one of these last two issues is a problem, the system architect must consider the three other 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 constraints (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 compatible 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 RFID-based 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).
To illustrate the use of these guidelines, let’s consider the choice of the architectural pattern for the RFID-based game
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,
This field is coded as a short (
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 (
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 architectural pattern.
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 RFID-based DSM can handle a maximum of 248 tags (as
8. Conclusion and future work
This chapter studies four RFID-based architectural patterns: centralized, semi-distributed, distributed and RFID-based DSM. It compares them according to nine aspects of three architecture attributes: functionality, scalability and cost. Despite their specific limitations, each architectural pattern fits the requirements of existing applications.
Maximum number of tags if s=1 byte (s=250 bytes) | 500 x 109 (2 x 109) |
109 (4 x 106) |
Infinite (Infinite) |
248 (2) |
Cost of computer network (per month) |
|
0 euro | 0 euro | 0 euro |
Cost of tag (per tag) | 0.10 euro | 0.10 euro |
|
|
Cost of introducing a tag (in seconds per tag) | 80 s/tag | 80 s/tag | 80 s/tag | 80 s/tag |
Cost of reinitializing tags (in seconds per tag) | 0 s/tag | 4 s/tag |
|
4 s/tag |
The chapter proposes guidelines for choosing the RFID-based architectural pattern which will best fit a given application requirements. These guidelines are tested in the context of an RFID-based pervasive game.
Future work concerns the analysis of these architectural patterns with respect to security architecture attribute. Security is a measure of the system’s ability to resist unauthorized usage while still providing its services to legitimate users [1]. This future work will determine the influence which the level of resistance to security attacks and the cost of implementing such resistance have on the guidelines provided in this paper. Another attribute we would like to study is the fault-tolerance of the different elements of the system.
References
- 1.
Bass L., Clements P., and Kazman R., Software Architecture in Practice, 2nd Edition. Addison-Wesley Professional, April 2003, ISBN-13: 978-0-321-15495-8. - 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 architecture framework,” GS1 EPCglobal, Tech. Rep. Version 1.2, September 2007. - 3.
Gonzalez L., RFID: Stakes for the enterprise! (in French). Afnor Editions, October 2008, ISBN-13 978-2-12-465153-5. - 4.
Roussos G. and Kostakos V., “RFID in pervasive computing: State-of-the-art and outlook,” Pervasive Mob. Comput., vol. 5, no. 1, pp. 110–131, February 2009. - 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 2012), December 2006. - 6.
“Smart Poster Record Type Definition, Technical specification SPR 1.1,” NFC Forum, 2006. - 7.
Simatic M., “RFID-based replicated distributed memory for mobile applications,” in Proceedings of the 1st International Conference on Mobile Computing, Applications, and Services (Mobicase 2009), San Diego, USA. ICST, October 2009. - 8.
Aspire RFID: OW2 Aspire RFID: an RFID suite for SMEs. Available at http://wiki.aspire.ow2.org (last access in July 2012), 2011. - 9.
Rashid O., Bamford W., Coulton P., Edwards R., and Scheible J., “PAC-LAN: mixed-reality gaming with RFID-enabled mobile phones,” Computers in Entertainment, vol. 4, no. 4, pp. 4–20, October–December 2006. - 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. Springer Berlin / Heidelberg. - 11.
Pellerin R., Adgeg G., Delpiano F., Gressier-Soudan E., and Simatic M., “Gasp : a middleware for mobile multiplayer games”. http://gasp.ow2.org (last access in July 2012), July 2007. - 12.
Pellerin R., Delpiano F., Duclos F., Gressier-Soudan E. and Simatic M. (2005) “Gasp : an open source gaming service middleware dedicated to multiplayer games for J2ME based mobile phones”. In 7th Int. Conference on Computer Games CGAMES'05 Proceedings, pages 75-82. - 13.
Heumer G., Gommlich F., Jung B. and Müller A. (2007). Via Mineralia - a pervasive museum exploration game. In Proc. of Pergames 2007, Salzburg, AT. - 14.
Touchatag: Using the Advanced HTTP Application. Available at http://www.touchatag.com/developer/docs/applications/advanced-HTTP (last access in July 2012), 2010 - 15.
Activision: Skylanders : Spyro's adventure. Available at http://www.skylanders.com/) (last access in July 2012), 2011. - 16.
Planck S.: Kids going crazy for Activision Skylanders NFC game. Available at http://www.nfcrumors.com/01-17-2012/kids-crazy-activision-skylanders-nfc/) (last access in July 2012), January 2012. - 17.
NFC Forum. NFC Data Exchange Format (NDEF) - Technical Specification 1.0. Rapport technique, NFC Forum. - 18.
NFC Forum (2006c). URI Record Type De?nition - Technical Specification 1.0. Rapport technique, NFC Forum. - 19.
Connecthings : 08/12/2011 - BAL intelligente @ mobulles Paris @ Lab Postal 2011 (Intelligent mailbox, in French). http://www.connecthings.com/node/123 (last access in July 2012), December 2011. - 20.
Levallois-Barth C., “Navigo: simplification or absolute traceability”. FYP éditions, May 2009, ch. 5 – Security and data protection, in Evolution of digital cultures (in French), pp. 173–181, ISBN-13 978-2-91-657113-3. - 21.
Couderc P. and Banâtre M., “Beyond RFID: The Ubiquitous Near-Field Distributed Memory,” ERCIM news, no. 76, pp. 35–36, January 2009. - 22.
Mamei M. and Zambonelli F. (2007). Pervasive pheromone-based interaction with RFID tags. ACM Trans. Auton. Adapt. Syst., 2(2):4. - 23.
Zecca G., Couderc, P., Banâtre M. et Beraldi R. (2009). « Swarm robot synchronization using RFID tags. In Pervasive Computing and Communications,” 2009. PerCom 2009. IEEE International Conference on, pages 1-4. - 24.
SALTO Systems: SALTO Networked Locking System - SVN. Available at http://www.saltosystems.com/index.php?option=com_content&task=view&id=62&Itemid=57) (last access in July 2012), 2007. - 25.
Murphy A. L. and Picco G., “Using LIME to Support Replication for Availability in Mobile Ad Hoc Networks,” in Proceedings of the 8th International Conference on Coordination Models and Languages (COORD06), vol. 4038, Bologna, Italy. Springer Lecture Notes on Computer Science, June 2006, pp. 194–211. - 26.
Simatic M., Astic I., Aunis C., Gentes A., Guyot-Mbodji A., Jutant C., and Zaza E., “’Plug: Secrets of the Museum’: A pervasive game taking place in a museum,” in Entertainment Computing - ICEC 2009, Eighth International Conference, Paris, France, September 3-5, 2009, Proceedings, ser. Lecture Notes in Computer Science. Springer, September 2009, pp. 302–303. - 27.
“PLUG: Play Ubiquitous Games and play more,” http://cedric.cnam.fr/PLUG/ (last access in July 2012), August 2009.
Notes
- . An. architectural. pattern. is. a. description. of. element. and. relation. types. together. with. a. set. of. constraints. on. how. they. may. be. used. [1].