摘  要： RFID技術在近年來得到了快速的發(fā)展。但是，RFID讀寫器與客戶端之間的通信協(xié)議并沒有得到統(tǒng)一，它們之間的連接需要適配讀寫器廠商私有的接口，不利于RFID應用系統(tǒng)的快速構建。因此，RFID標準化組織EPCglobal在2007年推出了底層讀寫器協(xié)議LLRP（Low Level Reader Protocol），它為讀寫器和其控制器提供了標準的網(wǎng)絡接口，極大地提高了RFID應用系統(tǒng)的構建效率。借助于開源的RFID中間件平臺Fosstrak對LLRP協(xié)議及其實現(xiàn)進行分析對比，會使開發(fā)者對LLRP協(xié)議有更深入的理解，為實現(xiàn)EPCglobal系統(tǒng)打下了堅實的基礎。

關鍵詞： 射頻識別；EPCglobal；底層讀寫器協(xié)議；Fosstrak

　　0 引言

　　射頻識別（Radio Frequency Identification，RFID）是一種非接觸式的自動識別技術，它利用無線射頻方式進行雙向通信并交換數(shù)據(jù)，以達到識別目標的目的。由于其具有標簽容量大、數(shù)據(jù)保密性好、傳輸可靠性高，以及非可視識別、移動識別、多目標識別、定位及長期跟蹤管理等特點，RFID技術在2005年入選“建議企業(yè)引入的十大策略技術”，并被公認為本世紀十大重要技術之一[1]。

　　目前，RFID技術被廣泛應用于生產(chǎn)、防偽、產(chǎn)品跟蹤、交通、物流、資產(chǎn)管理等眾多領域，射頻識別技術已經(jīng)成為企業(yè)提高供應鏈管理水平，降低生產(chǎn)成本，實現(xiàn)企業(yè)信息化管理，增強企業(yè)競爭能力的有力技術手段和工具。

　　但是，在傳統(tǒng)的RFID應用與開發(fā)中，RFID讀寫器與其控制器的客戶端之間的通信協(xié)議并沒有統(tǒng)一，它們之間的連接需要適配讀寫器廠商私有的接口。因此，當RFID讀寫器在硬件或軟件上稍有變動，則客戶端的軟件就必須隨之一起改動。當用戶采用不同供應商提供的產(chǎn)品時，其維護成本也隨之提高，這就造成了開發(fā)工作的重復性以及系統(tǒng)之間的不兼容性和維護的復雜性，同時也影響了RFID技術的發(fā)展和普及。

　　為了解決RFID技術在相關領域缺乏統(tǒng)一標準的問題，全球電子產(chǎn)品編碼協(xié)會（Electronic Product Code global，EPCglobal）于2007年發(fā)布了底層讀寫器協(xié)議（LLRP）[2]。該協(xié)議定義了RFID讀寫器與其控制器客戶端的接口規(guī)范，使得軟件開發(fā)者能夠更加專注于客戶的需求，極大地提高了RFID應用系統(tǒng)的構建效率。本文將通過Fosstrak平臺對LLRP進行分析，以深入理解LLRP的數(shù)據(jù)結構、工作流程及實現(xiàn)方式等，更好地掌握LLRP的使用方法。

1 Fosstrak平臺簡介

　　Fosstrak是一個實現(xiàn)了EPC網(wǎng)絡規(guī)范的開源的RFID軟件平臺。它提供了軟件的核心組件，旨在為應用程序開發(fā)人員和集成商提供一些支持。Fosstrak由EPCIS Repository、Tag Data Translation（TDT）Library、Filtering& Collection Middleware with ALE and LLRP Support和LLRP Commander四個模塊組成。本文中主要使用到Fosstrak的LLRP Commander模塊。

　　LLRP Commander是Fosstrak以Eclipse插件的形式對LLRP讀寫器控制器（客戶端）的實現(xiàn)。通過它可以對兼容LLRP協(xié)議的RFID讀寫器進行配置與管理操作。

　　LLRP Commander提供了XML、binary、graphical三種不同的編輯視圖，使開發(fā)者可以方便地檢查和修改LLRP消息。圖1展示了LLRP Commander的XML編輯視圖。

2 LLRP標準的分析

　　LLRP應用于RFID讀寫器與控制器之間，它負責讀寫器與控制器之間的連接，且可與讀寫器與標簽通信的空中接口協(xié)議進行互動[3-4]，如圖2所示。它將低層讀寫器的射頻協(xié)議屏蔽掉，而暴露給客戶端的是統(tǒng)一的協(xié)議接口，使得客戶端可以無差別地對低層的讀寫器進行控制和管理。

　　LLRP協(xié)議為客戶端與讀寫器之間提供了通信的格式和過程。這些交互過程以LLRP消息為基本的數(shù)據(jù)單元進行通信，主要包括客戶端-讀寫器消息和讀寫器-客戶端消息。

　　2.1 LLRP的基本數(shù)據(jù)類型

　　LLRP的基本數(shù)據(jù)類型包括消息（Messages）、參數(shù)（Parameters）和域（Fields）[2]。其中消息可以包含一個或多個參數(shù)或域，而一個參數(shù)也可以包含一個或多個參數(shù)（子參數(shù)）或域。

　　從客戶端到讀寫器的消息包括：獲取和設置讀寫器的配置信息；讀寫器的能力發(fā)現(xiàn)（包括讀寫器的天線數(shù)、通用輸入/輸出端口數(shù)等）；管理讀寫器的清點和訪問操作。從讀寫器到客戶端的信息包括：讀寫器的狀態(tài)報告、射頻監(jiān)測的信息、清點和訪問操作的結果報告。

　　LLRP消息中定義了兩個基本的操作規(guī)格即讀寫器操作規(guī)格（Reader Operations Specification，ROSpec）和訪問規(guī)格（Access Specification）。

　　ROSpec負責處理讀寫器的操作（Reader Operation，RO）。在一個RO中至少包含了一個規(guī)格AISpec或者RFSurveySpec。其中AISpec負責標簽的盤點作業(yè)，RFSurveySpec負責獲取讀寫器操作天線的射頻功率的信息。除此之外，在ROSpec中還可以根據(jù)實際情況加入其他的規(guī)格，比如ROReportSpec（它描述了一個報告的發(fā)送時機以及報告中包含的內(nèi)容等信息），或者一些自定義的規(guī)格（LLRP靈活的可擴展性允許供應商按照一定的規(guī)則對其進行擴展，有利于產(chǎn)品的創(chuàng)新與競爭）。

　　Access Specification描述了對標簽內(nèi)存中非EPC信息的操作。

　　2.2 LLRP的工作流程

　　典型的LLRP客戶端與讀寫器之間的交互過程如圖3所示。

　　從圖3可以看出，LLRP的工作流程主要包括以下幾個階段[5]：

　?。?）客戶端將向讀寫器發(fā)送配置命令。這些配置可以包括讀寫器的能力發(fā)現(xiàn)、配置和查詢讀寫器的設置。讀寫器能力發(fā)現(xiàn)包括讀寫器的天線數(shù)、天線接收靈敏度、天線支持的空中協(xié)議、通用輸入輸出端口（GPIO）數(shù)等。在配置讀寫器設置時，除了可以設置天線的模式、GPIO的狀態(tài)等，還可以設置ROReportSpec、AccessReportSpec等作為默認的報告規(guī)格。在客戶端發(fā)送配置消息后，讀寫器在完成了相關的設置之后會向客戶端發(fā)送相應的響應消息。

　?。?）讀寫器配置階段執(zhí)行完畢后，客戶端向讀寫器發(fā)送LLRP所定義的ROSpec和AccessSpec等操作命令集，對讀寫器標簽的存取操作進行設置與更新。在該階段，如果在ROSpec規(guī)格中沒有設置相關的報告規(guī)格（如ROReportSpec），則會使用在讀寫器配置階段所設置的默認報告規(guī)格；如果在ROSpec中設置了相關的報告規(guī)格，則將覆蓋默認的報告規(guī)格。

　?。?）在相關配置工作完成之后，對發(fā)生的符合條件的事件，將開始執(zhí)行讀寫器操作并向客戶端返回相應的信息報告。讀寫器操作包括標簽的盤點、存取和對讀寫器的射頻監(jiān)測等。

3 LLRP消息的實現(xiàn)

　　LLRP的兩個端點（客戶端與讀寫器端）之間是通過TCP/IP進行通信的[2]，同時LLRP消息以二進制編碼的格式在它們之間進行傳輸。這種方式是高效、快速的。LLRP規(guī)范中定義了LLRP消息的二進制編碼格式，如圖4所示。如果開發(fā)者直接以二進制的形式實現(xiàn)LLRP消息的話，將是困難的、低效的。因此，根據(jù)以上對LLRP的分析，以及LLRP Commander中的實現(xiàn)方式，并考慮到編程語言的效率，一般采用“面向文檔”和“面向?qū)ο蟆眱煞N方式對LLRP消息進行實現(xiàn)。

　　面向文檔的實現(xiàn)方式是基于XML的方式[6]。由于LLRP消息是嵌套的，即消息可以包含一個或多個參數(shù)或域，而一個參數(shù)也可以包含一個或多個參數(shù)或域，因此XML標簽的可嵌套性和可擴展性的特點非常適合于LLRP消息的實現(xiàn)。利用官方提供的llrp.xsd文檔，開發(fā)人員可以方便地構造出一個面向文檔的LLRP消息。在LLRP Commander中提供了一些LLRP消息的例子，其中ADD_ROSPEC消息的XML描述見圖1。

　　在圖1中，根節(jié)點ADD_ROSPEC是LLRP中的消息，子節(jié)點ROSpec、ROBoundarySpec、OSpecStartTrigger、ROSpecStopTrigger、AISpec、AISpecStopTrigger、InventoryParameterSpec是LLRP中的參數(shù)，而ROSpecID、Priority、CurrentState、ROSpecStartTriggerType等其他的子節(jié)點則為LLRP中的域。

　　面向?qū)ο蟮膶崿F(xiàn)方式就是將特定的消息和面向?qū)ο笾卸x的對象一一對應[7]。在以面向?qū)ο蟮姆绞綄崿F(xiàn)LLRP消息時，LLRP規(guī)范中每一個特定的消息都對應一個類，每一個特定的參數(shù)也都對應一個類，而域則是作為消息類與參數(shù)類的成員變量。如果在LLRP的定義中某個消息包含某個參數(shù)，則此參數(shù)也將作為該消息的一個成員變量。該消息類與其所包含的參數(shù)類之間構成了一種組合關系。這里，同樣以ADD_ROSPEC消息的面向?qū)ο髮崿F(xiàn)方式的UML類圖為例來進行說明，如圖5所示。

　　在圖5中，ADD_ROSPEC就是一個消息類，它對應于LLRP中的一個消息，而該消息類的一個成員變量ROSpec則是ROSPEC參數(shù)類的對象，它對應于LLRP中的一個參數(shù)。同時，在參數(shù)類ROSPEC中也包含參數(shù)類ROBoundarySpec等。

4 結論

　　LLRP作為讀寫器與客戶端之間的一個接口標準，它不需要去適配各個讀寫器廠商私有的接口，而是提供了標準的接口來接入不同廠商的讀寫器，極大地提高了RFID應用系統(tǒng)的構建效率。通過對LLRP數(shù)據(jù)結構、工作流程的分析，以及對其實現(xiàn)方式的比較，使開發(fā)者能夠?qū)ζ溆懈钊氲恼J知，提高應用效率，為實現(xiàn)相關應用系統(tǒng)奠定了堅實的基礎。

　　參考文獻

　　[1] 武君勝，李瑞賢.射頻識別系統(tǒng)底層協(xié)議開發(fā)工具包設計[J].計算機測量與控制，2010，18（1）：179-182.

　　[2] EPCglobal Inc. llrp_1_1-standard-20101013 [EB/OL]. http：//www.gs1.org/gsmp/kc/epcglobal/llrp/llrp_1_1-standard-20101013.pdf.

　　[3] 宋林.構建基于LLRP的可擴展的RFID中間件[D].北京：北京郵電大學，2011.

　　[4] 林強，趙辰，羅艷.底層識讀器協(xié)議規(guī)范與測試淺析[J].條碼與信息系統(tǒng)，2009（6）：21-23.

　　[5] 張益，楊國.基于低級別讀寫器協(xié)議的無線射頻識別中間件系統(tǒng)[J].中興通訊技術，2010，16（2）：42-45.

　　[6] POULOPOULOS D. A generalized binding framework for the low level reader protocol（LLRP）[D]. Cambridge： Massachusetts Institute of Technology， 2008.

　　[7] CONSTANTINOU F. An object-oriented implementation of a low level reader protocol（LLRP） library[D]. Cambridge： Massachusetts Institute of Technology， 2008.