RFID RFC

RFID

Status:	unknown
Sponsored by:	Oslo Public Library
Developed by:	Benjamin, Magnus and Petter
Expected for:	2014-05-01
Bug number:	Bug 11858
Work in progress repository:	https://github.com/digibib
Description:	Add support for using RFID-equipment in circulation situations. We're not talking about self-checkin/checkout machines, which are allready supported throught SIP, but rather support for using RFID-readers instead of barcode-scanners in Koha's intranet webpages. Use cases Checkin/checkout an item, or several items at a time Turn on/off alarms on items Write information to RFID-tags (typically when registering a new item) Problem space The circulation workflows in Koha's intranet interface is currently like this: User scans a barcode Submit html form with the request Koha processes the request Page is reloaded/redirected with result of request presented This is not a good fit for a RFID-based circulation workflow. Rather, as we are used to it in our current ILS, we want immediate feedback upon putting one or more items on the RFID-reader, whether the transaction(s) was successfull or not. Protocols & Standards The main challenge will be to design APIs & protocols which can be used with different RFID equipment and the software/drivers used to interact with the hardware. There are at least 3 levels of protocols/APIs which are needed for our purpose: 1) RFID-tag standard This describes what information and how it is written on the actual RFID-tag. We are using what is known as the Danish standard (http://biblstandard.dk/rfid/dk/RFID_Data_Model_for_Libraries_July_2005.pdf). As far as we can find out, a very similar standard is used in UK & US as well. This is quite low-level stuff, and I dont think we have to deal with it directly, unless we are writing our own drivers for the RFID-readers. Typically, the vendors supply some software which can be used to interact with the reader, which brings us to the next level: 2) RFID-communicatinos-software (driver) This level describes the communications with the RFID-reader. Ours work like this: The vendor has made a server which runs locally on the PC. This server accepts commands through a simple line-based protocol (i.e, like SIP). With this we can command the reader to start scanning, and it will return any tag-IDs if found. Then we can send commands to turn off/on alarm etc. We only have experience from one vendor (but the software works with several different RFID-readers), so we can't guarantee this is the only way to do it. If anyone does it differently we'd love to know. 3) Koha-RFIDhub communications protocol This is the high-level API we can define ourself, which will describe how Koha can send requests to the RFID-readers. Purposed solution The solution we are making includes several components: Each staff PC (client) has RFID-reader/writer connected. This typically communicates via a vendor-specific protocol which we do not control. The browser cannot access this protocol off course, as it has no rights to access localhost. Therefore we need a proxy to run on client, to forward all communications to and from the RFID-hub on the server. To identify any specific RFID-reader, we use the clients IP-address. This the only identifier common to both the webbrowser and the RFID-hub (through the TCP connection from the proxy). The RFID-hub is the main part in this solution. It will accept websoccket-connections from Koha's intranet interface, and runn a state-machine for each connection. It will handle requests from RFID-unit and generate SIP-requests and relay the information back to the UI. The RFID-hub is an independent server which doesn't touch Koha, but only communicates with the SIP-server. The communications from the hub to Koha's interface is through websocket, so we can easily inject the javascript code into the relevant pages. A major obstacle to creating an generic solution for any kind of RFID-equipment is that the protocol to communicate with the RFID-unit is vendor specific. There is no standard. A proposal is to create a standard API which we can translate into the vendor-specific one. This typically needs just a few commands: Read Tag, Write tag,, etc.. We realize that our needs are different than other libraries, which only use barcodes, possibly in addition to self-checkin machines, with or without RFID. However, in order to create a generic solution that can serve other libraries with other needs & different equipment, now or in the future, we want to gather as much feedback as we can on this. Any critique or input is most welcome.