Ubiquitous ID Center Activities
At Nihon Unisys Ltd., as one part of the T-Engine Forum's activities, we have developed a ucode resolution server based on the Ubiquitous Code Resolution Protocol (ucodeRP) and the Entity Transfer Protocol (eTP). In August 2003, with eTP and ucodeRP as targets, we carried out connection tests in which they mutually exchanged messages. Below, centering on the development of the ucode resolution server and the connection tests, I will introduce our activities in the T-Engine Forum.
Before we enter into a discussion of the ucode resolution server, I would like to first touch on the Ubiquitous ID technology architecture. This is already well known through T-Engine Forum explanatory meetings and various seminars, but in Fig. 1, I show the Ubiquitous ID technology architecture. Ubiquitous ID technology is composed of the following devices and servers.
 |
|
|
At the Ubiquitous ID Center, they call a unique ID they assign to a "thing" a ucode; the data carrier device that stores this ucode is an ID tag. As for ID tag devices, beginning with Radio Frequency Identification (RFID), smart cards, active chips, IC cards, barcodes, etc., are inclusively handled.
The Ubiquitous Communicator is a device for realizing communication between a ubiquitous computing environment and a user. In the Ubiquitous Communicator, we install wireless communication functions for reading in ucodes assigned to ID tags and reading in the memory contents of writeable ID tags, plus wide area communications functions for receiving information and services concerning "things" from servers that exist on networks. As for wide area communications functions, wireless LAN, PHS, Bluetooth, etc., are targeted.
Generally speaking, two methods are under consideration at the Ubiquitous ID Center for providing information concerning "things." One is a method to provide information by writing it into the memory of ID tags pasted onto "things," and the other is a method to provide information via servers that exist on networks. For example, one can conceive of information on the size, color, material, etc., if it's clothing; and information on best if eaten by this date, the producer, etc., if it's foodstuffs. We call a server that provides information on "things" in this manner a product information service server. Furthermore, we call a server for inquiring as to where a product information service server is a ucode resolution server.
I would now like to look into the workings of a ucode resolution server in a little more detail. A Ubiquitous Communicator that has read in a ucode from an ID tag inquires to a ucode resolution server as to the address of the product information service server that provides information concerning that ucode. The ucode resolution server in regard to that inquiry returns to the Ubiquitous Communicator the address (IP address, URL, telephone number, etc.) of the product information service server. The Ubiquitous Communicator then uses that address to access the product information service server, from which it obtains information about the "thing." The ucode resolution server, if we liken things to the Internet, plays a role along the lines of a Domain Name System (DNS).
In the future, when it comes about that ucodes are assigned to very large numbers of "things," vast numbers of inquiries will be sent to a ucode resolution server, and it will become difficult to respond to all requests with a single ucode resolution server. In order to cope with this kind of situation, at the Ubiquitous ID Center, we are considering a scheme in which we arrange ucode resolution servers hierarchically and manage them in a distributed manner. To the end, this is an example for explanation, but if we take the JAN Code that is used with barcodes as an example, the Ubiquitous ID Center manages several upper bits for the purpose of identifying the code type called the JAN Code ([1] of Fig. 2), and then it transfers to the organization that manages the JAN Code the management of the bits below that. Further, the JAN Code management organization manages the next several bits ([2] of Fig. 2), and then it transfers to the maker that utilizes the JAN Code the management of the bits below that. Finally, by means of each maker assigning unique IDs to products ([3] of Fig. 2), it become possible to identify products one by one.
 |
|
|
When it comes about that ucode resolution servers are managed through a hierarchical structure in this manner, it will come about that a Ubiquitous Communicator, as in Fig. 2, will obtain the address of the end product information service server after making inquires to several ucode resolution servers. In other words, it will come about that the address a ucode resolution server returns to the Ubiquitous Communicator will not just be the address of product information service server, but rather there will also be cases where it is the address of the next ucode resolution server in the hierarchy.
Furthermore, at the Ubiquitous ID Center, in order to guarantee privacy information, we have made the utilization of the eTP encryption and authentication standard the rule in the exchange of messages. We implemented eTP and ensured security also in the ucode resolution server that we implemented on this occasion.
At Nihon Unisys, in the development of the ucode resolution server, we carried out development by dividing the system into four modules as in Fig. 3. By dividing the modules and putting them aside beforehand, we can carry out enhancements in the future without influencing other modules through the substitution of modules. Below, I shall take a look at the individual modules.
 |
|
|
Communication Module
In the ucode resolution server we implemented on this occasion, we used TCP/IP as the communications protocol. The main roles of the communication module are receiving request messages from the Ubiquitous Communicator (hereafter, I will call this the client for the sake of convenience) and sending reply messages to the client. In a case where one will use a communications protocol other than TCP/IP, this can be handled by creating a communication module compatible with that protocol and changing modules.
eTP Module
eTP is an encryption and authentication standard prescribed in the TRON Project. In carrying out communications with eTP, it is necessary to obtain a certificate issued by the eTRON authentication bureau and the eTRON ID individually assigned to a node. In eTP, we identify our communications opposite by means of the eTRON ID.
In the eTP specification, even such things as the method for handling the eTRON chip are prescribed in detail; in the ucode resolution server implemented on this occasion, we implemented functions for safely communicating mainly with the Ubiquitous Communicator.
|
|
| In carrying out the mutual hand over of data in eTP, it is necessary to first establish a session between the nodes. In establishing a session, we mutually exchange eTRON IDs and certificates and authenticate whether the communications opposite is a node that can be trusted. Also, at this time, we decide what type of encryption method we will send and receive the data with. | |
|
|
| Cutting off the session established by means of "eTP Session Establishment." | |
|
|
| In eTP, we necessarily encrypt and send messages. Also, we confirm whether the message has been falsified, and whether the message has been sent from the proper opposite. | |
|
|
| Among the devices that handle eTP, there exist devices that cannot send and receive large amounts of data at a single time. In order to cope with communications with these types of devices, we have installed a function that divides messages and carries out transmission and reception. | |
ucodeRP Module
In the ucodeRP module, we have implemented the following three processes that are prescribed in the Ubiquitous Code Resolution Protocol.
|
|
| This is a function that ties together and registers a ucode and the address of a server that provides information about that ucode. From the fact that a hierarchical structure of the type in Fig. 2 has been conceived, the "server that provides related information" is at times a product service server and at times a ucode resolution server. We utilize this registration function when someone pastes an ID tag on a "thing" and it has come about that we will provide information with a product information service server. | |
|
|
| This is a function that deletes information concerning a ucode. We utilize this function when someone tears off an ID tag from a "thing" and it has come about that we will not provide information with a product information service server. | |
|
|
| This provides the attributes of a server (product information service server, ucode resolution server) that provides information concerning a corresponding ucode. As for the attributes we return to the client, they are the server type (ucode resolution server, product information service server), the server address (IP address, URL, etc.), the communications protocols for accessing that server, etc. | |
DB Module
This provides interfaces for inserting into, modifying, searching, and deleting from a database. In the same manner as the communications module, it is made up so that changing can be easily done when utilizing a different database product by creating a DB module compatible with it.
Also, we have created test drivers in the manner of Fig. 3 so that we can carry out tests independently in our company's environment.
From July through August, we executed connection tests on four occasions. In the connection tests, we made communications between the Ubiquitous Communicator and the ucode resolution server in Fig. 1 the object, and we confirmed eTP and ucodeRP. We used test drivers and conducted tests by sending messages to the ucode resolution server.
In the first test, we confirmed eTP session establishment and cut-off. We then confirmed exchange of eTRON IDs and certificates up to the point where the same encryption key could be mutually generated. In particular, in establishing the session, because it was necessary to implement after understanding the specifications down to their details, we required a little time prior to conducting the connection tests. However, since the level of finish of the specifications was very high, it was possible to proceed with the connection tests without any big problems.
In the second test, we confirmed data encryption and decoding following session establishment. Because we had already been able to confirm the encryption key in the first test, we were able to smoothly confirm encryption and decoding processing.
In the third test, we confirmed the basic operations of ucode resolution. We confirmed the basic processes of ucodeRP registration, deletion, and resolution, plus such things as whether database processing was being carried out accurately.
In the third test, confirmation of the basic operations was generally completed, but in order to conduct further detailed tests, we thoroughly investigated test cases considered necessary from the ucodeRP specification. In the fourth test, we executed testing in accordance with these test cases. We were able to respectively carry out processing of registration, deletion, and resolution without problem.
We got the Ubiquitous ID Center to jointly issue a news release concerning these connection tests on August 7, 2003.
By means of actually utilizing a ucode resolution server through the ucode resolution server connection tests executed on this occasion and the verification trials planed for the future, we would like to thoroughly investigate various points for improvement and create feedback so that a ucodeRP specification of greater convenience will be completed.
Our thinking is that in the future we would like to contribute to the spread on Ubiquitous IDs by providing not just the ucode resolution servers, but business models and system construction services suited to a user's needs, including even such things as ID tags and Ubiquitous Communicators.
The above article on T-Engine appeared on pages 71-73 in Vol. 84 of TRONWARE . It was translated and loaded onto this Web page with the permission of Personal Media Corporation.
Copyright © 2003 Personal Media Corporation
Copyright © 2003 Sakamura Laboratory, University Museum, University of Tokyo