A large share of Indian college, university and public libraries run Koha, the open-source library management system, often on a modest server looked after by the library staff themselves or a small IT cell. When these libraries look at RFID, the first practical question is not “which tag?” but “will it work with our Koha?” This guide explains what an RFID library management system looks like when Koha is the LMS, how the hardware typically connects to Koha through the SIP2 protocol, how to choose between HF and UHF, how to convert an existing collection, and what a tender or specification should actually list.
For a solution-level overview, see our RFID library management system page; this post goes deeper into the integration side.
The RFID library stack, component by component
An RFID library deployment is a set of five or six pieces that share one identifier per book and one database: the LMS.
| Component | What it does | Typical form |
|---|---|---|
| Book tag | Carries a unique ID (and, on HF, a security bit) for each item | HF ISO 15693 label or UHF label, pasted inside the cover |
| Staff workstation pad | Reads a stack of books at the issue/return counter | Desktop HF or UHF pad reader connected to the circulation PC |
| Self-checkout kiosk | Lets patrons issue and return without staff | Touch-screen kiosk with reader, printer and often a card reader |
| EAS security gate | Detects un-issued books leaving the library | Gate at the exit, single or multi-lane |
| Handheld shelf-audit reader | Stock verification, mis-shelved item search | Android handheld with RFID module |
| Middleware / SIP2 | Connects kiosk and gate to Koha | Typically Koha’s built-in SIP2 server plus the vendor’s kiosk software |
Some libraries also add a book-drop (a return chute with a reader) and a patron card system, but the six items above are the core.
How the hardware talks to Koha: SIP2
Koha includes a SIP2 server in its standard distribution; it has to be enabled and configured by the administrator. SIP2 (Standard Interchange Protocol, version 2) is a plain-text, message-based protocol originally developed for self-check machines, and it has become the common language between library hardware and library software. In a typical setup:
- The Koha administrator enables the SIP server, creates a SIP account for each device (kiosk, gate, book-drop) and assigns it to a branch and a set of permissions.
- The self-checkout kiosk acts as a SIP2 client. When a patron scans a card, the kiosk sends a patron-information request; Koha replies with the patron’s status, blocks and fines. When books are placed on the pad, the kiosk sends a checkout message per item and Koha responds with success or a reason for refusal (item on hold, patron over limit, and so on).
- Returns work the same way in reverse using check-in messages.
- Item-information messages let a gate or handheld ask Koha whether a given ID is currently on loan.
Staff workstations usually do not need SIP2. The pad reader commonly feeds the barcode/tag ID straight into the Koha circulation screen (keyboard-wedge or a small browser helper), because Koha’s staff interface already handles the transaction. SIP2 matters most for the unattended devices: kiosks, gates and book-drops.
Two honest caveats. First, “SIP2-compatible” is a capability claim from both sides; every rollout still needs a configuration and testing phase against the library’s actual Koha version and circulation rules. Second, some newer integrations use Koha’s REST API instead of or alongside SIP2. Ask the vendor which route they propose and why. Identium supplies readers, tags and library hardware designed to integrate via SIP2 and standard library protocols; we do not claim a Koha-specific certification, and neither should any vendor, since Koha is community-maintained and, to our knowledge, does not run a formal certification programme.
Security: how the gate knows a book is not issued
The answer differs by frequency.
- HF (ISO 15693) library tags carry an AFI or EAS bit. At checkout the kiosk clears the bit; at return it sets it again. The gate simply looks for tags with the bit set and alarms, without consulting the database. This is why HF gates can keep working even if the network is down.
- UHF tags identify themselves by EPC. The gate either checks the EPC against a local list synced from Koha, or the kiosk writes a status flag into the tag’s user memory at checkout, which the gate reads. Both approaches are common; the first needs reliable connectivity, the second needs the kiosk software to write to the tag.
HF vs UHF for libraries
HF ISO 15693 has been the library standard for around two decades and remains the default for most Indian academic libraries. UHF has grown in popularity where bulk shelf reading and range matter more than the established ecosystem. Our UHF vs HF vs NFC explainer covers the physics; here is the library-specific view.
| Factor | HF (ISO 15693) | UHF (EPC Gen2) |
|---|---|---|
| Item-level tap on the pad | Very reliable, short-range by design | Works, but the pad must be shielded to avoid reading neighbouring books |
| Bulk shelf reading | Slower, near-contact | Fast, reads a shelf metre from a distance |
| Security gate | Built-in AFI/EAS bit, offline-capable | Database or user-memory flag |
| Standards and vendor ecosystem | Mature (ISO 28560 data model widely used) | Growing; standards exist but library adoption is less uniform |
| Tag cost at volume | Often a little higher per label | Often lower per label at scale |
| Reading through thick or wet materials | Tolerant | More sensitive to moisture and metal shelving |
A pragmatic rule of thumb: libraries prioritising self-service accuracy and an offline-safe gate lean HF; libraries with very large collections and frequent stock verification lean UHF. Both are legitimate. Identium manufactures HF ISO 15693 library labels and UHF library labels and tags, and offers HF readers and UHF handheld readers for shelf audits, so we can support either route rather than push one.
Converting an existing collection
Tagging is the largest labour item in most projects. A workable conversion workflow:
- Clean the catalogue first. Every physical item needs a Koha barcode/accession number. Items missing from the catalogue should be catalogued before tagging, not after.
- Choose the tag position. A consistent inside-cover position, varied slightly between adjacent books on the shelf, improves shelf-read reliability.
- Set up a conversion station. A PC with the Koha staff interface, a barcode scanner and an RFID pad. Scan the barcode, place the book, write the ID to the tag, and verify the read.
- Work section by section. Convert one range at a time so circulation can continue on barcodes for the remaining ranges.
- Verify with the handheld. After each section, walk the shelves and reconcile against Koha to catch missed or duplicate tags.
Throughput depends on staff, station count and book condition; plan for a pilot section before committing to a full timeline.
What a tender or specification should list
Vague specifications produce mismatched bids. A usable spec covers:
- Frequency (HF ISO 15693 or UHF EPC Gen2) and, for HF, the data model expected (ISO 28560 is common).
- Tag quantities, sizes and adhesive type, plus a small quantity of tags for CDs, DVDs and metal-bound items if held.
- Number of staff pads, kiosks, gate lanes and handhelds, with the physical width of each exit.
- An explicit statement that kiosks and gates must integrate with the library’s Koha version via SIP2 (or REST API), with a test-and-acceptance phase.
- Conversion scope: who tags, how many items, in what period.
- Warranty, spares, on-site training and SDK/source availability for readers.
- Certifications applicable to the hardware, such as BIS and, for UHF equipment, WPC approval for India’s delicensed 865-867 MHz band. See our BIS/WPC buyer’s guide.
Cost drivers
We do not publish rupee figures for full library systems, since the total swings on decisions the library controls. The main drivers, roughly in order of impact:
- Tags per book. Volume dominates: a 30,000-item college library and a 5 lakh-item university library are different projects. Per-label cost generally falls with quantity.
- Gate lanes. Each additional lane adds hardware; wide exits may need multiple gates.
- Kiosks. Kiosk count and features (receipt printer, card reader, touch size) drive cost more than the reader inside them.
- Integration and testing. SIP2 configuration, Koha tuning and acceptance testing are labour, not hardware.
- Conversion labour. Whether the vendor or library staff tag the collection.
- Handhelds. Usually one or two per library; a small share of the total.
For an idea of how tag pricing behaves, see our RFID tag price guide, then request a manufacturer quote against your actual item count.
Getting started
If your library runs Koha and you are weighing RFID, the sensible first step is a pilot: a few thousand items in one section, one staff pad, one kiosk configured against your SIP2 server, and a handheld for stock verification. That answers the HF-versus-UHF question and the integration question with real data before the tender goes out. Identium supports libraries and the wider education sector with library labels and tags, readers and gate hardware made in New Delhi, and self-checkout, EAS gate and shelf-audit solutions. Contact us with your collection size, Koha version and exit layout, and we can suggest a stack and a pilot scope.