**5. Networked RFID testbed**

To study the internetworking of objects with passive RFID tags, a simple testbed has been built. The approach makes use of an RFID reader and an application that works as a proxy for the tags we wish to communicate with. The proxy is capable of making a virtual representation of the passive RFID tag on the Internet by creating a Virtual Net‐ work Interface (VNI) with an IPv6 address that can be attributed to each tag that comes within the electric field of a reader. Hence, the tags do not terminate IPv6 traffic directly but merely communicate with an entity which represents the tag (physical object) that we wish to communicate with.

The approach taken is software-oriented. The application runs as standalone but it can be embedded on the reader or it can be run on a computer local to the reader. The application receives the EPC of a tag attached to a physical object via the reader. The application then creates an IPv6 address from one of the mentioned methods. Hereafter, it is possible to route IP traffic to the particular Internet end-point. This will in effect make the application act as a proxy that for example can keep the most recently read tags "online". The solution gives a one-to-one mapping of physical objects to the virtual representations that are needed to communicate over the Internet.

Figure 6 illustrates the system implemented. In practice, the application host has a predeter‐ mined number of Virtual Network Interfaces (VNIs) installed. These interfaces work as the online virtual representation of the tag swiped at the reader. In other words, this is the inter‐ face the outside world can contact. In the testbed, the network interfaces are virtualized in a way similar to a loopback interface [17]. As the system works as a testbed the database is merely there as a logging service. In the future, it is planned to use the database as founda‐ tion for a local ONS. The corresponding node is there to illustrate possible communication over the Internet.

Each of the cases tagged will be given a unique IPv6 address when they enter the electric field of a reader. This process involves the extracting of the essential bitstring of the SGTIN identifier for each case. Likewise, the returnable pallet and the shipment as a whole will be given IPv6 addresses that can be built based on the GRAI and the SSCC, respectively. By using the assigned IPv6 unicast addresses it is possible to establish communication to indi‐ vidual cases as well as the pallet. However, it may be of less interest to address individual cases at this point in the supply chain but rather to address the ensemble of cases. By intro‐ ducing multicasting at the network layer it can be possible to communicate with groups of

Because moving objects can easily carry RFID tags, a common use is to track the movement of people and the information associated with them. By associating a particular tag's EPC with a global network address the task of tracking the object/asset become equivalent to lo‐ cating a mobile host in the network. In general, this is a key challenge in mobility research and several solutions have been proposed [22][26], and this will be the subject of our discus‐ sion in Section 7. Another interesting use case can be applied to sensor-tags. When these

To study the internetworking of objects with passive RFID tags, a simple testbed has been built. The approach makes use of an RFID reader and an application that works as a proxy for the tags we wish to communicate with. The proxy is capable of making a virtual representation of the passive RFID tag on the Internet by creating a Virtual Net‐ work Interface (VNI) with an IPv6 address that can be attributed to each tag that comes within the electric field of a reader. Hence, the tags do not terminate IPv6 traffic directly but merely communicate with an entity which represents the tag (physical object) that

The approach taken is software-oriented. The application runs as standalone but it can be embedded on the reader or it can be run on a computer local to the reader. The application receives the EPC of a tag attached to a physical object via the reader. The application then creates an IPv6 address from one of the mentioned methods. Hereafter, it is possible to route IP traffic to the particular Internet end-point. This will in effect make the application act as a proxy that for example can keep the most recently read tags "online". The solution gives a one-to-one mapping of physical objects to the virtual representations that are needed to

Figure 6 illustrates the system implemented. In practice, the application host has a predeter‐ mined number of Virtual Network Interfaces (VNIs) installed. These interfaces work as the online virtual representation of the tag swiped at the reader. In other words, this is the inter‐ face the outside world can contact. In the testbed, the network interfaces are virtualized in a

sensor-tags connect to a network sensor data can be retrieved from the tag.

cases on the pallet.

**4.3. Object/asset tracking**

122 Radio Frequency Identification from System to Applications

**5. Networked RFID testbed**

we wish to communicate with.

communicate over the Internet.

**Figure 6.** Simple setup to give RFID tags virtual identification on the Internet. A RedBee RFID Reader v1.1 is used. The application is built on the Microsoft® .NET connection software.

Figure 7 shows a state machine diagram for a single VNI resulting from a tag swiped in an access control application.

When the tag is swiped at the reader, the application host creates an IPv6 address by com‐ bining the network prefix configured at the reader with the tags identity as illustrated by the Example in Table 1. In the initial state, the software is waiting for a TagSwipe event to occur. Subsequently, the interface is put online with the address constructed, and it is kept alive as long the *expiration time* is greater than 0 (zero) seconds.

Tags are only reachable while they are within reader range. This makes it hard to communi‐ cate with the real tag, simply because it is only reachable for a short duration of time. When the tag's attachment to the network is virtualized it is possible to set up an expiration value. This value effectively serves as the time the tags virtual representation on the network can be reached.

The tag identity together with the constructed IPv6 address and a timestamp is stored on the database. Table 1 shows an example of the steps taken to construct an IPv6 address from an EM4100 tag ID.

in the multicast group e.g., a particular logical area. Details on how to operate an RFID in

In this Section we will discuss different methods of mapping between an RFID namespace

The most simple approach to find IPv6 addresses for tags is the mapping of the tag ID to an IPv6 address, i.e., the bits from the ID are used to form the IP address [14]. As different pas‐ sive RFID standards exist there is no common ID structure for tags. Even within standards, there are different types of IDs with different structures. This means, that a general concept

Table 2 shows a list of some commonly encountered passive tags and their ID formats.

HF (13,56 MHz) 64 bytes to 4096

HF (13,56 MHz) 128 bytes to 4096

**IC type Frequency band Memory Standards compliance**

EM4100 series LF (125 KHz) 64 bits EM4100. Proprietary standard issued by EM

EM4450/4550 LF (125 KHz) 1024 bits EM4450/4550. Proprietary standard issued

bytes 2K/4K/8K

bytes

An EPC with the length of 64 bits maps well in the IPv6 address format and can result in globally unique addresses. With longer EPCs it is impossible to map the EPC directly into the IPv6 address space and here specialized functions are needed. One solution would be to

LF (125 KHz) 256 bit to 2048 bit IEC/ISO 18000-2 (Hitag μ) [20].

Microelectronics [28].

Integrating RFID with IP Host Identities http://dx.doi.org/10.5772/53525 125

by EM Microelectronics [29].

ISO 14443A [18].

IEC/ISO 15693 [19] (ATC128, ATC256, ATC1024), IEC/ISO 14443 A [18] (ATC 2048, ATC 4096).

[20].

2048 bit ISO18000-4 and 18000-6B [20].

512 bit EPCglobal class 1 gen2 and ISO 18000-6C

IPv6 multicast networks are beyond the scope of this chapter.

**6. Strategies for interworking IPv6 with RFID tags**

to map tag IDs to IPv6 addresses will not work.

NXP UCode HSL UHF (868 MHz or 915

NXP UCode EPC Gen2 UHF (868 MHz or 915

**Table 2.** Common passive RFID tag and their characteristics.

MHz)

MHz)

and an Internet namespace.

**6.1. Address mappings**

NXP Hitag family (Hitag 1, Hitag 2, Hitag S, Hitag μ)

NXP Mifare family (Ultralight/ MF1S20/MF1S50/MF1S70/ DESFire EV1)

LEGIC Advant family (ATC128, ATC256, ATC1024, ATC2048, ATC4096)

**Figure 7.** State machine for the virtual interface resulting from a TagSwipe event at the reader.


**Table 1.** Example of IPv6 network address construction from on EM4100 tag ID.

The application has no visual interface and all configurations must be done in software. For example, it is possible to use more than one virtual interface to represent the tags online. These interfaces need to be preinstalled, as already mentioned, and some parameters in the application need to be configured. Hereafter, it is possible to make use of at least 5 virtual interfaces.

Although focus is on the assignment of IPv6 unicast addresses, tags can also be assigned to become member of multicast groups thereby facilitating one-to-many communication. As an example an application may want to address all tags at a particular reader. Likewise, read‐ ers can become members of multicast groups hereby enabling communication to all readers in the multicast group e.g., a particular logical area. Details on how to operate an RFID in IPv6 multicast networks are beyond the scope of this chapter.
