WO2005114545A2 - Methods and devices for locating and provisioning rfid devices and related network devices - Google Patents

Methods and devices for locating and provisioning rfid devices and related network devices Download PDF

Info

Publication number
WO2005114545A2
WO2005114545A2 PCT/US2005/016484 US2005016484W WO2005114545A2 WO 2005114545 A2 WO2005114545 A2 WO 2005114545A2 US 2005016484 W US2005016484 W US 2005016484W WO 2005114545 A2 WO2005114545 A2 WO 2005114545A2
Authority
WO
WIPO (PCT)
Prior art keywords
rfed
request
network
dhcpdisconer
provisioning
Prior art date
Application number
PCT/US2005/016484
Other languages
French (fr)
Other versions
WO2005114545A8 (en
WO2005114545A3 (en
Inventor
Arthur G. Howarth
Ralph Droms
Roland Saville
Lawrence Kreeger
Christopher Wiborg
Vikas Butaney
Rajiv Singhal
Gary Dennis Vogel, Jr.
Original Assignee
Cisco Technology, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US10/866,507 external-priority patent/US7336175B2/en
Priority claimed from US10/866,285 external-priority patent/US7325734B2/en
Priority claimed from US10/866,506 external-priority patent/US7322523B2/en
Priority claimed from US11/104,140 external-priority patent/US8060623B2/en
Application filed by Cisco Technology, Inc. filed Critical Cisco Technology, Inc.
Priority to EP05750091A priority Critical patent/EP1751687A4/en
Priority to CA2565099A priority patent/CA2565099C/en
Publication of WO2005114545A2 publication Critical patent/WO2005114545A2/en
Publication of WO2005114545A8 publication Critical patent/WO2005114545A8/en
Publication of WO2005114545A3 publication Critical patent/WO2005114545A3/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0876Aspects of the degree of configuration automation
    • H04L41/0886Fully automatic configuration
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/08Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/08Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/087Inventory or stock management, e.g. order filling, procurement or balancing against orders
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0803Configuration setting
    • H04L41/0806Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/50Address allocation
    • H04L61/5007Internet protocol [IP] addresses
    • H04L61/5014Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/12Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/26Network addressing or numbering for mobility support
    • H04W8/265Network addressing or numbering for mobility support for initial activation of new user
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W64/00Locating users or terminals or network equipment for network management purposes, e.g. mobility management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/26Network addressing or numbering for mobility support

Definitions

  • the present invention relates to provisioning RFID devices and related network devices.
  • Bar codes containing a Universal Product Code have become a nearly ubiquitous feature of modern life.
  • bar codes have some drawbacks. Bar codes are "read only,” in that they are merely a printed set of machine-readable parallel bars that cannot be updated. Bar codes cannot transmit information, but instead must be read by a scanner. Bar codes must be scanned within a relatively short distance and must be properly oriented for the bar code to be read.
  • Smart labels generally implemented by RFID tags, have been developed in an effort to address the shortcomings of bar codes and add greater functionality. RFID tags have been used to keep track of items such as airline baggage, items of clothing in a retail environment, cows and highway tolls. As shown in Fig. 1, an
  • RFLD tag 100 includes microprocessor 105 and antenna 110.
  • RFID tag 100 is powered by a magnetic field 145 generated by an RFID reader 125.
  • the tag's antenna 110 picks up the magnetic signal 145.
  • RFID tag 100 modulates the signal 145 according to information coded in the tag and transmits the modulated signal 155 to the RFID reader 125.
  • RFID tags use the Electronic Product Code ("EPC" or "ePC") format for encoding information.
  • EPC includes variable length bits of information (common formats are 64, 96 and 128 bits), which allows for identification of individual products as well as associated information.
  • EPC 120 includes header 130, EPC Manager field 140, Object class field 150 and serial number field 160.
  • EPC Manager field 140 contains manufacturer information.
  • Object class field 150 includes a product's stock-keeping unit ("SKU") number.
  • Serial number field 160 is a 40-bit field that can uniquely identify the specific instance of an individual product i.e., not just a make or model, but also down to a specific "serial number" of a make and model.
  • RFID tags and associated RFLD devices such as RFLD readers and printers
  • RFLD readers and printers could form part of a network for tracking a product (or a group of products) and its history.
  • various difficulties have prevented this theory from being realized.
  • One problem that has required considerable time and energy from RF engineers is the development of lower-cost RFID tags with acceptable performance levels. Inductively-coupled RFID tags have acceptable performance levels.
  • Capacitively-coupled RFID tags use conductive ink instead of the metal coil used in inductive RFID tags. The ink is printed on a paper label by an RFID printer, creating a lower-cost, disposable RFID tag.
  • capacitively- coupled RFID tags have a very limited range. In recent years, RF engineers have been striving to extend the range of capacitively-coupled RFLD tags beyond approximately one centimeter.
  • Prior art RFLD devices and systems are not suitable for large-scale deployment of networks of RFID devices.
  • Conventional RFLD devices also have a small amount of available memory.
  • a typical RFLD device may have approximately .5 Mb of flash memory and a total of 1 Mb of overall memory.
  • the small memories of RFID devices place restrictions on the range of possible solutions to the problems noted herein.
  • an RFID device typically uses a proprietary operating system, e.g., of the manufacturer of the microprocessor(s) used in the RFLD device.
  • many RFID devices are deployed in a hostile industrial environment (such as a warehouse or factory) by relatively unskilled "IT" personnel.
  • RFID devices are being deployed with "static" knowledge of where the device was deployed at the original time of deployment. In practice, RFID devices are moved if another device is damaged or not functioning. In general, it is desirable to allow for the movement of RFLD devices. However, if an RFID device is moved, prior art systems do not know to what location the RFID device has been moved. It is becoming commonplace for devices, including but not limited to RFID readers, RFLD printers, VoIP telephones and devices used in manufacturing, to be deployed in large numbers within some networks. These devices often have unique characteristics, such as traffic type, bandwidth requirements, security demands, etc.
  • Fig. 10 illustrates a portion of a network 1000, in which network device 1005 (in this example, a CatalystTM switch provided by Cisco Systems, Inc.) is connected to a plurality of devices, including RFID reader 1010.
  • network device 1005 in this example, a CatalystTM switch provided by Cisco Systems, Inc.
  • RFID reader 1010 In this example, RFID reader
  • MAC address information and EPC information can be combined to identify a particular device and its location in a network.
  • Upper-level applications can be notified, for example, that a particular RFID device is available for use.
  • DHCP Dynamic Host Configuration Protocol
  • DHCP Options may be used to pass identification, location and provisioning information.
  • selected DHCP Options may be used to indicate whether a device is an RFLD device, to provide an EPC code uniquely identifying the particular device, indicating the company name using the device and indicating how the device is being used.
  • Some such implementations of the invention use DHCPREQUEST and
  • DHCPL FORM (RFC 213I) and DHCP Options (RFCs 2132 and 3004) to pass current provisioning and personality information.
  • some such implementations of the invention use the DHCPFORCERENEW command (RFC 3203) from a DHCP server to initiate an update or to complete reconfiguration, as required.
  • some implementations provide for a cached secret to be hashed with a client EPC that is included with the DHCPREQUEST from the RFID device and the response from the DHCP server.
  • Some implementations employ Domain Name Service (“DNS”) and dynamic DNS (“DDNS”) to allow easy identification of RFLD devices.
  • DNS Domain Name Service
  • DDNS dynamic DNS
  • Some aspects of the invention provide a method for uniquely provisioning a radio frequency identification (“RFLD”) device.
  • the method includes the following steps: receiving a provisioning request on a network; automatically identifying an RFID device according to a media access control (“MAC”) address and an electronic product code (“EPC") included in the provisioning request; and automatically locating the RFID device according to location information included in the provisioning request.
  • the method may be performed by a network device such as a Dynamic Host Configuration Protocol (“DHCP”) server.
  • the method may include the step of comparing information in the provisioning request with other information, in order to validate the RFLD device.
  • the method may also include the steps of determining whether the RFLD device has previously booted and/or of determining whether provisioning information has previously been established for the RFLD device.
  • the RFID device may be provisioned when it is determined that provisioning information has previously been established for the RFID device.
  • the RFLD device may be categorized as an untrusted device if it is determined that provisioning information has not previously been established for the RFID device.
  • Alternative aspects of the invention provide another method for uniquely provisioning an RFID device. The method includes the following steps: forming a DHCPDISCONER request that includes an EPC of an RFID device and location information indicating a location of the RFID device; sending the DHCPDISCONER request to a DHCP server; and receiving provisioning information from the DHCP server that is specifically intended for the RFID device.
  • the forming step may involve including the EPC in an Option field (e.g., Option 61) of the DHCPDISCONER request.
  • the forming step may involve including information (e.g., in Option 60) of the DHCPDISCONER request that indicates that the DHCPDISCONER request comes from an RFID device.
  • the forming step may also involve including information in the DHCPDISCONER request that indicates a name of a company that provides, owns or operates the RFID device.
  • the forming step may involve including information (e.g., in Option 77) of the DHCPDISCONER request regarding the type of RFLD device that formed the DHCPDISCONER request.
  • An RFLD device may include the EPC during a first part of the forming step.
  • a relay agent may include the location information in the DHCPDISCONER request during a second part of the forming step.
  • the RFID device may include the location information in the DHCPDISCONER request.
  • Some embodiments of the invention provide an RFLD device, including: a flash memory; a processor configured to form a DHCPDISCONER request that includes an EPC of an RFID device in Option 61, according to instructions in the flash memory; and a network interface for sending the DHCPDISCONER request to a DHCP server.
  • DHCPDISCONER request to a DHCP server; and receive provisioning information from the DHCP server that is specifically intended for the RFID device.
  • Still other embodiments of the invention provide a computer program embodied in a machine-readable medium, the computer program including instructions for controlling a network device to perform the following steps: receive a provisioning request on a network; identify an RFID device according to a MAC address and an EPC included in the provisioning request; and locate the RFID device according to location information included in the provisioning request.
  • Yet other aspects of the invention provide methods for deploying an RFID device in a network. One such method includes the following steps: forming a
  • DHCPDISCONER request that includes an EPC of an RFLD reader and location information indicating that the RFID reader is positioned at an exit door of a retail store; sending the DHCPDISCOVER request to a DHCP server; receiving provisioning information from the DHCP server that is specifically intended for the RFID reader; and provisioning the RFID reader according to the provisioning information, thereby enabling the RFID reader to read RFID tags passing through the exit door and to transmit RFID tag information to an RFID network.
  • the RFID tag information may include product information and/or shopper information.
  • the method may involve the step of using the RFID tag information to cause a financial account to be debited for the cost of the products.
  • the RFID tag information may be used to automatically update a database maintained by the retail store and/or a database maintained by a manufacturer/producer, wholesaler and/or a distributor of at least one of the products.
  • the RFID tag information may be used to update a business plan, such as a marketing, manufacturing, distribution or sales plan.
  • Still other embodiments of the invention provide an RFID network, including: a plurality of RFID devices; a plurality of switches connecting the RFID devices to the RFED network; and a DHCP server.
  • the RFLD devices are configured to do the following: form a DHCPDISCONER request that includes an EPC of an RFID device; send the DHCPDISCONER request to the DHCP server via a switch; and receive provisioning information from the DHCP server that is specifically tailored for the RFID device.
  • the switch is configured to add location information to the DHCPDISCONER request indicating a location of the RFLD device.
  • the DHCP server is configured to receive a DHCPDISCONER request, to automatically identify an RFID device according to a
  • MAC address and an EPC included in the DHCPDISCONER request and to automatically locate the RFLD device according to location information included in the DHCPDISCONER request.
  • Methods and devices are also provided for identifying end devices and automatically configuring associated network settings. Preferred implementations of the invention do not require users to manually identify connection types (e.g., RFLD, EPphone, manufacturing device, etc.) or to manually configure the network device. Accordingly, such implementations allow automatic switch configuration, even for devices that use inconsistent protocols and/or protocols that are not well known.
  • Some methods of the invention employ DHCP options combined with traffic snooping to identify devices and automatically apply appropriate switch port configuration. Some such implementations of the invention trigger Cisco Systems' SmartPortsTM software to configure ports of network devices. Some aspects of the SmartPorts software are described in United States Patent Application No. 10/896,410, filed July 21, 2004, which is hereby incorporated by reference.
  • the present invention is not limited to implementation via SmartPortsTM; any convenient software for the automated configuring of network device ports may be used in accordance with the present invention.
  • Some implementations of the invention provide a method for establishing network device port settings. The method includes the steps of receiving a
  • the method may also include the step of applying the appropriate macro when it is determined to be available.
  • the method preferably includes the step of determining whether the port has already been configured in a manner appropriate for the device.
  • the determining step may involve determining a device personality, identifying the device and/or examining at least one DHCP option or other component of the DHCPDISCONER request.
  • the "other component" could be, for example, one or more parts of the DHCP message header.
  • the determining step may or may not be performed by the network device on which the DHCPDISCONER request was first received.
  • the DHCPDISCONER request may first be received by a switch port and the determining step may be performed by one of a DHCP server, an edge services management server, an authentication server and a device dedicated to port configuration.
  • Some embodiments of the invention provide at least one apparatus for establishing network device port settings. Such embodiments include a port for receiving a DHCPDISCONER request from a device and at least one logic device configured for determining, based on information in the DHCPDISCONER request, whether an appropriate macro is available to configure the port.
  • a logic device may examine one or more DHCP options of the
  • the port and the logic device(s) may be included within a single device or may be disposed in separate devices.
  • the port and the logic device(s) may be included within a single switch or a DHCP server.
  • Alternative embodiments of the invention provide a network device that includes these elements: a plurality of ports; a storage device; and at least one logic device configured to receive a DHCPDISCONER request from a device via a first port and configure the first port with appropriate configuration parameters for the device.
  • a logic device may be further configured to forward a copy of the DHCPDISCONER request to a second device.
  • a logic device may configure the first port according to instructions received from the second device.
  • the second device may be, for example, a DHCP server, an edge services management server, an authentication server or a device dedicated to port configuration.
  • the methods of the present invention may be implemented, at least in part, by hardware and/or software.
  • some embodiments of the invention provide computer programs embodied in machine-readable media. The computer programs include instructions for controlling one or more devices to perform the methods described herein. BRIEF DESCRIPTION OF THE DRAWINGS
  • Fig. 1 is a diagram illustrating an RFLD tag.
  • Fig. 2 illustrates an exemplary RFID network according to the present invention.
  • Fig. 3 is a block diagram of an exemplary RFID reader that may be configured to perform some methods of the present invention.
  • Fig. 4 is a block diagram of an exemplary RFID printer that may be configured to perform some methods of the present invention.
  • Fig. 5 is a block diagram of an exemplary RFID system that may be configured to perform some methods of the present invention.
  • Fig. 6 is a flow chart that provides an overview of some methods of the present invention.
  • Fig. 7 is a flow chart that provides an overview of alternative methods of the present invention.
  • Fig. 8 is a flow chart that provides an overview of some implementations of the present invention.
  • Fig. 1 is a diagram illustrating an RFLD tag.
  • Fig. 2 illustrates an exemplary RFID network according to the present invention.
  • Fig. 3 is a block diagram of an exemplary RFID reader that may be configured to
  • FIG. 9 illustrates an example of a network device that may be configured to implement some methods of the present invention.
  • Fig. 10 is a network diagram illustrating a switch and attached RFID devices.
  • Fig. 11 A illustrates an exemplary SmartPortsTM macro.
  • Fig. 1 IB illustrates an exemplary set of commands to be used for configuring a port according to a SmartPortsTM macro.
  • Fig. 12A is a flow chart that provides an overview of a method of the present invention.
  • Fig. 12B is a network diagram that illustrates an implementation of the method outlined in Fig. 12 A.
  • Fig. 13 is a flow chart that provides an overview of an alternative method of the present invention.
  • Fig. 14 is a block diagram that illustrates a network device for implementing some aspects of the invention. DETAILED DESCRIPTION OF THE INVENTION
  • RFLD devices perform different functions and may interface to the upstream systems differently depending on where they are located. The functions they perform, as well as the unique settings to perform those functions, will be referred to herein as the device "personality.”
  • provisioning a device can include, but is not limited to, providing network configuration, providing personality configuration, incorporating the device into a network database and enabling the device with software (e.g., business process software).
  • software e.g., business process software
  • RFJD devices that are networked according to the present invention can provide necessary information for allowing enterprises to track equipment and products (or groups of products).
  • the information that will be provided by RFID devices that are networked according to the present invention will be of great benefit for enterprise resource planning, including the planning of manufacturing, distribution, sales and marketing.
  • RFLD tags and associated RFID devices can form part of a network for tracking a product and its history.
  • a shopper who wishes to purchase products bearing RFID tags can, for example, transport the products through a door that has an RFID reader nearby.
  • the EPC information regarding the products can be provided to an RFID network by the reader and can be used to automatically update a store inventory, cause a financial account to be debited, update manufacturers', distributors' and retailers' product sales databases, etc.
  • Read/write RFID tags can capture information regarding the history of products or groups of products, e.g., temperature and other environmental changes, stresses, accelerations and/or vibrations that have acted upon the product. It will be particularly useful to record such information for products that relatively more subject to spoilage or other damage, such as perishable foods and fragile items.
  • this information will be used to update databases maintained by various entities (e.g., manufacturers, wholesalers, retailers, transportation companies and financial institutions).
  • the information will be used not only to resolve disputes (for example, regarding responsibility for product damage) but also to increase customer satisfaction, to avoid health risks, etc.
  • Some aspects of the invention use a combination of EPC code information and modified versions of existing networking standards for identifying, locating and provisioning RFID devices, such as RFID readers and RFID printers, that are located in a network.
  • An example of such a network is depicted in Fig. 2.
  • RFID network 200 includes warehouse 201, factory 205, retail outlet 210, financial institution 215 and headquarters 220.
  • network 200 could include many other elements and/or multiple instances of the elements shown in Fig. 2.
  • network 200 could include a plurality of warehouses, factories, etc.
  • products 227 are being delivered to warehouse 201 by truck 275.
  • Products 227 which already include RFED tags, are delivered through door 225.
  • RFID reader 252 is connected to port 262 of switch 260.
  • switches 230 and 260 are connected to the rest of RFLD network 200 via gateway 250 and network 225.
  • Network 225 could be any convenient network, but in this example network 225 is the Internet.
  • RFID reader 252 reads each product that passes through door 225 and transmits the EPC code corresponding to each product on RFLD network 200.
  • RFID tags may be used for different levels of a product distribution system. For example, there may be an RFID tag for a pallet of cases, an RFID tag for each case in the pallet and an RFID tag for each product. Accordingly, after products 227 enter warehouse 201, they are assembled into cases 246.
  • RFLD printer 256 makes an RFLD tag for each of cases 246.
  • RFID printer 256 is connected to port 266 of switch 260.
  • RFID printer 256 could operate under the control of PC 247 in warehouse 201, one of PCs 267 in headquarters 220, or some other device.
  • RFID reader 224 which is connected to port 214, reads the EPC code of each case 246 and product 227 on conveyor belt 244 and transmits this information on network 200.
  • Each of the RFID devices in network 200 preferably has a "personality" suitable for its intended use.
  • device 252 could cause reassuring tone to sound and/or a green light to flash if an authorized person or object enters door 225.
  • device 252 might cause an alarm to sound and/or an alert to be sent to an administrator on network 200 if a product exits door 225 or an unauthorized person enters or exits door 225.
  • Fig. 3 illustrates an RFID reader that can be configured to perform methods of the present invention.
  • RFID reader 300 includes one or more RF radios 305 for transmitting RF waves to, and receiving modulated RF waves from, RFID tags.
  • RF radios 305 provide raw RF data that is converted by an analog-to-digital converter (not shown) and conveyed to other elements of RFID reader 300. In some embodiments, these data are stored, at least temporarily, by CPU 310 in memory 315 before being transmitted to other parts of RFID network 200 via network interface 325.
  • Network interface 325 may be any convenient type of interface, such as an Ethernet interface.
  • Flash memory 320 is used to store a program (a "bootloader") for booting/initializing RFID reader 300.
  • flash memory 320 includes instructions for controlling CPU 310 to form "DHCPDISCONER" requests, as described below with reference to Fig. 6, to initiate a provisioning/configuration cycle.
  • flash memory 320 is used to store personality information and other configuration information obtained from, e.g., a DHCP server during such a cycle. However, in preferred implementations, such information is only stored in volatile memory 415 after being received from, e.g. a DHCP server.
  • a network of dumb RFID devices allows much of the processing load to be centralized (e.g., performed by server 270 of network 200), instead of being performed by the RFID devices.
  • the processing load can be decentralized, but only to trusted devices (such as PC 247 of network 200).
  • Configuration information is downloaded from, e.g., a central server to memory 315. Updates may be instigated by the central server or selected, trusted devices. New versions of the image file (e.g., the running, base image necessary to operate the RFID device) are copied into flash memory 320.
  • Alternative embodiments of RFLD devices implement the methods of the present invention yet lack flash memory.
  • Fig. 4 is a block diagram illustrating an exemplary RFID printer 400 that may be configured to perform some methods of the present invention.
  • RFID printer 400 has many of the same components as RFID reader 300 and can be configured in the same general manner as RFID reader 300.
  • RFID printer also includes printer interface 430, which may be a standard printer interface. Printer interface prints a label for each RFID tag, e.g. according to instructions received from network 200 via network interface 425.
  • RF Radio 405 is an outbound radio that is used to send RF signals to the antenna of an RFED tag under the control of CPU 410, thereby encoding information (e.g. an EPC) on the tag's microprocessor. Preferably, RF Radio 405 then checks the encoded information for accuracy.
  • the RFID tag is sandwiched within the label produced by printer interface 430.
  • Fig. 5 illustrates RFED system 500 that includes control portion 501 and RF radio portion 502. The components of control portion 501 are substantially similar to those described above with reference to Figs. 3 and 4. Interconnect 530 of control portion 501 is configured for communication with interconnect 535 of RF radio portion 502.
  • the communication may be via any convenient medium and format, such as wireless, serial, point-to-point serial, etc.
  • each control portion 501 may control a plurality of RF radio portions 502.
  • RFID system 500 may be deployed on a single framework or chassis (e.g., on a forklift) or in multiple chassis.
  • the DHCP protocol is used in some preferred implementations of the present invention because it offers various convenient features. For example, the DHCP protocol allows pools or "scopes" of TCP/IP addresses to be defined. A DHCP server can temporarily allocate or "lease" these TCP/IP addresses to host devices. An IP address that is not used for the duration of the lease is returned to the pool of unallocated IP addresses.
  • the DHCP server will provide all related configuration settings, such as the default router, Domain Name Service ("DNS") servers, subnet mask, etc., that are required for the proper functioning of TCP/IP.
  • DNS Domain Name Service
  • DHCP Options may be used to pass provisioning information.
  • the DHCP protocol is defined in RFC 2131 and DHCP Options are set forth in, for example, RFCs 2132, 3004 and 3046. RFCs 2131, 2132, 3004 and 3046 are hereby incorporated by reference for all purposes.
  • an EPC corresponding to an RFED device is put inside a DHCP request sent from the RFED device to a DHCP server. The EPC uniquely identifies the RFED device.
  • a device that sends out an initiation for an EP address to a DHCP server does so by way of a packet that includes a "DHCPDISCONER" request.
  • This command includes the media access control (“MAC") address of the device.
  • the RFID device e.g., CPU 310 of RFID Reader 300
  • the RFID device encodes DHCP "class identifier" Option 60 with a code indicating that the device is an RFED device.
  • RFED will be a new type of "class,” encoded in Option 60.
  • the RFED device encodes its own EPC in the field reserved for Option 61
  • the RFED device also encodes a company name, e.g., of the company that supplies, owns or is using the RFED device, in DHCP Option 43.
  • Option 77 may be used in various ways according to different implementations of the invention. In some implementations, Option 77 will be used to indicate the type of RFED device, e.g., that the RFED device is an RFED reader or an RFED printer, hi some implementations, Option 77 can also include information regarding the functionality or "personality" of the RFED device.
  • Option 77 could indicate that the RFED device is an inbound RFED reader, an outbound RFED reader, an RFED reader or printer on an assembly line, a retail store, etc.
  • the request is from RFED device 252
  • that device would encode information in Option 77 indicating that the device is an RFED reader
  • Option 77 also indicates that RFED device 252 has a personality suitable for being positioned at an entrance door. Some implementations include more detailed information about the current personality of device 252.
  • Option 77 may indicate that in addition to reading EPC codes and uploading them to the RFED network, device 252 will also cause a green light to flash if an authorized person or object enters door 225 and will cause a red light to flash, an alarm to sound and an alert to be sent to an administrator on the network if a product exits door 225.
  • This information could be encoded, for example, according to a number that corresponds to one of a range of suitable personalities for an RFED reader at an entrance door. It is desirable to determine and provide location information for RFED devices in a network. Switches and wireless bridges with Ethernet or switch ports are considered static and have assigned names and locations.
  • location information is added, for example to an RFLD device's DHCPDISCONER request, by the network device to which the RFED device is attached (step 610).
  • Some such implementations use DHCP Option 82 (RFC 3046) in a new way to determine the switch port and switch to which an RFED device is connected.
  • a switch may insert the following two information elements into any DHCP request from an attached RFED device: Option 82, Sub-Option 1 : Agent Circuit ED and Option 82, Sub-Option 2: Agent Remote ED.
  • the Agent Circuit ED is the name or identifier of the switch.
  • the Agent Remote ED is the name or identifier of the switch port.
  • network device 230 adds location information to the request in step 610.
  • the location information would be encoded in Option 82 and would include information identifying network device 230 and port 216, to which RFED reader 226 is attached.
  • the RFED device may encode location information in the DHCPDISCONER request or in other commands.
  • RFED pilot networks As RFED pilot networks emerge and develop, they will be interleaved with existing networks, including networks that employ the DHCP protocol.
  • DHCP servers that are provisioning RFED devices (e.g. server 270 of Fig. 2) will respond to "DHCPDISCONER" commands identifying a class of the device as "RFED,” e.g., encoded in Option 60.
  • RFED e.g., encoded in Option 60.
  • DHCP servers that are not provisioning RFED devices will not respond to "DHCPDISCONER" commands identifying a class of the device as "RFED.” Further, if a non-RFED DHCP server does respond, the RFED device will be able to determine from the DHCP options response that it has received an incomplete DHCP response and will discard it and will prefer responses from RFED DHCP servers. Accordingly, the methods of the present invention allow for the integration of RFID networks within the existing framework of the DHCP protocol. In step 615, the DHCP server determines whether there is information regarding the requesting device within a database of information regarding known RFED devices, their intended functions, configurations, etc.
  • the DHCP server may inspect the EPC encoded in a request and determine whether there is information for a device with a corresponding EPC in the database. If so, in step 620, the server compares information in the DHCP request with stored information regarding the RFED device. This information may be in a database (e.g., stored in one of storage devices 265) that is updated, for example, by IT personnel responsible for the RFED network. For example, MAC address information and EPC information can be combined to identify a particular device and its location in a network. Upper-level applications can be notified, for example, that a particular RFED device is available for use.
  • the server can then determine the type, identity, location and personality (if any) of the RFED device. By comparing the received data with information in the database, the server can then determine, for example, if that precise RFED device has moved and where it is now located.
  • the DHCP server may determine the current personality of the RFED device (e.g., by inspecting the Option 77 data) and may compare the current personality with a desired personality.
  • the DHCP server provides the RFED device with configuration information, etc., indicated in the database.
  • the DHCP server may indicate the RFED device's time server, SYSLOG server, the location of the device's configuration files, image files, etc.
  • the DHCP server can provide the device with information (e.g., a computer program, configuration settings, etc.) for enabling the desired personality. For example, suppose that the EPC code indicates that the device is RFED reader 252 and Option 77 indicates that RFED device 252 has a personality suitable for being positioned at an entrance door. However, the location information in the request may indicate that the requesting device has been moved and is now located at an exit door. Alternatively, the database may indicate that the device is positioned at a door that has been used as an entrance door, but which now will be used as an exit door. This may be a periodic (e.g.
  • the desired personality for RFED device 252 is now a personality appropriate for an exit door.
  • a device with fewer capabilities may be enabled for relatively simpler exit door functionality.
  • a device may be enabled to, e.g., make a green light flash when particular type of product is exiting the door and to transmit a notification message to IT personnel and/or cause an alarm to sound if other items are exiting the door.
  • a device with greater capabilities may be enabled for relatively more complex exit door functionality.
  • the device could be enabled to cause a green light to flash if a particular type of product is exiting at an expected time, if the number of products exiting the door is within a predetermined range, etc.
  • This flexibility in reassigning device personality allows an RFED network to cause the same device type to have multiple personalities based upon location, time of day, or any other suitable criteria. Moreover, this flexibility allows for movement or relocation of devices (whether or not this movement has been approved in advance) and then having devices automatically "repersonalized," as appropriate for the new location. In addition, it allows for specialized functionality on a per device, per locale basis. However, in some circumstances there may be no information in the database regarding the device. For example, the device may be a new RFED device that has just been activated in the RFED network for the first time (step 630). In this example, the device is placed in a "walled garden" for devices that are not trusted devices.
  • Step 630 may involve assigning the device a non-routable EP address for a predetermined length of time via a DHCPOFFER command.
  • the DHCP server performs step 630 when there is information in the database regarding the device that is inconsistent with information in the request.
  • step 630 includes notifying an upper-layer application that the device has made the request. In this way, IT personnel responsible for the site within which the RFED device is located will be notified that the RFED device exists and has made a request.
  • step 630 involves setting the DHCP Tl timer for a short time interval, for example, 60 seconds.
  • the RFED device will continue to send DHCP requests to the server every 60 seconds and the server will send "ACKs" to the device until one of two events occurs: (1) the server has been updated (e.g., by IT personnel responsible for the site within which the
  • Step 635 If the server is updated within the predetermined time, this indicates that an IT person has determined that the RFID device making the request is a trusted device. Accordingly, the method proceeds to step 625. If not, the device remains classified as an untrusted device (step 630). Preferably, the device's status may still be changed to that of a trusted (and therefore provisioned) device, e.g., according to subsequent input from IT personnel. After an initial provisioning configuration cycle (e.g., as described above),
  • RFED devices may need to be reprovisioned or have their personalities changed. As noted above, it is desirable for an RFED device to take on unique provisioning and personalities depending on the desired functionality of the RFED device at a particular time. The desired functionality may be determined according to the location and capabilities of the RFED device. Some devices may be provided with the same personality for a relatively longer time, e.g., months or years. However, it may be desirable to change the personality and/or provisioning information of an RFED device in a relatively shorter time, e.g., prior to the time that a DHCP Tl timer expires. The majority of currently-deployed RFED end devices do not support RFC 3203 (DHCP Reconfigure Extension).
  • Method 700 begins with a determination of whether to send information to a network device regarding the current personality of the RFED device (step 701).
  • the RFED device will send the information to a DHCP server if a predetermined period of time has elapsed. In this example, the predetermined period of time is one hour, but it could be any convenient period of time. If it is time for another DHCPREQUEST or DHCPLNFORM request to be sent to the DHCP server, the RFED device forms the request (step 705). If not, the current personality is maintained (step 702).
  • the information will be sent in a DHCP request (RFC 2131) combined with DHCP Option 61 set to the RFLD device's EPC (or equivalent) and Option 77 set to the RFED device's current personality.
  • RRC 2131 DHCP request
  • DHCP Option 61 set to the RFLD device's EPC (or equivalent)
  • Option 77 set to the RFED device's current personality.
  • DHCPLNFORM and DHCP Options the RFED device is able to pass current identification, provisioning and personality information.
  • a cached secret e.g., hashed with the contents of the DHCP message, including the client EPC
  • the secret could be provided, for example, during an earlier provisioning stage, e.g., the initial provisioning stage of the RFED device.
  • the secret could be used in the DHCPLNFORM validation process and for other processes.
  • the request is sent in step 710.
  • a relay agent updates the request with location information, as described above (step 715).
  • the server compares the information in the request with stored information (e.g., in a lookup table or a database) to determine whether an update or a complete reconfiguration of the RFED device is required. If not, the process returns to step 701. If so, the server provides the RFED device with the necessary update and/or reconfiguration information (step 725). The RFED device triggers the update and/or reconfiguration determination in the foregoing example.
  • a DHCP server e.g., the DHCP server
  • the DHCP server could initiate a periodic process of comparing a desired RFED device personality with the last known RFED device personality.
  • an IT worker could send information (e.g., to the DHCP server, to the RFED device or to another device) indicating a desired change in personality.
  • a DHCP server causes an update or a complete reconfiguration using a DHCPFORCERENEW command as defined by RFC 3203, which is hereby incorporated by reference in its entirety.
  • the CPU of the RFED device registers the ForceRenew command and starts a new provisioning cycle, for example as described above with reference to Fig. 6.
  • a cached secret is hashed within the command.
  • the secret can be included with the EPC code of the RFED device.
  • One method for creating an authentication key is as follows: MD-5 (EPC, Challenge, Secret) By adding in the variable of a random Challenge, no replay attacks of the hash code could be used. Because the EPC is included, the authentication can be further validated to come from a specific device.
  • Fig. 8 is a flow chart that illustrates an exemplary business application of the present invention. Those of skill in the art will appreciate that the example described below with reference to Fig. 8 is but one of many applications of the invention.
  • step 805 an RFED device has already been provisioned according to one of the previously-described methods. The condition of the RFED device is comparable to that of a device at step 640 in method 600, shown in Fig.
  • the RFLD device is an RFED reader that is positioned near an exit door of a retail store. Therefore, in the previous steps, the device has been provisioned with a personality that is appropriate for its role.
  • a shopper exits the door with a number of selected products.
  • the RFED reader reads the RFED tags of each product and extracts the EPC codes and related product information (e.g., the price of each product). The RFED reader also reads an RFED tag that identifies the shopper and the shopper's preferred account(s) that should be debited in order to purchase the products.
  • the shopper may have an RFED tag embedded in a card, a key chain, or any other convenient place in which this information is encoded.
  • the accounts may be various types of accounts maintained by one or more financial institutions.
  • the accounts may be one or more of a checking account, savings account, a line of credit, a credit card account, etc.
  • Biometric data e.g., voice, fingerprint, retinal scan, etc.
  • the RFED reader transmits the product information, including the EPC codes, on the RFED network.
  • the information is first sent to a financial institution indicated by the shopper's RFED tag.
  • the financial institution that maintains the shopper's selected account determines whether there are sufficient funds (or whether there is sufficient credit) for the shopper to purchase the selected products. If so, the shopper's account is debited and the transaction is consummated (step 830). In this example, the shopper has the option of designating one or more alternative accounts. Accordingly, if the first account has insufficient funds or credit, it is determined (e.g., by a server on the RFED network) whether there the shopper has indicated any alternative accounts for making purchases (step 835). If so, the next account is evaluated in step 825. If it is determined in step 835 that there are no additional accounts designated by the shopper, in this example some form of human intervention takes place.
  • a cashier of the retail store could assist the shopper in making the purchases in a conventional manner. If some or all of the products are purchased, information regarding the purchased products (including the EPC codes) are transmitted on the RFED network. For example, this information is preferably forwarded to one or more devices on the
  • RFED network that are configured to update one or more databases maintained by the retail store or the manufacturers/producers, distributors, wholesalers, etc., of the purchased products (step 840).
  • information regarding the shopper is also transmitted on the RFED network (e.g., if the shopper has authorized such information to be released).
  • This product information (and optionally shopper information) may be used for a variety of purposes, e.g., in the formation of various types of business plans (e.g., inventory re-stocking, marketing, sales, distribution and manufacturing/production plans).
  • Fig. 9 illustrates an example of a network device that may be configured to implement some methods of the present invention.
  • Network device 960 includes a master central processing unit (CPU) 962, interfaces 968, and a bus 967 (e.g., a PCI bus).
  • interfaces 968 include ports 969 appropriate for communication with the appropriate media.
  • one or more of interfaces 968 includes at least one independent processor 974 and, in some instances, volatile RAM.
  • Independent processors 974 may be, for example ASICs or any other appropriate processors. According to some such embodiments, these independent processors 974 perform at least some of the functions of the logic described herein.
  • one or more of interfaces 968 control such communications-intensive tasks as media control and management.
  • interfaces 968 allow the master microprocessor 962 efficiently to perform other functions such as routing computations, network diagnostics, security functions, etc.
  • the interfaces 968 are typically provided as interface cards (sometimes referred to as "line cards").
  • interfaces 968 control the sending and receiving of data packets over the network and sometimes support other peripherals used with the network device 960.
  • interfaces that may be provided are Fibre Channel (“FC”) interfaces, Ethernet interfaces, frame relay interfaces, cable interfaces, DSL interfaces, token ring interfaces, and the like.
  • FC Fibre Channel
  • CPU 962 may be responsible for implementing specific functions associated with the functions of a desired network device.
  • CPU 962 accomplishes all these functions under the control of software including an operating system (e.g. Linux, Nx Works, etc.), and any appropriate applications software.
  • CPU 962 may include one or more processors 963 such as a processor from the Motorola family of microprocessors or the MIPS family of microprocessors.
  • processor 963 is specially designed hardware for controlling the operations of network device 960.
  • a memory 961 (such as non- volatile RAM and/or ROM) also forms part of CPU 962.
  • Memory block 961 may be used for a variety of purposes such as, for example, caching and/or storing data, programming instructions, etc.
  • network device may employ one or more memories or memory modules (such as, for example, memory block 965) configured to store data, program instructions for the general-purpose network operations and/or other information relating to the functionality of the techniques described herein.
  • the program instructions may control the operation of an operating system and/or one or more applications, for example. Because such information and program instructions may be employed to implement the systems/methods described herein, the present invention relates to machine-readable media that include program instructions, state information, etc. for performing various operations described herein.
  • machine-readable media include, but are not limited to, magnetic media such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROM disks; magneto-optical media; and hardware devices that are specially configured to store and perform program instructions, such as read-only memory devices (ROM) and random access memory (RAM).
  • ROM read-only memory
  • RAM random access memory
  • the invention may also be embodied in a carrier wave traveling over an appropriate medium such as airwaves, optical lines, electric lines, etc.
  • program instructions include both machine code, such as produced by a compiler, and files containing higher level code that may be executed by the computer using an interpreter.
  • interfaces/line cards may be bus based (as shown in Fig. 9) or switch fabric based (such as a cross-bar).
  • SmartPortsTM “macro” functionality for configuring ports of network devices.
  • a command line interface (“CLI”) or another programmatic interface such as Simple Network Management Protocol (“SNMP”) or Netconf® is used for this purpose.
  • SNMP Simple Network Management Protocol
  • Prior implementations of SmartPortsTM macros required users to manually identify connection types (e.g., RFLD, manufacturing, EPphone) and then to configure a network device according to the identified connection type.
  • connection types e.g., RFLD, manufacturing, EPphone
  • the term “macro” will sometimes be used to mean both the commands used to configure, e.g., a port of a network device and a configuration resulting from the application of such a macro.
  • the network device could be configured, for example, using a command line interface or a network management tool such as CMS on a per-port basis.
  • An exemplary Cisco SmartPortsTM macro for configuring a port for an RFID device will now be described with reference to Fig. 11 A.
  • Line 1101 is used to establish the macro's name, which in this case is RFED_Macrol. It is helpful to use a name that is easy to recognize as one type of macro for RFED devices, to allow for the possibility of having macros for multiple device types and multiple macros for RFED devices.
  • Line 1103 will cause an RFED VLAN to be assigned and line 1105 puts a switch port in "access" mode.
  • Line 1107 assigns a generic description to the interface indicating its use, which is a connection to an RFID device in this example.
  • Lines 1109 enable port security and limit the port to a single media access control (“MAC") address.
  • MAC media access control
  • Line 1111 when the maximum number of MAC addresses is exceeded, traffic from additional source MAC addresses are dropped. In addition, an SNMP trap and a syslog message are generated.
  • Lines 1113 cause the secure MAC address to age out after 10 minutes of inactivity.
  • Lines 1115 configure the port as an edge device port that does not need to behave according to a spanning tree protocol. Accordingly, bridge port data unit (“BPDU”) packets are not be allowed to enter the network from this port.
  • BPDU bridge port data unit
  • Lines 1117 set broadcast and multicast storm control limits to 20% of the interface bandwidth. As with other settings in this example, this limit should be based upon the anticipated requirements of the device to be in communication with the port.
  • Line 1119 applies a rate limiting of DHCP packets coming from the device to 100 packets per second.
  • Line 1121 is one example of a QoS for the device. This QoS is applicable, for example, if the device is an RFED reader that sends packets marked with DSCP and if these values should be trusted.
  • Fig. 1 IB sets forth one example of how to apply the previously-described SmartPorts macro to a switch port. Fig.
  • 1 IB is a screen capture of a CLI session for configuring a port.
  • Line 1151 identifies the switch to be configured ("DC_Switchl").
  • Line 1155 is a prompt from switch DC_Switchl.
  • Line 1160 configures the interface as a Fast Ethernet interface.
  • Line 1165 applies a selected macro, which is "RFED_Macrol" in this example, to the interface. The example assumes that VLAN 30 has previously been configured as the RFED VLAN.
  • Line 1170 is a command prompt from switch DC Switchl.
  • a user e.g., a network administrator
  • a user would need to manually go into every port, select a macro for each device (if one exists) and apply the appropriate macro to the port to which the device is connected.
  • the user would need to determine the appropriate port configuration for a connection with RFED reader 1010, determine whether a macro exists for this configuration, and, if so, apply the appropriate macro to configure port 1020. If no such macro existed, each attribute of the port configuration would need to be separately indicated.
  • FIG. 12A is a flow chart that outlines method 1200 according to the invention.
  • Fig. 12B is a simplified network diagram of network 1250 that provides one example of how method 1200 may be implemented.
  • Those of skill in the art will appreciate that some steps of the methods discussed herein, including method 1200, need not be performed (and in some implementations are not performed) in the order shown. Moreover, some implementations of the methods discussed herein may include more or fewer steps than those shown, e.g., in Fig. 12A.
  • Fig. 12B illustrates switches 1265, 1280 and 1285, all of which have attached devices.
  • switch 1265 is a Cisco Catalyst 4500 Series switch and switches 1280 and 1285 are Cisco Catalyst 3750 Series switches.
  • switches 1265 are a Cisco Catalyst 4500 Series switch and switches 1280 and 1285 are Cisco Catalyst 3750 Series switches.
  • switches 1265 are a Cisco Catalyst 4500 Series switch and switches 1280 and 1285 are Cisco Catalyst 3750 Series switches.
  • switches 1265 is a Cisco Catalyst 4500 Series switch and switches 1280 and 1285 are Cisco Catalyst 3750 Series switches.
  • Switches 1265, 1280 and 1285 could be in the same location (e.g., in the same warehouse or factory) or could be in different locations.
  • Switches 1265, 1280 and 1285 can commumcate with DHCP server 1270, host device 1290 and storage devices 1295 via network 1275.
  • network 1275 may include portions of one or more private networks and part of the Internet.
  • the devices attached to switches 1265, 1280 and 1285 are not necessarily all of the same type.
  • device 1255 is an RFED reader and device 1257 is an EP telephone.
  • even devices that are of the same general type may have different capabilities and/or different desired functions.
  • a device that sends out an initiation for an EP address to a DHCP server does so by way of a packet that includes a "DHCPDISCONER" request.
  • This command includes, inter alia, the media access control ("MAC") address of the device.
  • MAC media access control
  • switch 1265 is configured not only to forward DHCPDISCONER request 1256 to DHCP server 1270 via network 1275, but also to analyze the contents of DHCPDISCONER request 1256.
  • the steps performed by switch 1265 according to method 1200 may be controlled by one or more logic devices 1268, which is an ASIC in this example. However, logic device(s) 1268 could be any convenient logic device(s).
  • switch 1265 attempts to identify device 1255 according to information in DHCPDISCONER request 1256. In this example, switch 1265 applies "snooping" techniques to analyze the contents of Options in DHCPDISCONER request 1256. Switch 1265 may, for example, examine the contents of DHCP Option 60 to determine a device type or vendor identifier.
  • Switch 1265 may examine the "Enterprise number" field of DHCP Option 125 to determine the EPCGlobal enterprise number of the device. RFC 3925 is hereby incorporated by reference. Alternatively, or additionally, switch 1265 may examine other DHCP options. For example, switch 1265 may examine DHCP Option 150 to identify device 1255; this Option is used, for example, by EPPhones provided by Cisco Systems, Inc. R. Johnson's draft "TFTP Server Address DHCP Option" (Network Working Group Feb. 6, 2005) describes relevant information and is hereby incorporated by reference.
  • Switch 1265 may examine a "PXE boot” option to determine an appropriate configuration for port 1260.
  • PXE Preboot execution Environment
  • Switch 1265 may examine Option 43 to obtain vendor-specific information regarding device
  • Switch 1265 may examine Option 61 to determine an EPC identifier of device 1255. In some implementations, switch 1265 also determines an appropriate personality for device 1255 in step 1215. In some such implementations, switch 1265 examines the DHCP Option 77 to determine a device personality. In other implementations, switch 1265 can determine an appropriate personality for device 1255 indirectly, e.g., by cross-referencing a look-up table or a similar data structure based on other information in DHCPDISCONER request 1256. The look-up table could be stored locally (e.g., in memory 1267), on an attached device or on another device that switch 1265 can access via network 1275, part of which is the Internet in this example.
  • switch 1265 cannot identify device 1255, the process ends in this example (step 1240 of Fig. 12A). Alternatively (or additionally), a network administrator could be alerted, e.g., by causing switch 1265 to send a message to host device 1290. However, if switch 1265 can identify the device, the method proceeds to step 1220, wherein switch 1265 determines port 1260 is already configured. (In the flow chart of Fig. 12A it is presumed that a port configuration (if any) has resulted from the application of a macro, though this need not be the case.) If port 1260 has not yet been configured, it is determined whether there is a configuration macro available (e.g., locally available and stored in memory 1267) that is appropriate for device 1255.
  • a configuration macro available (e.g., locally available and stored in memory 1267) that is appropriate for device 1255.
  • Table 1266 is one exemplary data structure that may be used for such a purpose.
  • Table 1266 includes macro field 1272, for defining a plurality of configuration macros, each of which corresponds to a device of device ID field 1274. Accordingly, a device ID determined as described above with reference to step 1215 (or otherwise) can be used to determine whether there is a corresponding macro. If port 1260 is already configured, it is determined in step 1225 whether the configuration is suitable for the device identified in step 1215. If so, the process ends. If the port does not have a desired configuration, it is determined in step 1230 whether there is an appropriate macro available for the device.
  • the macro is applied (step 1235) and then the process ends (step 1240). If not, the process ends without a macro being applied.
  • a network administrator is notified, e.g., by sending a message from switch 1265 to host device 1290.
  • switch 1265 had the intelligence for determining how to automatically configure a port on which a DHCPDISCONER request is received.
  • the switch itself analyzed the DHCPDISCONER request and configured the port with an appropriate combination of attributes. These combinations of attributes, along with the necessary software for applying them, were stored in the switch itself.
  • both the intelligence for determining how appropriately to configure the port and the instructions for so configuring the port may be owned by another device.
  • the intelligence may reside in DHCP server 1270, an edge services management server, an authentication server and a device dedicated to port configuration.
  • Some such implementations are illustrated by the flow chart of Fig. 13.
  • steps 1301 and 1305 a device initializes and sends a DHCPDISCONER request to a switch port, h this example, switch 1265 forwards the DHCPDISCONER request with an indication of the port on which the DHCPDISCONER request was received.
  • the port ID could be provided, for example, in DHCP Option 82.
  • the switch also forwards information regarding the current port configuration to DHCP server 1270.
  • DHCP server 1270 attempts to identify the device. (Step 1312.) If DHCP server 1270 can identify the device, DHCP server 1270 performs steps 1320, 1325 and 1330, which are analogous to steps 1220 through 1230 of method 1200. DHCP server 1270 then instructs switch 1265 to configure the port in an appropriate manner, e.g., by applying a macro. (Step 1335.) Macros (or the like) for this purpose could be stored in switch 1265, could be sent from DHCP server 1270 to switch 1265, or could be obtained by switch 1265 from another device.
  • DHCP server 1270 could send switch 1265 a pointer to a memory space wherein such instructions are stored (e.g., in one of storage devices 1295).
  • DHCP server 1270 provides an IP address in response to the DHCPDISCONER request and forwards the DHCPDISCONER request to another device that performs steps similar to steps 1210 through 1230.
  • the device could be, e.g., an authentication server or a server that is dedicated to automated port configuration. This device could instruct switch 1265 to configure the port in an appropriate manner, e.g., as described above.
  • DHCP server 1270 could perform at least the device and port identification steps.
  • DHCP server 1270 could then forward this information to another device that first performs a mapping of device type to desired configuration and then instructs switch 1265 to configure port 1260 accordingly.
  • a device local to switch 1265 performs steps similar to those of steps 1215 through 1230 and then instructs switch 1265 accordingly.
  • a DHCP relay agent in switch 1265 is programmed to forward a copy of the DHCPDISCONER request to another device (e.g., an edge services management server) that performs steps similar to steps 1210 through 1230, e.g., prior to forwarding the DHCPDISCONER request to the DHCP server.
  • chassis 1400 is a router that includes switch module 1405, with ports 1410 that can be configured for appropriately communicating with devices 1415.
  • router 1400 also includes DHCP server 1420, which may be implemented in software and/or hardware (e.g., as a line card or "blade").
  • DHCP server 1420 could be implemented in a separate device that is in communication with router 1400.
  • alternative embodiments of the invention provide a chassis 1400 that is a switch that runs Layer
  • chassis 1400 could also include DHCP server 1420, implemented in software and/or hardware, or DHCP server 1420 could be implemented in a separate device that is in communication with chassis 1400.
  • DHCP server 1420 could also include DHCP server 1420, implemented in software and/or hardware, or DHCP server 1420 could be implemented in a separate device that is in communication with chassis 1400.
  • DHCP server 1420 could be implemented in a separate device that is in communication with chassis 1400.
  • point-of-sale devices e.g., "cash registers”
  • NoEP telephones and devices used in manufacturing may be advantageously configured according to the methods of the present invention.
  • one or more defined fields could indicate the type of device, device personality, etc.
  • DHCP Option 60 could indicate that the device is a cash register and DHCP Option 77 could indicate the "personality" of the cash register, e.g., that it is a cash register used by a particular type of restaurant.

Abstract

Methods and devices are provided for requesting (601), identifying, locating (610), configuring (640) and provisioning devices in a network. According to some implementations of the invention, MAC address information and EPC information can be combined to identify a particular device and its location in a network. For implementations using the Dynamic Host Configuration Protocol ('DHCP'), DHCP options may be used to pass provisioning and other information. Some implementations employ Domain Name Service ('DNS') and dynamic DNS ('DDNS') to allow easy identification of devices.

Description

METHODS AND DEVICES FOR LOCATING AND PROVISIONING RFID DEVICES AND RELATED NETWORK DEVICES BACKGROUND OF THE INVENTION
1. Field of the Invention The present invention relates to provisioning RFID devices and related network devices.
2. Description of the Related Art
Bar codes containing a Universal Product Code ("UPC") have become a nearly ubiquitous feature of modern life. The vast majority of products, as well as packages, containers and other elements in the stream of commerce now bear a bar code to allow for convenient tracking and inventory control. However, bar codes have some drawbacks. Bar codes are "read only," in that they are merely a printed set of machine-readable parallel bars that cannot be updated. Bar codes cannot transmit information, but instead must be read by a scanner. Bar codes must be scanned within a relatively short distance and must be properly oriented for the bar code to be read. "Smart labels," generally implemented by RFID tags, have been developed in an effort to address the shortcomings of bar codes and add greater functionality. RFID tags have been used to keep track of items such as airline baggage, items of clothing in a retail environment, cows and highway tolls. As shown in Fig. 1, an
RFLD tag 100 includes microprocessor 105 and antenna 110. In this example, RFID tag 100 is powered by a magnetic field 145 generated by an RFID reader 125. The tag's antenna 110 picks up the magnetic signal 145. RFID tag 100 modulates the signal 145 according to information coded in the tag and transmits the modulated signal 155 to the RFID reader 125. RFID tags use the Electronic Product Code ("EPC" or "ePC") format for encoding information. An EPC code includes variable length bits of information (common formats are 64, 96 and 128 bits), which allows for identification of individual products as well as associated information. As shown in Fig. 1, EPC 120 includes header 130, EPC Manager field 140, Object class field 150 and serial number field 160. EPC Manager field 140 contains manufacturer information. Object class field 150 includes a product's stock-keeping unit ("SKU") number. Serial number field 160 is a 40-bit field that can uniquely identify the specific instance of an individual product i.e., not just a make or model, but also down to a specific "serial number" of a make and model. In theory, RFID tags and associated RFLD devices (such as RFLD readers and printers) could form part of a network for tracking a product (or a group of products) and its history. However, various difficulties have prevented this theory from being realized. One problem that has required considerable time and energy from RF engineers is the development of lower-cost RFID tags with acceptable performance levels. Inductively-coupled RFID tags have acceptable performance levels. These tags include a microprocessor, a metal coil and glass or polymer encapsulating material. Unfortunately, the materials used in inductively-coupled RFID tags make them too expensive for widespread use: a passive button tag costs approximately $1 and a battery-powered read/write tag may cost $100 or more. Capacitively-coupled RFID tags use conductive ink instead of the metal coil used in inductive RFID tags. The ink is printed on a paper label by an RFID printer, creating a lower-cost, disposable RFID tag. However, conventional capacitively- coupled RFID tags have a very limited range. In recent years, RF engineers have been striving to extend the range of capacitively-coupled RFLD tags beyond approximately one centimeter. In part because of the significant efforts that have been expended in solving the foregoing problems, prior art systems and methods for networking RFID devices are rather primitive. RFID devices have only recently been deployed with network interfaces. Device provisioning for prior art RFLD devices is not automatic, but instead requires a time-consuming process for configuring each individual device.
Prior art RFLD devices and systems are not suitable for large-scale deployment of networks of RFID devices. Conventional RFLD devices also have a small amount of available memory. A typical RFLD device may have approximately .5 Mb of flash memory and a total of 1 Mb of overall memory. The small memories of RFID devices place restrictions on the range of possible solutions to the problems noted herein. In addition, an RFID device typically uses a proprietary operating system, e.g., of the manufacturer of the microprocessor(s) used in the RFLD device. Moreover, many RFID devices are deployed in a hostile industrial environment (such as a warehouse or factory) by relatively unskilled "IT" personnel. If a device deployed in one location fails, for example, it may simply be removed and replaced by a functioning device that was deployed in another location. Moreover, RFID devices are being deployed with "static" knowledge of where the device was deployed at the original time of deployment. In practice, RFID devices are moved if another device is damaged or not functioning. In general, it is desirable to allow for the movement of RFLD devices. However, if an RFID device is moved, prior art systems do not know to what location the RFID device has been moved. It is becoming commonplace for devices, including but not limited to RFID readers, RFLD printers, VoIP telephones and devices used in manufacturing, to be deployed in large numbers within some networks. These devices often have unique characteristics, such as traffic type, bandwidth requirements, security demands, etc. Accordingly, such devices require specific network configurations, e.g., quality of service ("QoS"), security settings, NLANs or VSANs, etc. to properly support their desired functionality. Fig. 10 illustrates a portion of a network 1000, in which network device 1005 (in this example, a Catalyst™ switch provided by Cisco Systems, Inc.) is connected to a plurality of devices, including RFID reader 1010. In this example, RFID reader
1010 is connected to port 1020 via a fast Ethernet connection. For each port of network device 1005, a variety of attributes may be configured, such as QoS, security, port speed, description, etc. Within network 1000, a large number of devices and associated network devices may be deployed. In general, it is a tedious and time-consuming process for users to deploy devices and to manage the associated infrastructure components, such as switches and other network devices. For example, the process of configuring switch port settings is currently a manual process, in which each desired attribute must be individually selected and enabled for a port. This manual configuration process is currently inhibiting the deployment of large-scale RFID networks, manufacturing device networks, etc. It would be desirable to provide improved methods and devices that overcome at least some limitations of the prior art. SUMMARY OF THE INVENTION
Methods and devices are provided for identifying and provisioning individual RFLD devices in a network. According to some implementations of the invention, a combination of EPC code information and existing networking standards form the basis of identifying and provisioning methods. For example, MAC address information and EPC information can be combined to identify a particular device and its location in a network. Upper-level applications can be notified, for example, that a particular RFID device is available for use. For implementations using the Dynamic Host Configuration Protocol ("DHCP"), DHCP Options may be used to pass identification, location and provisioning information. For example, selected DHCP Options may be used to indicate whether a device is an RFLD device, to provide an EPC code uniquely identifying the particular device, indicating the company name using the device and indicating how the device is being used. Some such implementations of the invention use DHCPREQUEST and
DHCPL FORM (RFC 213I) and DHCP Options (RFCs 2132 and 3004) to pass current provisioning and personality information. Moreover, some such implementations of the invention use the DHCPFORCERENEW command (RFC 3203) from a DHCP server to initiate an update or to complete reconfiguration, as required. In order to secure the DHCPFORCERENEW command, some implementations provide for a cached secret to be hashed with a client EPC that is included with the DHCPREQUEST from the RFID device and the response from the DHCP server. Some implementations employ Domain Name Service ("DNS") and dynamic DNS ("DDNS") to allow easy identification of RFLD devices. Some aspects of the invention provide a method for uniquely provisioning a radio frequency identification ("RFLD") device. The method includes the following steps: receiving a provisioning request on a network; automatically identifying an RFID device according to a media access control ("MAC") address and an electronic product code ("EPC") included in the provisioning request; and automatically locating the RFID device according to location information included in the provisioning request. The method may be performed by a network device such as a Dynamic Host Configuration Protocol ("DHCP") server. The method may include the step of comparing information in the provisioning request with other information, in order to validate the RFLD device. The method may also include the steps of determining whether the RFLD device has previously booted and/or of determining whether provisioning information has previously been established for the RFLD device. The RFID device may be provisioned when it is determined that provisioning information has previously been established for the RFID device. The RFLD device may be categorized as an untrusted device if it is determined that provisioning information has not previously been established for the RFID device. Alternative aspects of the invention provide another method for uniquely provisioning an RFID device. The method includes the following steps: forming a DHCPDISCONER request that includes an EPC of an RFID device and location information indicating a location of the RFID device; sending the DHCPDISCONER request to a DHCP server; and receiving provisioning information from the DHCP server that is specifically intended for the RFID device. The forming step may involve including the EPC in an Option field (e.g., Option 61) of the DHCPDISCONER request. The forming step may involve including information (e.g., in Option 60) of the DHCPDISCONER request that indicates that the DHCPDISCONER request comes from an RFID device. The forming step may also involve including information in the DHCPDISCONER request that indicates a name of a company that provides, owns or operates the RFID device. Moreover, the forming step may involve including information (e.g., in Option 77) of the DHCPDISCONER request regarding the type of RFLD device that formed the DHCPDISCONER request. An RFLD device may include the EPC during a first part of the forming step.
A relay agent may include the location information in the DHCPDISCONER request during a second part of the forming step. Alternatively, the RFID device may include the location information in the DHCPDISCONER request. Some embodiments of the invention provide an RFLD device, including: a flash memory; a processor configured to form a DHCPDISCONER request that includes an EPC of an RFID device in Option 61, according to instructions in the flash memory; and a network interface for sending the DHCPDISCONER request to a DHCP server. Other embodiments of the invention provide a computer program embodied in a machine-readable medium, the computer program including instructions for controlling one or more elements of an RFID network to perform the following steps: form a DHCPDISCONER request that includes an EPC of an RFID device and location information indicating a location of the RFID device; send the
DHCPDISCONER request to a DHCP server; and receive provisioning information from the DHCP server that is specifically intended for the RFID device. Still other embodiments of the invention provide a computer program embodied in a machine-readable medium, the computer program including instructions for controlling a network device to perform the following steps: receive a provisioning request on a network; identify an RFID device according to a MAC address and an EPC included in the provisioning request; and locate the RFID device according to location information included in the provisioning request. Yet other aspects of the invention provide methods for deploying an RFID device in a network. One such method includes the following steps: forming a
DHCPDISCONER request that includes an EPC of an RFLD reader and location information indicating that the RFID reader is positioned at an exit door of a retail store; sending the DHCPDISCOVER request to a DHCP server; receiving provisioning information from the DHCP server that is specifically intended for the RFID reader; and provisioning the RFID reader according to the provisioning information, thereby enabling the RFID reader to read RFID tags passing through the exit door and to transmit RFID tag information to an RFID network. The RFID tag information may include product information and/or shopper information. The method may involve the step of using the RFID tag information to cause a financial account to be debited for the cost of the products. The RFID tag information may be used to automatically update a database maintained by the retail store and/or a database maintained by a manufacturer/producer, wholesaler and/or a distributor of at least one of the products. The RFID tag information may be used to update a business plan, such as a marketing, manufacturing, distribution or sales plan. Still other embodiments of the invention provide an RFID network, including: a plurality of RFID devices; a plurality of switches connecting the RFID devices to the RFED network; and a DHCP server. In some such embodiments, at least some of the RFLD devices are configured to do the following: form a DHCPDISCONER request that includes an EPC of an RFID device; send the DHCPDISCONER request to the DHCP server via a switch; and receive provisioning information from the DHCP server that is specifically tailored for the RFID device. The switch is configured to add location information to the DHCPDISCONER request indicating a location of the RFLD device. The DHCP server is configured to receive a DHCPDISCONER request, to automatically identify an RFID device according to a
MAC address and an EPC included in the DHCPDISCONER request and to automatically locate the RFLD device according to location information included in the DHCPDISCONER request. Methods and devices are also provided for identifying end devices and automatically configuring associated network settings. Preferred implementations of the invention do not require users to manually identify connection types (e.g., RFLD, EPphone, manufacturing device, etc.) or to manually configure the network device. Accordingly, such implementations allow automatic switch configuration, even for devices that use inconsistent protocols and/or protocols that are not well known. Some methods of the invention employ DHCP options combined with traffic snooping to identify devices and automatically apply appropriate switch port configuration. Some such implementations of the invention trigger Cisco Systems' SmartPorts™ software to configure ports of network devices. Some aspects of the SmartPorts software are described in United States Patent Application No. 10/896,410, filed July 21, 2004, which is hereby incorporated by reference.
However, the present invention is not limited to implementation via SmartPorts™; any convenient software for the automated configuring of network device ports may be used in accordance with the present invention. Some implementations of the invention provide a method for establishing network device port settings. The method includes the steps of receiving a
DHCPDISCONER request from a device and of determining, based on information in the DHCPDISCONER request, whether an appropriate macro is available to configure a port of a network device on which the DHCPDISCONER request was first received. The method may also include the step of applying the appropriate macro when it is determined to be available. The method preferably includes the step of determining whether the port has already been configured in a manner appropriate for the device. The determining step may involve determining a device personality, identifying the device and/or examining at least one DHCP option or other component of the DHCPDISCONER request. The "other component" could be, for example, one or more parts of the DHCP message header. The determining step may or may not be performed by the network device on which the DHCPDISCONER request was first received. For example, the DHCPDISCONER request may first be received by a switch port and the determining step may be performed by one of a DHCP server, an edge services management server, an authentication server and a device dedicated to port configuration.. Some embodiments of the invention provide at least one apparatus for establishing network device port settings. Such embodiments include a port for receiving a DHCPDISCONER request from a device and at least one logic device configured for determining, based on information in the DHCPDISCONER request, whether an appropriate macro is available to configure the port. A logic device may examine one or more DHCP options of the
DHCPDISCONER request. The port and the logic device(s) may be included within a single device or may be disposed in separate devices. For example, the port and the logic device(s) may be included within a single switch or a DHCP server. Alternative embodiments of the invention provide a network device that includes these elements: a plurality of ports; a storage device; and at least one logic device configured to receive a DHCPDISCONER request from a device via a first port and configure the first port with appropriate configuration parameters for the device. A logic device may be further configured to forward a copy of the DHCPDISCONER request to a second device. A logic device may configure the first port according to instructions received from the second device. The second device may be, for example, a DHCP server, an edge services management server, an authentication server or a device dedicated to port configuration. The methods of the present invention may be implemented, at least in part, by hardware and/or software. For example, some embodiments of the invention provide computer programs embodied in machine-readable media. The computer programs include instructions for controlling one or more devices to perform the methods described herein. BRIEF DESCRIPTION OF THE DRAWINGS
Fig. 1 is a diagram illustrating an RFLD tag. Fig. 2 illustrates an exemplary RFID network according to the present invention. Fig. 3 is a block diagram of an exemplary RFID reader that may be configured to perform some methods of the present invention. Fig. 4 is a block diagram of an exemplary RFID printer that may be configured to perform some methods of the present invention. Fig. 5 is a block diagram of an exemplary RFID system that may be configured to perform some methods of the present invention. Fig. 6 is a flow chart that provides an overview of some methods of the present invention. Fig. 7 is a flow chart that provides an overview of alternative methods of the present invention. Fig. 8 is a flow chart that provides an overview of some implementations of the present invention. Fig. 9 illustrates an example of a network device that may be configured to implement some methods of the present invention. Fig. 10 is a network diagram illustrating a switch and attached RFID devices. Fig. 11 A illustrates an exemplary SmartPorts™ macro. Fig. 1 IB illustrates an exemplary set of commands to be used for configuring a port according to a SmartPorts™ macro. Fig. 12A is a flow chart that provides an overview of a method of the present invention. Fig. 12B is a network diagram that illustrates an implementation of the method outlined in Fig. 12 A. Fig. 13 is a flow chart that provides an overview of an alternative method of the present invention. Fig. 14 is a block diagram that illustrates a network device for implementing some aspects of the invention. DETAILED DESCRIPTION OF THE INVENTION
In this application, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be obvious, however, to one skilled in the art, that the present invention may be practiced without some or all of these specific details. In other instances, well known process steps have not been described in detail in order not to obscure the present invention. Although the present invention involves methods and devices for identifying and provisioning individual RFID devices in a network, many aspects of the present invention can be applied to identifying and provisioning other types of devices in a network. Similarly, although much of the discussion herein applies to implementations using the DHCP protocol, the present invention is not protocol- specific and maybe used, for example, in implementations using UPnP, 802. lab or similar discovery protocols. Likewise, while the implementations described herein refer to exemplary DHCP Options, other DHCP Options may advantageously be used to implement the present invention. RFLD devices perform different functions and may interface to the upstream systems differently depending on where they are located. The functions they perform, as well as the unique settings to perform those functions, will be referred to herein as the device "personality." As used herein, "provisioning" a device can include, but is not limited to, providing network configuration, providing personality configuration, incorporating the device into a network database and enabling the device with software (e.g., business process software). The methods and devices of the present invention have very broad utility, both in the public and private sectors. Any enterprise needs to keep track of how its equipment is being deployed, whether that equipment is used for commercial purposes, for military purposes, etc. RFJD devices that are networked according to the present invention can provide necessary information for allowing enterprises to track equipment and products (or groups of products). The information that will be provided by RFID devices that are networked according to the present invention will be of great benefit for enterprise resource planning, including the planning of manufacturing, distribution, sales and marketing. Using the devices and methods of the present invention, RFLD tags and associated RFID devices (such as RFID readers and printers) can form part of a network for tracking a product and its history. For example, instead of waiting in a checkout line to purchase selected products, a shopper who wishes to purchase products bearing RFID tags can, for example, transport the products through a door that has an RFID reader nearby. The EPC information regarding the products can be provided to an RFID network by the reader and can be used to automatically update a store inventory, cause a financial account to be debited, update manufacturers', distributors' and retailers' product sales databases, etc. Read/write RFID tags can capture information regarding the history of products or groups of products, e.g., temperature and other environmental changes, stresses, accelerations and/or vibrations that have acted upon the product. It will be particularly useful to record such information for products that relatively more subject to spoilage or other damage, such as perishable foods and fragile items. By using the methods of the present invention, this information will be used to update databases maintained by various entities (e.g., manufacturers, wholesalers, retailers, transportation companies and financial institutions). The information will be used not only to resolve disputes (for example, regarding responsibility for product damage) but also to increase customer satisfaction, to avoid health risks, etc. Some aspects of the invention use a combination of EPC code information and modified versions of existing networking standards for identifying, locating and provisioning RFID devices, such as RFID readers and RFID printers, that are located in a network. An example of such a network is depicted in Fig. 2. Here, RFID network 200 includes warehouse 201, factory 205, retail outlet 210, financial institution 215 and headquarters 220. As will be appreciated by those of skill in the art, network 200 could include many other elements and/or multiple instances of the elements shown in Fig. 2. For example, network 200 could include a plurality of warehouses, factories, etc. In this illustration, products 227 are being delivered to warehouse 201 by truck 275. Products 227, which already include RFED tags, are delivered through door 225. In this example, RFID reader 252 is connected to port 262 of switch 260. Here, switches 230 and 260 are connected to the rest of RFLD network 200 via gateway 250 and network 225. Network 225 could be any convenient network, but in this example network 225 is the Internet. RFID reader 252 reads each product that passes through door 225 and transmits the EPC code corresponding to each product on RFLD network 200. RFID tags may be used for different levels of a product distribution system. For example, there may be an RFID tag for a pallet of cases, an RFID tag for each case in the pallet and an RFID tag for each product. Accordingly, after products 227 enter warehouse 201, they are assembled into cases 246. RFLD printer 256 makes an RFLD tag for each of cases 246. In this example, RFID printer 256 is connected to port 266 of switch 260. RFID printer 256 could operate under the control of PC 247 in warehouse 201, one of PCs 267 in headquarters 220, or some other device. RFID reader 224, which is connected to port 214, reads the EPC code of each case 246 and product 227 on conveyor belt 244 and transmits this information on network 200. Similarly, RFLD reader 226, which is connected to port 216, reads the
EPC code of each case 246 and product 227 that exits door 204 and transmits this information on network 200. Cases 246 are loaded onto truck 285 for distribution to another part of the product chain, e.g., to retail outlet 210. Each of the RFID devices in network 200 preferably has a "personality" suitable for its intended use. For example, device 252 could cause reassuring tone to sound and/or a green light to flash if an authorized person or object enters door 225. However, device 252 might cause an alarm to sound and/or an alert to be sent to an administrator on network 200 if a product exits door 225 or an unauthorized person enters or exits door 225. Fig. 3 illustrates an RFID reader that can be configured to perform methods of the present invention. RFID reader 300 includes one or more RF radios 305 for transmitting RF waves to, and receiving modulated RF waves from, RFID tags. RF radios 305 provide raw RF data that is converted by an analog-to-digital converter (not shown) and conveyed to other elements of RFID reader 300. In some embodiments, these data are stored, at least temporarily, by CPU 310 in memory 315 before being transmitted to other parts of RFID network 200 via network interface 325. Network interface 325 may be any convenient type of interface, such as an Ethernet interface. Flash memory 320 is used to store a program (a "bootloader") for booting/initializing RFID reader 300. The bootloader, which is usually stored in a separate, partitioned area of flash memory 320, also allows RFLD reader 300 to recover from a power loss, etc. In some embodiments of the invention, flash memory 320 includes instructions for controlling CPU 310 to form "DHCPDISCONER" requests, as described below with reference to Fig. 6, to initiate a provisioning/configuration cycle. In some implementations, flash memory 320 is used to store personality information and other configuration information obtained from, e.g., a DHCP server during such a cycle. However, in preferred implementations, such information is only stored in volatile memory 415 after being received from, e.g. a DHCP server. There are advantages to keeping RFED devices "dumb." For example, a network of dumb RFID devices allows much of the processing load to be centralized (e.g., performed by server 270 of network 200), instead of being performed by the RFID devices. Alternatively, the processing load can be decentralized, but only to trusted devices (such as PC 247 of network 200). Configuration information is downloaded from, e.g., a central server to memory 315. Updates may be instigated by the central server or selected, trusted devices. New versions of the image file (e.g., the running, base image necessary to operate the RFID device) are copied into flash memory 320. Alternative embodiments of RFLD devices implement the methods of the present invention yet lack flash memory. Newer RFID devices also include dry contact input/output leads to connect to signal lights, industrial networks or the equivalent. These newer RFLD devices typically have evolved in the amount of memory, flash, CPU capacity and methods of determination of the number, type and content of RFID tags in their field of view. Fig. 4 is a block diagram illustrating an exemplary RFID printer 400 that may be configured to perform some methods of the present invention. RFID printer 400 has many of the same components as RFID reader 300 and can be configured in the same general manner as RFID reader 300. RFID printer also includes printer interface 430, which may be a standard printer interface. Printer interface prints a label for each RFID tag, e.g. according to instructions received from network 200 via network interface 425. RF Radio 405 is an outbound radio that is used to send RF signals to the antenna of an RFED tag under the control of CPU 410, thereby encoding information (e.g. an EPC) on the tag's microprocessor. Preferably, RF Radio 405 then checks the encoded information for accuracy. The RFID tag is sandwiched within the label produced by printer interface 430. Fig. 5 illustrates RFED system 500 that includes control portion 501 and RF radio portion 502. The components of control portion 501 are substantially similar to those described above with reference to Figs. 3 and 4. Interconnect 530 of control portion 501 is configured for communication with interconnect 535 of RF radio portion 502. The communication may be via any convenient medium and format, such as wireless, serial, point-to-point serial, etc. Although only one RF radio portion 502 is depicted in Fig. 5, each control portion 501 may control a plurality of RF radio portions 502. RFID system 500 may be deployed on a single framework or chassis (e.g., on a forklift) or in multiple chassis. The DHCP protocol is used in some preferred implementations of the present invention because it offers various convenient features. For example, the DHCP protocol allows pools or "scopes" of TCP/IP addresses to be defined. A DHCP server can temporarily allocate or "lease" these TCP/IP addresses to host devices. An IP address that is not used for the duration of the lease is returned to the pool of unallocated IP addresses. In addition, the DHCP server will provide all related configuration settings, such as the default router, Domain Name Service ("DNS") servers, subnet mask, etc., that are required for the proper functioning of TCP/IP. For implementations using the DHCP protocol, DHCP Options may be used to pass provisioning information. The DHCP protocol is defined in RFC 2131 and DHCP Options are set forth in, for example, RFCs 2132, 3004 and 3046. RFCs 2131, 2132, 3004 and 3046 are hereby incorporated by reference for all purposes. In some preferred implementations, an EPC corresponding to an RFED device is put inside a DHCP request sent from the RFED device to a DHCP server. The EPC uniquely identifies the RFED device. Some implementations employ Domain Name Service ("DNS") and dynamic DNS ("DDNS") to allow yet easier identification of RFED devices. An overview of some such implementations of the present invention will now be described with reference to Fig. 6. A device that sends out an initiation for an EP address to a DHCP server does so by way of a packet that includes a "DHCPDISCONER" request. This command includes the media access control ("MAC") address of the device. According to some preferred implementations, the RFID device (e.g., CPU 310 of RFID Reader 300) forms a "DHCPDISCONER" request packet that includes information in various DHCP Option fields (step 601). The RFID device encodes DHCP "class identifier" Option 60 with a code indicating that the device is an RFED device. In other words, "RFED" will be a new type of "class," encoded in Option 60. In this example, the RFED device encodes its own EPC in the field reserved for Option 61, The RFED device also encodes a company name, e.g., of the company that supplies, owns or is using the RFED device, in DHCP Option 43. Option 77 may be used in various ways according to different implementations of the invention. In some implementations, Option 77 will be used to indicate the type of RFED device, e.g., that the RFED device is an RFED reader or an RFED printer, hi some implementations, Option 77 can also include information regarding the functionality or "personality" of the RFED device. For example, Option 77 could indicate that the RFED device is an inbound RFED reader, an outbound RFED reader, an RFED reader or printer on an assembly line, a retail store, etc. Referring once again to Fig. 2, if the request is from RFED device 252, that device would encode information in Option 77 indicating that the device is an RFED reader, h some implementations, Option 77 also indicates that RFED device 252 has a personality suitable for being positioned at an entrance door. Some implementations include more detailed information about the current personality of device 252. For example, Option 77 may indicate that in addition to reading EPC codes and uploading them to the RFED network, device 252 will also cause a green light to flash if an authorized person or object enters door 225 and will cause a red light to flash, an alarm to sound and an alert to be sent to an administrator on the network if a product exits door 225. This information could be encoded, for example, according to a number that corresponds to one of a range of suitable personalities for an RFED reader at an entrance door. It is desirable to determine and provide location information for RFED devices in a network. Switches and wireless bridges with Ethernet or switch ports are considered static and have assigned names and locations. According to some implementations of the invention, location information is added, for example to an RFLD device's DHCPDISCONER request, by the network device to which the RFED device is attached (step 610). Some such implementations use DHCP Option 82 (RFC 3046) in a new way to determine the switch port and switch to which an RFED device is connected. For example, a switch may insert the following two information elements into any DHCP request from an attached RFED device: Option 82, Sub-Option 1 : Agent Circuit ED and Option 82, Sub-Option 2: Agent Remote ED. The Agent Circuit ED is the name or identifier of the switch. The Agent Remote ED is the name or identifier of the switch port. For example, if the request is from RFED device 226 of Fig. 2, network device 230 adds location information to the request in step 610. Here, the location information would be encoded in Option 82 and would include information identifying network device 230 and port 216, to which RFED reader 226 is attached. In alternative embodiments wherein the RFED device is capable of determining its own location (e.g., from GPS coordinates), the RFED device may encode location information in the DHCPDISCONER request or in other commands. There can be multiple DHCP servers serving the same network. How the servers respond can depend, for example, on whether each server is busy, whether it has served out all its addresses, etc. As RFED pilot networks emerge and develop, they will be interleaved with existing networks, including networks that employ the DHCP protocol. DHCP servers that are provisioning RFED devices (e.g. server 270 of Fig. 2) will respond to "DHCPDISCONER" commands identifying a class of the device as "RFED," e.g., encoded in Option 60. Those of skill in the art will appreciate that other Options may be used for this purpose. Conversely, DHCP servers that are not provisioning RFED devices will not respond to "DHCPDISCONER" commands identifying a class of the device as "RFED." Further, if a non-RFED DHCP server does respond, the RFED device will be able to determine from the DHCP options response that it has received an incomplete DHCP response and will discard it and will prefer responses from RFED DHCP servers. Accordingly, the methods of the present invention allow for the integration of RFID networks within the existing framework of the DHCP protocol. In step 615, the DHCP server determines whether there is information regarding the requesting device within a database of information regarding known RFED devices, their intended functions, configurations, etc. For example, the DHCP server may inspect the EPC encoded in a request and determine whether there is information for a device with a corresponding EPC in the database. If so, in step 620, the server compares information in the DHCP request with stored information regarding the RFED device. This information may be in a database (e.g., stored in one of storage devices 265) that is updated, for example, by IT personnel responsible for the RFED network. For example, MAC address information and EPC information can be combined to identify a particular device and its location in a network. Upper-level applications can be notified, for example, that a particular RFED device is available for use. By inspecting the received data, the server can then determine the type, identity, location and personality (if any) of the RFED device. By comparing the received data with information in the database, the server can then determine, for example, if that precise RFED device has moved and where it is now located. In preferred implementations, the DHCP server may determine the current personality of the RFED device (e.g., by inspecting the Option 77 data) and may compare the current personality with a desired personality. In step 625, the DHCP server provides the RFED device with configuration information, etc., indicated in the database. For example, the DHCP server may indicate the RFED device's time server, SYSLOG server, the location of the device's configuration files, image files, etc. If the RFED device's current personality does not match the desired personality (or if the request does not indicate a current personality), according to some implementations the DHCP server can provide the device with information (e.g., a computer program, configuration settings, etc.) for enabling the desired personality. For example, suppose that the EPC code indicates that the device is RFED reader 252 and Option 77 indicates that RFED device 252 has a personality suitable for being positioned at an entrance door. However, the location information in the request may indicate that the requesting device has been moved and is now located at an exit door. Alternatively, the database may indicate that the device is positioned at a door that has been used as an entrance door, but which now will be used as an exit door. This may be a periodic (e.g. hourly, daily, weekly, or monthly) change at a manufacturing facility or warehouse, or may be due to a reconfiguration of the facility. Therefore, the desired personality for RFED device 252 is now a personality appropriate for an exit door. However, there may be a range of different "exit door" personalities that could be provided to device 252 depending, for example, on the capabilities of the device making the request, the expected uses of the exit door, etc.
For example, a device with fewer capabilities (e.g., a smaller memory) may be enabled for relatively simpler exit door functionality. For example, such a device may be enabled to, e.g., make a green light flash when particular type of product is exiting the door and to transmit a notification message to IT personnel and/or cause an alarm to sound if other items are exiting the door. However, a device with greater capabilities may be enabled for relatively more complex exit door functionality. For example, the device could be enabled to cause a green light to flash if a particular type of product is exiting at an expected time, if the number of products exiting the door is within a predetermined range, etc. This flexibility in reassigning device personality allows an RFED network to cause the same device type to have multiple personalities based upon location, time of day, or any other suitable criteria. Moreover, this flexibility allows for movement or relocation of devices (whether or not this movement has been approved in advance) and then having devices automatically "repersonalized," as appropriate for the new location. In addition, it allows for specialized functionality on a per device, per locale basis. However, in some circumstances there may be no information in the database regarding the device. For example, the device may be a new RFED device that has just been activated in the RFED network for the first time (step 630). In this example, the device is placed in a "walled garden" for devices that are not trusted devices. Step 630 may involve assigning the device a non-routable EP address for a predetermined length of time via a DHCPOFFER command. According to some implementations, the DHCP server performs step 630 when there is information in the database regarding the device that is inconsistent with information in the request. Preferably, step 630 includes notifying an upper-layer application that the device has made the request. In this way, IT personnel responsible for the site within which the RFED device is located will be notified that the RFED device exists and has made a request. According to some implementations, step 630 involves setting the DHCP Tl timer for a short time interval, for example, 60 seconds. In this example, the RFED device will continue to send DHCP requests to the server every 60 seconds and the server will send "ACKs" to the device until one of two events occurs: (1) the server has been updated (e.g., by IT personnel responsible for the site within which the
RFID device is located); or (2) the connection between the server and the RFID device goes down. (Step 635.) If the server is updated within the predetermined time, this indicates that an IT person has determined that the RFID device making the request is a trusted device. Accordingly, the method proceeds to step 625. If not, the device remains classified as an untrusted device (step 630). Preferably, the device's status may still be changed to that of a trusted (and therefore provisioned) device, e.g., according to subsequent input from IT personnel. After an initial provisioning configuration cycle (e.g., as described above),
RFED devices may need to be reprovisioned or have their personalities changed. As noted above, it is desirable for an RFED device to take on unique provisioning and personalities depending on the desired functionality of the RFED device at a particular time. The desired functionality may be determined according to the location and capabilities of the RFED device. Some devices may be provided with the same personality for a relatively longer time, e.g., months or years. However, it may be desirable to change the personality and/or provisioning information of an RFED device in a relatively shorter time, e.g., prior to the time that a DHCP Tl timer expires. The majority of currently-deployed RFED end devices do not support RFC 3203 (DHCP Reconfigure Extension). The present invention encompasses a variety of methods for accomplishing these goals. One such method will now be described with reference to Fig. 7. Method 700 begins with a determination of whether to send information to a network device regarding the current personality of the RFED device (step 701). Here, the RFED device will send the information to a DHCP server if a predetermined period of time has elapsed. In this example, the predetermined period of time is one hour, but it could be any convenient period of time. If it is time for another DHCPREQUEST or DHCPLNFORM request to be sent to the DHCP server, the RFED device forms the request (step 705). If not, the current personality is maintained (step 702). In this example, the information will be sent in a DHCP request (RFC 2131) combined with DHCP Option 61 set to the RFLD device's EPC (or equivalent) and Option 77 set to the RFED device's current personality. Using DHCPLNFORM and DHCP Options, the RFED device is able to pass current identification, provisioning and personality information. In this example, a cached secret (e.g., hashed with the contents of the DHCP message, including the client EPC) will be included with the DHCP request in order to secure the response. The secret could be provided, for example, during an earlier provisioning stage, e.g., the initial provisioning stage of the RFED device. The secret could be used in the DHCPLNFORM validation process and for other processes. The request is sent in step 710. Preferably, a relay agent updates the request with location information, as described above (step 715). In step 720, the server compares the information in the request with stored information (e.g., in a lookup table or a database) to determine whether an update or a complete reconfiguration of the RFED device is required. If not, the process returns to step 701. If so, the server provides the RFED device with the necessary update and/or reconfiguration information (step 725). The RFED device triggers the update and/or reconfiguration determination in the foregoing example. However, in other implementations, another device (e.g., the DHCP server) and/or a person initiates this determination. For example, the DHCP server could initiate a periodic process of comparing a desired RFED device personality with the last known RFED device personality. Alternatively, an IT worker could send information (e.g., to the DHCP server, to the RFED device or to another device) indicating a desired change in personality. According to some implementations of the invention, a DHCP server causes an update or a complete reconfiguration using a DHCPFORCERENEW command as defined by RFC 3203, which is hereby incorporated by reference in its entirety. The CPU of the RFED device registers the ForceRenew command and starts a new provisioning cycle, for example as described above with reference to Fig. 6. In order to secure the command, in this example a cached secret is hashed within the command. For example, the secret can be included with the EPC code of the RFED device. One method for creating an authentication key is as follows: MD-5 (EPC, Challenge, Secret) By adding in the variable of a random Challenge, no replay attacks of the hash code could be used. Because the EPC is included, the authentication can be further validated to come from a specific device. The foregoing methods allow for unique determination and provisioning of RFED devices by time of day, not simply by device "type," "class" or "location." Moreover, the foregoing methods allow for ongoing verification/auditing of what the end device roles are. In addition, these methods allow operation managers to have enterprise resource planning systems control end devices to allow for increased functionality. Fig. 8 is a flow chart that illustrates an exemplary business application of the present invention. Those of skill in the art will appreciate that the example described below with reference to Fig. 8 is but one of many applications of the invention. In step 805, an RFED device has already been provisioned according to one of the previously-described methods. The condition of the RFED device is comparable to that of a device at step 640 in method 600, shown in Fig. 6 and described above. In this example, the RFLD device is an RFED reader that is positioned near an exit door of a retail store. Therefore, in the previous steps, the device has been provisioned with a personality that is appropriate for its role. In step 810, a shopper exits the door with a number of selected products. In step 815, the RFED reader reads the RFED tags of each product and extracts the EPC codes and related product information (e.g., the price of each product). The RFED reader also reads an RFED tag that identifies the shopper and the shopper's preferred account(s) that should be debited in order to purchase the products. For example, the shopper may have an RFED tag embedded in a card, a key chain, or any other convenient place in which this information is encoded. The accounts may be various types of accounts maintained by one or more financial institutions. For example, the accounts may be one or more of a checking account, savings account, a line of credit, a credit card account, etc. Biometric data (e.g., voice, fingerprint, retinal scan, etc.) from the shopper may also be obtained and compared with stored biometric data in order to verify the shopper's identity. In step 820, the RFED reader transmits the product information, including the EPC codes, on the RFED network. In this example, the information is first sent to a financial institution indicated by the shopper's RFED tag. Ln step 825, the financial institution that maintains the shopper's selected account determines whether there are sufficient funds (or whether there is sufficient credit) for the shopper to purchase the selected products. If so, the shopper's account is debited and the transaction is consummated (step 830). In this example, the shopper has the option of designating one or more alternative accounts. Accordingly, if the first account has insufficient funds or credit, it is determined (e.g., by a server on the RFED network) whether there the shopper has indicated any alternative accounts for making purchases (step 835). If so, the next account is evaluated in step 825. If it is determined in step 835 that there are no additional accounts designated by the shopper, in this example some form of human intervention takes place. For example, a cashier of the retail store could assist the shopper in making the purchases in a conventional manner. If some or all of the products are purchased, information regarding the purchased products (including the EPC codes) are transmitted on the RFED network. For example, this information is preferably forwarded to one or more devices on the
RFED network that are configured to update one or more databases maintained by the retail store or the manufacturers/producers, distributors, wholesalers, etc., of the purchased products (step 840). In some implementations, information regarding the shopper is also transmitted on the RFED network (e.g., if the shopper has authorized such information to be released). This product information (and optionally shopper information) may be used for a variety of purposes, e.g., in the formation of various types of business plans (e.g., inventory re-stocking, marketing, sales, distribution and manufacturing/production plans). Fig. 9 illustrates an example of a network device that may be configured to implement some methods of the present invention. Network device 960 includes a master central processing unit (CPU) 962, interfaces 968, and a bus 967 (e.g., a PCI bus). Generally, interfaces 968 include ports 969 appropriate for communication with the appropriate media. In some embodiments, one or more of interfaces 968 includes at least one independent processor 974 and, in some instances, volatile RAM. Independent processors 974 may be, for example ASICs or any other appropriate processors. According to some such embodiments, these independent processors 974 perform at least some of the functions of the logic described herein. In some embodiments, one or more of interfaces 968 control such communications-intensive tasks as media control and management. By providing separate processors for the communications-intensive tasks, interfaces 968 allow the master microprocessor 962 efficiently to perform other functions such as routing computations, network diagnostics, security functions, etc. The interfaces 968 are typically provided as interface cards (sometimes referred to as "line cards"). Generally, interfaces 968 control the sending and receiving of data packets over the network and sometimes support other peripherals used with the network device 960. Among the interfaces that may be provided are Fibre Channel ("FC") interfaces, Ethernet interfaces, frame relay interfaces, cable interfaces, DSL interfaces, token ring interfaces, and the like. In addition, various very high-speed interfaces may be provided, such as fast Ethernet interfaces, Gigabit Ethernet interfaces, ATM interfaces, HSSI interfaces, POS interfaces, FDDI interfaces, ASI interfaces, DHEI interfaces and the like. When acting under the control of appropriate software or firmware, in some implementations of the invention CPU 962 may be responsible for implementing specific functions associated with the functions of a desired network device.
According to some embodiments, CPU 962 accomplishes all these functions under the control of software including an operating system (e.g. Linux, Nx Works, etc.), and any appropriate applications software. CPU 962 may include one or more processors 963 such as a processor from the Motorola family of microprocessors or the MIPS family of microprocessors. In an alternative embodiment, processor 963 is specially designed hardware for controlling the operations of network device 960. In a specific embodiment, a memory 961 (such as non- volatile RAM and/or ROM) also forms part of CPU 962. However, there are many different ways in which memory could be coupled to the system. Memory block 961 may be used for a variety of purposes such as, for example, caching and/or storing data, programming instructions, etc. Regardless of network device's configuration, it may employ one or more memories or memory modules (such as, for example, memory block 965) configured to store data, program instructions for the general-purpose network operations and/or other information relating to the functionality of the techniques described herein. The program instructions may control the operation of an operating system and/or one or more applications, for example. Because such information and program instructions may be employed to implement the systems/methods described herein, the present invention relates to machine-readable media that include program instructions, state information, etc. for performing various operations described herein. Examples of machine-readable media include, but are not limited to, magnetic media such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROM disks; magneto-optical media; and hardware devices that are specially configured to store and perform program instructions, such as read-only memory devices (ROM) and random access memory (RAM). The invention may also be embodied in a carrier wave traveling over an appropriate medium such as airwaves, optical lines, electric lines, etc. Examples of program instructions include both machine code, such as produced by a compiler, and files containing higher level code that may be executed by the computer using an interpreter. Although the system shown in Fig. 9 illustrates one specific network device of the present invention, it is by no means the only network device architecture on which the present invention can be implemented. For example, an architecture having a single processor that handles communications as well as routing computations, etc. is often used. Further, other types of interfaces and media could also be used with the network device. The communication path between interfaces/line cards may be bus based (as shown in Fig. 9) or switch fabric based (such as a cross-bar). Some exemplary implementations of the invention involve using the
SmartPorts™ "macro" functionality for configuring ports of network devices. However, other such tools could be used. In other implementations of the invention, a command line interface ("CLI") or another programmatic interface such as Simple Network Management Protocol ("SNMP") or Netconf® is used for this purpose. Prior implementations of SmartPorts™ macros required users to manually identify connection types (e.g., RFLD, manufacturing, EPphone) and then to configure a network device according to the identified connection type. As used herein, the term "macro" will sometimes be used to mean both the commands used to configure, e.g., a port of a network device and a configuration resulting from the application of such a macro. The network device could be configured, for example, using a command line interface or a network management tool such as CMS on a per-port basis. An exemplary Cisco SmartPorts™ macro for configuring a port for an RFID device will now be described with reference to Fig. 11 A. Line 1101 is used to establish the macro's name, which in this case is RFED_Macrol. It is helpful to use a name that is easy to recognize as one type of macro for RFED devices, to allow for the possibility of having macros for multiple device types and multiple macros for RFED devices. Line 1103 will cause an RFED VLAN to be assigned and line 1105 puts a switch port in "access" mode. Line 1107 assigns a generic description to the interface indicating its use, which is a connection to an RFID device in this example. Lines 1109 enable port security and limit the port to a single media access control ("MAC") address. According to line 1111, when the maximum number of MAC addresses is exceeded, traffic from additional source MAC addresses are dropped. In addition, an SNMP trap and a syslog message are generated. Lines 1113 cause the secure MAC address to age out after 10 minutes of inactivity. Lines 1115 configure the port as an edge device port that does not need to behave according to a spanning tree protocol. Accordingly, bridge port data unit ("BPDU") packets are not be allowed to enter the network from this port. "Spanning- tree portfast" allows the port to move into the forwarding state quickly. Lines 1117 set broadcast and multicast storm control limits to 20% of the interface bandwidth. As with other settings in this example, this limit should be based upon the anticipated requirements of the device to be in communication with the port. Line 1119 applies a rate limiting of DHCP packets coming from the device to 100 packets per second. Line 1121 is one example of a QoS for the device. This QoS is applicable, for example, if the device is an RFED reader that sends packets marked with DSCP and if these values should be trusted. Fig. 1 IB sets forth one example of how to apply the previously-described SmartPorts macro to a switch port. Fig. 1 IB is a screen capture of a CLI session for configuring a port. Line 1151 identifies the switch to be configured ("DC_Switchl"). Line 1155 is a prompt from switch DC_Switchl. Line 1160 configures the interface as a Fast Ethernet interface. Line 1165 applies a selected macro, which is "RFED_Macrol" in this example, to the interface. The example assumes that VLAN 30 has previously been configured as the RFED VLAN. Line 1170 is a command prompt from switch DC Switchl. Referring back to Fig.10, for example, in order to configure port 1020 using prior implementations of SmartPorts, a user (e.g., a network administrator) would need to manually go into every port, select a macro for each device (if one exists) and apply the appropriate macro to the port to which the device is connected. For example, the user would need to determine the appropriate port configuration for a connection with RFED reader 1010, determine whether a macro exists for this configuration, and, if so, apply the appropriate macro to configure port 1020. If no such macro existed, each attribute of the port configuration would need to be separately indicated. Some exemplary implementations of the invention will now be described with reference to Figs. 12A and 12B. Fig. 12A is a flow chart that outlines method 1200 according to the invention. Fig. 12B is a simplified network diagram of network 1250 that provides one example of how method 1200 may be implemented. Those of skill in the art will appreciate that some steps of the methods discussed herein, including method 1200, need not be performed (and in some implementations are not performed) in the order shown. Moreover, some implementations of the methods discussed herein may include more or fewer steps than those shown, e.g., in Fig. 12A. Similarly, those of skill in the art will appreciate that the elements of Fig. 12B are both simplified and merely illustrative. Fig. 12B illustrates switches 1265, 1280 and 1285, all of which have attached devices. In this example, switch 1265 is a Cisco Catalyst 4500 Series switch and switches 1280 and 1285 are Cisco Catalyst 3750 Series switches. However, one of skill in the art will appreciate that other types of network devices could be used to implement the invention. Moreover, switches 1265,
1280 and 1285 could be in the same location (e.g., in the same warehouse or factory) or could be in different locations. Switches 1265, 1280 and 1285 can commumcate with DHCP server 1270, host device 1290 and storage devices 1295 via network 1275. Accordingly, network 1275 may include portions of one or more private networks and part of the Internet. The devices attached to switches 1265, 1280 and 1285 are not necessarily all of the same type. In this example, device 1255 is an RFED reader and device 1257 is an EP telephone. As discussed elsewhere herein, even devices that are of the same general type may have different capabilities and/or different desired functions. A device that sends out an initiation for an EP address to a DHCP server does so by way of a packet that includes a "DHCPDISCONER" request. This command includes, inter alia, the media access control ("MAC") address of the device. RFC 2131 is hereby incorporated by reference. Accordingly, in step 1201 of method 1200, device 1255 of Fig. 12B initializes and then sends DHCPDISCONER request 1256 to port 1260 of switch 1265. Switch
1265 is configured not only to forward DHCPDISCONER request 1256 to DHCP server 1270 via network 1275, but also to analyze the contents of DHCPDISCONER request 1256. The steps performed by switch 1265 according to method 1200 may be controlled by one or more logic devices 1268, which is an ASIC in this example. However, logic device(s) 1268 could be any convenient logic device(s). In step 1215, switch 1265 attempts to identify device 1255 according to information in DHCPDISCONER request 1256. In this example, switch 1265 applies "snooping" techniques to analyze the contents of Options in DHCPDISCONER request 1256. Switch 1265 may, for example, examine the contents of DHCP Option 60 to determine a device type or vendor identifier. RFC 2132 is hereby incorporated by reference. Switch 1265 may examine the "Enterprise number" field of DHCP Option 125 to determine the EPCGlobal enterprise number of the device. RFC 3925 is hereby incorporated by reference. Alternatively, or additionally, switch 1265 may examine other DHCP options. For example, switch 1265 may examine DHCP Option 150 to identify device 1255; this Option is used, for example, by EPPhones provided by Cisco Systems, Inc. R. Johnson's draft "TFTP Server Address DHCP Option" (Network Working Group Feb. 6, 2005) describes relevant information and is hereby incorporated by reference.
Switch 1265 may examine a "PXE boot" option to determine an appropriate configuration for port 1260. M. Johnston's draft "DHCP Preboot execution Environment (PXE) Options" (Dynamic Host Configuration Working Group Jan. 21, 2005) describes relevant information and is hereby incorporated by reference. Switch 1265 may examine Option 43 to obtain vendor-specific information regarding device
1255. Switch 1265 may examine Option 61 to determine an EPC identifier of device 1255. In some implementations, switch 1265 also determines an appropriate personality for device 1255 in step 1215. In some such implementations, switch 1265 examines the DHCP Option 77 to determine a device personality. In other implementations, switch 1265 can determine an appropriate personality for device 1255 indirectly, e.g., by cross-referencing a look-up table or a similar data structure based on other information in DHCPDISCONER request 1256. The look-up table could be stored locally (e.g., in memory 1267), on an attached device or on another device that switch 1265 can access via network 1275, part of which is the Internet in this example. If switch 1265 cannot identify device 1255, the process ends in this example (step 1240 of Fig. 12A). Alternatively (or additionally), a network administrator could be alerted, e.g., by causing switch 1265 to send a message to host device 1290. However, if switch 1265 can identify the device, the method proceeds to step 1220, wherein switch 1265 determines port 1260 is already configured. (In the flow chart of Fig. 12A it is presumed that a port configuration (if any) has resulted from the application of a macro, though this need not be the case.) If port 1260 has not yet been configured, it is determined whether there is a configuration macro available (e.g., locally available and stored in memory 1267) that is appropriate for device 1255. (Step 1230.) Table 1266 is one exemplary data structure that may be used for such a purpose. Table 1266 includes macro field 1272, for defining a plurality of configuration macros, each of which corresponds to a device of device ID field 1274. Accordingly, a device ID determined as described above with reference to step 1215 (or otherwise) can be used to determine whether there is a corresponding macro. If port 1260 is already configured, it is determined in step 1225 whether the configuration is suitable for the device identified in step 1215. If so, the process ends. If the port does not have a desired configuration, it is determined in step 1230 whether there is an appropriate macro available for the device. If there is an appropriate macro available for the device, the macro is applied (step 1235) and then the process ends (step 1240). If not, the process ends without a macro being applied. Preferably, a network administrator is notified, e.g., by sending a message from switch 1265 to host device 1290. In the preceding example, switch 1265 had the intelligence for determining how to automatically configure a port on which a DHCPDISCONER request is received. The switch itself analyzed the DHCPDISCONER request and configured the port with an appropriate combination of attributes. These combinations of attributes, along with the necessary software for applying them, were stored in the switch itself. However, in other implementations of the invention, both the intelligence for determining how appropriately to configure the port and the instructions for so configuring the port may be owned by another device. For example, the intelligence may reside in DHCP server 1270, an edge services management server, an authentication server and a device dedicated to port configuration. Some such implementations are illustrated by the flow chart of Fig. 13. In steps 1301 and 1305, a device initializes and sends a DHCPDISCONER request to a switch port, h this example, switch 1265 forwards the DHCPDISCONER request with an indication of the port on which the DHCPDISCONER request was received. (Step 1310.) The port ID could be provided, for example, in DHCP Option 82. Preferably, the switch also forwards information regarding the current port configuration to DHCP server 1270. According to some implementations, DHCP server 1270 attempts to identify the device. (Step 1312.) If DHCP server 1270 can identify the device, DHCP server 1270 performs steps 1320, 1325 and 1330, which are analogous to steps 1220 through 1230 of method 1200. DHCP server 1270 then instructs switch 1265 to configure the port in an appropriate manner, e.g., by applying a macro. (Step 1335.) Macros (or the like) for this purpose could be stored in switch 1265, could be sent from DHCP server 1270 to switch 1265, or could be obtained by switch 1265 from another device. For example, DHCP server 1270 could send switch 1265 a pointer to a memory space wherein such instructions are stored (e.g., in one of storage devices 1295). hi other implementations, DHCP server 1270 provides an IP address in response to the DHCPDISCONER request and forwards the DHCPDISCONER request to another device that performs steps similar to steps 1210 through 1230. The device could be, e.g., an authentication server or a server that is dedicated to automated port configuration. This device could instruct switch 1265 to configure the port in an appropriate manner, e.g., as described above. Alternatively, DHCP server 1270 could perform at least the device and port identification steps. DHCP server 1270 could then forward this information to another device that first performs a mapping of device type to desired configuration and then instructs switch 1265 to configure port 1260 accordingly. In yet other implementations, a device local to switch 1265 performs steps similar to those of steps 1215 through 1230 and then instructs switch 1265 accordingly. For example, a DHCP relay agent in switch 1265 is programmed to forward a copy of the DHCPDISCONER request to another device (e.g., an edge services management server) that performs steps similar to steps 1210 through 1230, e.g., prior to forwarding the DHCPDISCONER request to the DHCP server. In such implementations, the DHCP server could behave as a normal DHCP server and switch 1265 could lack the intelligence to perform steps 1210 through 1230. The DHCPDISCONER request could be forwarded to another device on the local network that performs steps similar to steps 1210 through 1230. However, as illustrated in Fig. 14, some embodiments of the invention combine many of the components necessary to implement the invention within a single chassis. Here, chassis 1400 is a router that includes switch module 1405, with ports 1410 that can be configured for appropriately communicating with devices 1415. In this example, router 1400 also includes DHCP server 1420, which may be implemented in software and/or hardware (e.g., as a line card or "blade"). In alternative implementations, DHCP server 1420 could be implemented in a separate device that is in communication with router 1400. Instead of being implemented in a router having a switch module, alternative embodiments of the invention provide a chassis 1400 that is a switch that runs Layer
3, running IOS. As above, chassis 1400 could also include DHCP server 1420, implemented in software and/or hardware, or DHCP server 1420 could be implemented in a separate device that is in communication with chassis 1400. It will be appreciated by those of skill in the art that other types of devices, including but not limited to point-of-sale devices (e.g., "cash registers") NoEP telephones and devices used in manufacturing, may be advantageously configured according to the methods of the present invention. For example, one or more defined fields could indicate the type of device, device personality, etc. In one such example, DHCP Option 60 could indicate that the device is a cash register and DHCP Option 77 could indicate the "personality" of the cash register, e.g., that it is a cash register used by a particular type of restaurant. There could be predefined macros for configuring a switch port appropriately for each type of device, e.g., for a cash register.
Other Embodiments
Although illustrative embodiments and applications of this invention are shown and described herein, many variations and modifications are possible which remain within the concept, scope, and spirit of the invention, and these variations would become clear to those of ordinary skill in the art after perusal of this application. Accordingly, the present embodiments are to be considered as illustrative and not restrictive, and the invention is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.

Claims

WE CLAIM:
1. A method for uniquely provisioning a radio frequency identification ("RFED") device, the method comprising: receiving a provisioning request on a network; automatically identifying an RFED device according to a media access control
("MAC") address and an electronic product code ("EPC") included in the provisioning request; and automatically locating the RFED device according to location information included in the provisioning request.
2. The method of claim 1 , further comprising the step of automatically initiating a reprovisioning cycle to provide the RFED device with a different functionality.
3. The method of claim 1 , further comprising: determining whether provisioning information has previously been established for the RFED device; and . provisioning the RFED device when it is determined that provisioning information has previously been established for the RFED device.
4. A method for uniquely provisioning a radio frequency identification ("RFLD") device, the method comprising: forming a DHCPDISCONER request that includes an electronic product code ("EPC") of an RFED device and location information indicating a location of the
RFED device; sending the DHCPDISCONER request to a Dynamic Host Configuration Protocol ("DHCP") server; and receiving provisioning information from the DHCP server that is specifically intended for the RFED device.
5. The method of claim 4, further comprising the step of transmitting a DHCPLNFORM request to the DHCP server, the DHCPINFORM request indicating a current enabled functionality of the RFLD device.
6. A radio frequency identification ("RFED") network, comprising: means for forming a DHCPDISCONER request that includes an electronic product code ("EPC") of an RFED device and location information indicating a location of the RFED device; means for sending the DHCPDISCONER request to a Dynamic Host Configuration Protocol ("DHCP") server and for receiving provisioning information from the DHCP server that is specifically tailored for the RFED device.
7. The RFED network of claim 6, further comprising means for transmitting a
DHCPLNFORM request to the DHCP server, the DHCPINFORM request indicating a current enabled functionality of the RFED device.
8. The RFED network of claim 18, wherein the forming means comprises an RFED device for including the EPC in the DHCPDISCONER request and a relay agent for including the location information in the DHCPDISCONER request.
9. A network device, comprising: means for receiving a provisioning request on a network; and means for automatically identifying an RFED device according to a media access control ("MAC") address and an electronic product code ("EPC") included in the provisioning request and for locating the RFID device according to location information included in the provisioning request.
10. The network device of claim 9, further comprising means for initiating a reprovisioning cycle to provide the RFED device with a different functionality.
11. A computer program embodied in a machine-readable medium, the computer program including instructions for controlling one or more elements of a radio frequency identification ("RFLD") network to perform the following steps: form a DHCPDISCONER request that includes an electronic product code ("EPC") of an RFED device and location information indicating a location of the RFLD device; send the DHCPDISCONER request to a Dynamic Host Configuration
Protocol ("DHCP") server; and receive provisioning information from the DHCP server that is specifically intended for the RFED device.
12. A computer program embodied in a machine-readable medium, the computer program including instructions for controlling a network device to perform the following steps: receive a provisioning request on a network; identify an RFED device according to a media access control ("MAC") address and an electronic product code ("EPC") included in the provisioning request; locate the RFLD device according to location information included in the provisioning request; and determine whether provisioning information has previously been established for the RFLD device.
13. The computer program of claim 12, further comprising instructions for controlling the network device to provision the RFED device when it is determined that provisioning information has previously been established for the RFED device.
14. A method for deploying a uniquely-provisioned radio frequency identification ("RFED") device in a network, the method comprising: forming a DHCPDISCONER request that includes an electronic product code
("EPC") of an RFED reader and location information indicating that the RFED reader is positioned at an exit door of a retail store; sending the DHCPDISCONER request to a Dynamic Host Configuration Protocol ("DHCP") server; receiving provisioning information from the DHCP server that is specifically intended for the RFED reader; and provisioning the RFED reader according to the provisioning information, thereby enabling the RFID reader to read RFED tags passing through the exit door and to transmit RFED tag information to an RFED network.
15. The method of claim 14, further comprising the step of using the RFED tag information to automatically update a database maintained by at least one of the retail store, a manufacturer of at least one of the products and a distributor of at least one of the products.
16. The method of claim 14, further comprising the step of using the RFED tag information to cause a financial account to be debited for a cost of the products.
17. The method of claim 14, further comprising the step of using the RFED tag information to update a business plan.
18. The method of claim 17, wherein the business plan comprises at least one of a marketing plan, a manufacturing plan, a distribution plan and a sales plan.
19. A radio frequency identification ("RFED") network, comprising: a plurality of RFED devices; a plurality of switches connecting the RFED devices to the RFED network; and a Dynamic Host Configuration Protocol ("DHCP") server, wherein at least some of the plurality of RFED devices comprise: means for forming a DHCPDISCONER request that includes an electronic product code ("EPC") of an RFED device; and means for sending the DHCPDISCONER request to the DHCP server via a switch and for receiving provisioning information from the DHCP server that is specifically tailored for the RFED device; wherein the switch comprises means for including location information in the DHCPDISCONER request indicating a location of the RFED device; and wherein the DHCP server comprises: means for receiving a DHCPDISCONER request; and means for automatically identifying an RFED device according to a media access control ("MAC") address and an EPC included in the DHCPDISCONER request and for locating the RFED device according to the location information included in the DHCPDISCONER request.
20. A method for establishing network device port settings, the method comprising: receiving a DHCPDISCONER request from a device; and determining, based on information in the DHCPDISCONER request, whether an appropriate macro is available to configure a port of a network device on wliich the DHCPDISCONER request was first received.
21. The method of claim 20, further comprising the step of applying the appropriate macro when it is determined to be available.
22. The method of claim 20, wherein the determining step comprises determining a device personality.
23. The method of claim 20, wherein the determining step is performed by the network device on which the DHCPDISCONER request was first received.
24. The method of claim 20, wherein the determining step is not performed by the network device on which the DHCPDISCONER request was first received.
25. The method of claim 20, wherein the DHCPDISCONER request is first received by a switch port and wherein the determining step is performed by one of a DHCP server, an edge services management server, an authentication server and a device dedicated to port configuration..
26. A network device, comprising: a plurality of ports; a storage device; and at least one logic device configured to receive a DHCPDISCONER request from a device via a first port and configure the first port with appropriate configuration parameters for the device.
27. The network device of claim 26, wherein a logic device is further configured to forward a copy of the DHCPDISCONER request to a second device and wherein the logic device configures the first port according to instructions received from the second device.
28. The network device of claim 27, wherein the second device is a device selected from the group consisting of a DHCP server, an edge services management server, an authentication server and a device dedicated to port configuration.
PCT/US2005/016484 2004-05-13 2005-05-10 Methods and devices for locating and provisioning rfid devices and related network devices WO2005114545A2 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP05750091A EP1751687A4 (en) 2004-05-13 2005-05-10 Methods and devices for locating and provisioning rfid devices and related network devices
CA2565099A CA2565099C (en) 2004-05-13 2005-05-10 Methods and devices for locating and provisioning rfid devices and related network devices

Applications Claiming Priority (10)

Application Number Priority Date Filing Date Title
US57099904P 2004-05-13 2004-05-13
US60/570,999 2004-05-13
US10/866,507 US7336175B2 (en) 2004-05-13 2004-06-09 Methods and devices for locating and uniquely provisioning RFID devices
US10/866,506 2004-06-09
US10/866,507 2004-06-09
US10/866,285 US7325734B2 (en) 2004-05-13 2004-06-09 Methods and devices for assigning RFID device personality
US10/866,506 US7322523B2 (en) 2004-05-13 2004-06-09 Methods and devices for uniquely provisioning RFID devices
US10/866,285 2004-06-09
US11/104,140 2005-04-11
US11/104,140 US8060623B2 (en) 2004-05-13 2005-04-11 Automated configuration of network device ports

Publications (3)

Publication Number Publication Date
WO2005114545A2 true WO2005114545A2 (en) 2005-12-01
WO2005114545A8 WO2005114545A8 (en) 2005-12-22
WO2005114545A3 WO2005114545A3 (en) 2006-01-26

Family

ID=35429065

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2005/016484 WO2005114545A2 (en) 2004-05-13 2005-05-10 Methods and devices for locating and provisioning rfid devices and related network devices

Country Status (3)

Country Link
EP (1) EP1751687A4 (en)
CA (1) CA2565099C (en)
WO (1) WO2005114545A2 (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7648070B2 (en) 2004-05-13 2010-01-19 Cisco Technology, Inc. Locating, provisioning and identifying devices in a network
US9064164B2 (en) 2006-02-03 2015-06-23 Cisco Technology, Inc. Methods and systems for automatic device provisioning in an RFID network using IP multicast
CN107871093A (en) * 2016-09-28 2018-04-03 青岛海尔智能技术研发有限公司 RFID reader, RFID reading accuracy improve method and storage facilities

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE3851168T2 (en) * 1987-03-31 1995-03-30 Identec Ltd Access control device.
US5850187A (en) * 1996-03-27 1998-12-15 Amtech Corporation Integrated electronic tag reader and wireless communication link
US5887176A (en) * 1996-06-28 1999-03-23 Randtec, Inc. Method and system for remote monitoring and tracking of inventory
US6073178A (en) * 1996-12-09 2000-06-06 Sun Microsystems, Inc. Method and apparatus for assignment of IP addresses
US6553489B1 (en) * 2000-01-12 2003-04-22 Cisco Technology, Inc. System and method for secure and efficient universal port configuration
KR100454513B1 (en) * 2000-02-09 2004-11-03 인터내셔널 비지네스 머신즈 코포레이션 Method and apparatus for providing automatic configuration of a computer system based on its physical location using an electronic unit
FR2815494B1 (en) * 2000-10-12 2003-01-10 Schneider Automation S A METHOD FOR CONFIGURING AN AUTOMATION MODULE ON A TCP / IP NETWORK

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None
See also references of EP1751687A4

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7648070B2 (en) 2004-05-13 2010-01-19 Cisco Technology, Inc. Locating, provisioning and identifying devices in a network
US9064164B2 (en) 2006-02-03 2015-06-23 Cisco Technology, Inc. Methods and systems for automatic device provisioning in an RFID network using IP multicast
CN107871093A (en) * 2016-09-28 2018-04-03 青岛海尔智能技术研发有限公司 RFID reader, RFID reading accuracy improve method and storage facilities
CN107871093B (en) * 2016-09-28 2021-11-26 青岛海尔智能技术研发有限公司 RFID reader, RFID reading accuracy improving method, and storage device

Also Published As

Publication number Publication date
CA2565099C (en) 2016-08-09
WO2005114545A8 (en) 2005-12-22
WO2005114545A3 (en) 2006-01-26
EP1751687A4 (en) 2010-09-08
CA2565099A1 (en) 2005-12-01
EP1751687A2 (en) 2007-02-14

Similar Documents

Publication Publication Date Title
US7325734B2 (en) Methods and devices for assigning RFID device personality
US7336175B2 (en) Methods and devices for locating and uniquely provisioning RFID devices
US7322523B2 (en) Methods and devices for uniquely provisioning RFID devices
US7789308B2 (en) Locating and provisioning devices in a network
US7648070B2 (en) Locating, provisioning and identifying devices in a network
US8604910B2 (en) Using syslog and SNMP for scalable monitoring of networked devices
US8249953B2 (en) Methods and apparatus for determining the status of a device
EP1902432B1 (en) Provisioning and redundancy for rfid middleware servers
CA2565451C (en) Locating, provisioning and identifying devices in a network
EP2047440A2 (en) Virtual readers for scalable rfid infrastructures
CA2565099C (en) Methods and devices for locating and provisioning rfid devices and related network devices

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

CFP Corrected version of a pamphlet front page
CR1 Correction of entry in section i

Free format text: IN PCT GAZETTE 48/2005 UNDER "PUBLISHED" DELETE "WITH INTERNATIONAL SEARCH REPORT "

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2565099

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 200580015167.4

Country of ref document: CN

NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Ref document number: DE

REEP Request for entry into the european phase

Ref document number: 2005750091

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2005750091

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2005750091

Country of ref document: EP