無線射頻識(shí)別中間件技術(shù)

摘要：無線射頻識(shí)別(RFID)技術(shù)及其應(yīng)用，近年來在國(guó)內(nèi)外的發(fā)展方興未艾。中間件是構(gòu)建以及部署RFID系統(tǒng)時(shí)所必須的功能組件，被稱為RFID系統(tǒng)的“神經(jīng)中樞”。中間件實(shí)現(xiàn)標(biāo)簽數(shù)據(jù)的處理和上報(bào)，內(nèi)部處理流程由清點(diǎn)規(guī)則的狀態(tài)躍遷機(jī)制實(shí)現(xiàn)。作為一個(gè)軟件系統(tǒng)，中間件的架構(gòu)應(yīng)用了面向?qū)ο蟮乃枷搿⒖剂嗽O(shè)計(jì)模式的成功經(jīng)驗(yàn)。融合網(wǎng)絡(luò)設(shè)備管理功能、支持多標(biāo)簽標(biāo)準(zhǔn)、支持多廠家閱讀器等將是中間件的技術(shù)發(fā)展方向。

關(guān)鍵詞：中間件，無線射頻識(shí)別，面向?qū)ο螅O(shè)計(jì)模式

Abstract: Radio Frequency Identification (RFID)， as a new technology， has been developing rapidly in recent years. Middleware is one of the most important components in the RFID system. It provides functions of tag data processing and reporting. The mechanism of inner processing is based on state transition of event cycle specification. As a software system， the middleware structure is object-oriented， and it uses the idea of design patterns. The growing trend of middleware may be combining network element management functions， supporting multi-standard of tags， and accommodating different RFID reader vendors.

Key words: middleware， RFID， object oriented， design patterns

無線射頻識(shí)別(RFID)技術(shù)是一種快速、實(shí)時(shí)、準(zhǔn)確的信息采集與處理技術(shù)，通過射頻信號(hào)對(duì)實(shí)體對(duì)象進(jìn)行唯一有效的標(biāo)識(shí)，可廣泛應(yīng)用于生產(chǎn)、零售、物流、交通、醫(yī)療、國(guó)防、畜牧、采礦等各個(gè)行業(yè)。

基本的RFID系統(tǒng)一般由3部分組成：標(biāo)簽、閱讀器以及應(yīng)用支撐軟件。中間件是應(yīng)用支撐軟件的一個(gè)重要組成部分，是銜接硬件設(shè)備如標(biāo)簽、閱讀器和企業(yè)應(yīng)用軟件如企業(yè)資源規(guī)劃(ERP)、客戶關(guān)系管理(CRM)等的橋梁。中間件的主要任務(wù)是對(duì)閱讀器傳來的與標(biāo)簽相關(guān)的數(shù)據(jù)進(jìn)行過濾、匯總、計(jì)算、分組，減少?gòu)拈喿x器傳往企業(yè)應(yīng)用的大量原始數(shù)據(jù)、生成加入了語意解釋的事件數(shù)據(jù)。可以說，中間件是RFID系統(tǒng)的“神經(jīng)中樞”。

對(duì)于RFID中間件的設(shè)計(jì)，有諸多問題需要考慮，如：如何實(shí)現(xiàn)軟件的諸多質(zhì)量屬性、如何實(shí)現(xiàn)中間件與硬件設(shè)備的隔離、如何處理與設(shè)備管理功能的關(guān)系、如何實(shí)現(xiàn)高性能的數(shù)據(jù)處理等等。

1 RFID網(wǎng)絡(luò)框架結(jié)構(gòu)

無線射頻識(shí)別網(wǎng)絡(luò)的框架結(jié)構(gòu)如圖1所示。

標(biāo)簽數(shù)據(jù)經(jīng)過中間件的分組、過濾等處理上報(bào)給應(yīng)用系統(tǒng)；應(yīng)用系統(tǒng)負(fù)責(zé)事件數(shù)據(jù)的持久化存儲(chǔ)，以及標(biāo)簽綁定的業(yè)務(wù)信息的管理。

RFID系統(tǒng)共享公共服務(wù)平臺(tái)提供根節(jié)點(diǎn)對(duì)象名稱服務(wù)(ONS)、企業(yè)應(yīng)用鑒權(quán)管理、標(biāo)簽信息發(fā)現(xiàn)和企業(yè)授權(quán)碼管理等公共服務(wù)。其中，根節(jié)點(diǎn)ONS連同所有企業(yè)級(jí)RFID系統(tǒng)的內(nèi)部ONS，組成一個(gè)ONS樹，任何一個(gè)標(biāo)簽都可以在ONS樹上找到標(biāo)簽所對(duì)應(yīng)的標(biāo)簽信息庫的地址，即可以進(jìn)一步訪問到標(biāo)簽對(duì)應(yīng)的詳細(xì)信息。

2 中間件功能及實(shí)現(xiàn)原理

一言蔽之，中間件的功能就是接受應(yīng)用系統(tǒng)的請(qǐng)求，對(duì)指定的一個(gè)或者多個(gè)閱讀器發(fā)起操作命令如標(biāo)簽清點(diǎn)、標(biāo)簽標(biāo)識(shí)數(shù)據(jù)寫入、標(biāo)簽用戶數(shù)據(jù)區(qū)讀寫、標(biāo)簽數(shù)據(jù)加鎖、標(biāo)簽殺死等，并接收、處理、向后臺(tái)應(yīng)用系統(tǒng)上報(bào)結(jié)果數(shù)據(jù)。

其中，標(biāo)簽清點(diǎn)是最為基本、也是應(yīng)用最為廣泛的功能。

2.1標(biāo)簽清點(diǎn)功能概述

標(biāo)簽清點(diǎn)的工作流程可簡(jiǎn)單描述為：

●應(yīng)用系統(tǒng)以規(guī)則的形式定義對(duì)標(biāo)簽數(shù)據(jù)的需求，規(guī)則由應(yīng)用系統(tǒng)向中間件提出，由中間件維護(hù)。規(guī)則中定義了：需要哪些閱讀器的清點(diǎn)數(shù)據(jù)，標(biāo)簽數(shù)據(jù)上報(bào)周期(事件周期)的開始和結(jié)束條件，標(biāo)簽數(shù)據(jù)如何過濾，標(biāo)簽數(shù)據(jù)如何分組，上報(bào)數(shù)據(jù)為原始清點(diǎn)數(shù)據(jù)、新增標(biāo)簽數(shù)據(jù)還是新減標(biāo)簽數(shù)據(jù)，標(biāo)簽數(shù)據(jù)包含哪些原始數(shù)據(jù)等。

●應(yīng)用系統(tǒng)指定某項(xiàng)規(guī)則，向中間件提出對(duì)標(biāo)簽數(shù)據(jù)的預(yù)訂。

●中間件根據(jù)應(yīng)用系統(tǒng)對(duì)標(biāo)簽數(shù)據(jù)的預(yù)訂情況，適時(shí)啟動(dòng)事件周期，并向閱讀器下發(fā)標(biāo)簽清點(diǎn)命令。

●閱讀器將一定時(shí)間周期(讀取周期)中清點(diǎn)到的數(shù)據(jù)，發(fā)送給中間件。讀取周期可由中間件與閱讀器制定私下協(xié)商確定。

●中間件接由收閱讀器上報(bào)的數(shù)據(jù)。

●中間件根據(jù)規(guī)則的定義，對(duì)接收數(shù)據(jù)做過濾、分組、累加等操作，并在事件周期結(jié)束時(shí)，按照規(guī)則的要求生成數(shù)據(jù)結(jié)果報(bào)告，發(fā)送給規(guī)則的預(yù)訂者。過濾過程可去除重復(fù)數(shù)據(jù)、應(yīng)用系統(tǒng)不感興趣的數(shù)據(jù)，大大降低了組件間的傳輸數(shù)據(jù)量。

此流程可參見圖2。

此處，需要說明一下邏輯閱讀器的概念。

中間件將事件源抽象為一個(gè)邏輯概念——邏輯閱讀器，一個(gè)邏輯閱讀器可以包含多個(gè)物理閱讀器，甚至可更細(xì)化為包含多個(gè)物理閱讀器的多個(gè)天線。

邏輯閱讀器的劃分可以根據(jù)實(shí)際的系統(tǒng)部署情況來確定，比如，某一個(gè)倉庫兩個(gè)出口部署了4個(gè)閱讀器，可根據(jù)需要將這4個(gè)閱讀器配置成為一個(gè)邏輯閱讀器，不妨命名為“倉庫出口”。應(yīng)用系統(tǒng)在需要倉庫出口的標(biāo)簽數(shù)據(jù)時(shí)，可基于這個(gè)邏輯閱讀器下發(fā)清點(diǎn)命令，而邏輯閱讀器名稱作為部分應(yīng)用程序接口(API)調(diào)用的參數(shù)。

2.2 標(biāo)簽清點(diǎn)實(shí)現(xiàn)原理

如前所述，規(guī)則是整個(gè)中間件功能的關(guān)鍵元素。規(guī)則相當(dāng)于應(yīng)用系統(tǒng)發(fā)給中間件的訂貨單，定義了對(duì)貨品(標(biāo)簽數(shù)據(jù))的時(shí)間(事件周期)和規(guī)格(如何過濾、如何分組、報(bào)告樣式等)的要求，原理描述部分參考EPCglobal相關(guān)內(nèi)容[1]。

規(guī)則、報(bào)告有自身的信息模型，表征其承載的信息，同時(shí)，規(guī)則擁有其自身的狀態(tài)機(jī)模型。在接受應(yīng)用系統(tǒng)的長(zhǎng)期預(yù)訂、單次預(yù)訂時(shí)，這些預(yù)訂操作會(huì)激發(fā)規(guī)則的狀態(tài)變遷，如從“未被請(qǐng)求”狀態(tài)躍遷到“已被請(qǐng)求”狀態(tài)。

規(guī)則由應(yīng)用系統(tǒng)通過API定義。

(1) 規(guī)則信息模型

規(guī)則信息模型的描述采用了統(tǒng)一建模語言(UML)，如圖3所示。

在面向?qū)ο蟮恼Z境中，規(guī)則可表征為一個(gè)類(ECSpec)。從信息模型描述中可看出，一個(gè)規(guī)則類，與其他多個(gè)類具有關(guān)聯(lián)關(guān)系，或者說擁有如下屬性：一個(gè)或者多個(gè)邏輯閱讀器的列表(readers)、事件周期邊界定義(boundaries)、一個(gè)或者多個(gè)報(bào)告的定義(reportSpecs)、是否在報(bào)告中包含規(guī)則本身的標(biāo)記(includeSpecInReports)。

(2) 報(bào)告信息模型

與規(guī)則信息模型類似，報(bào)告信息模型如圖4所示。

其中，事件報(bào)告組類(ECReports)擁有如下屬性：規(guī)則名稱(specName)、時(shí)間上報(bào)時(shí)間(date)、事件周期時(shí)長(zhǎng)(totalMilliseconds)、事件周期結(jié)束條件(terminationCondition)、規(guī)則定義類實(shí)例(spec)、一個(gè)或者多個(gè)報(bào)告類的實(shí)例列表(reports)。

報(bào)告類(ECReport)中包含了具體的標(biāo)簽數(shù)據(jù)信息。

(3) 標(biāo)簽清點(diǎn)API

應(yīng)用系統(tǒng)下發(fā)的定義規(guī)則、預(yù)訂數(shù)據(jù)等請(qǐng)求，以調(diào)用中間件提供的API的方式完成。API調(diào)用過程可采用Java RMI、SOAP等相關(guān)具體技術(shù)實(shí)現(xiàn)，其中最重要的API參見表1。

其中，poll操作相當(dāng)于subscribe操作收到一個(gè)事件周期的數(shù)據(jù)之后調(diào)用unsubscribe操作；immediate操作相當(dāng)于define操作定義規(guī)則之后，調(diào)用poll操作，然后調(diào)用undefine操作。

(4) 規(guī)則狀態(tài)機(jī)模型

規(guī)則從其定義開始，可能存在于3種狀態(tài)：未被請(qǐng)求狀態(tài)(Unrequested)、已被請(qǐng)求狀態(tài)(Requested)、激活狀態(tài)(Active)。

當(dāng)規(guī)則創(chuàng)建之后，還沒有被任何客戶端(即應(yīng)用系統(tǒng))預(yù)訂，規(guī)則處于Unrequested狀態(tài)；對(duì)規(guī)則的第一個(gè)預(yù)訂動(dòng)作將使規(guī)則躍遷到Requested狀態(tài)；當(dāng)事件周期開始條件滿足時(shí)，規(guī)則進(jìn)入Active狀態(tài)；當(dāng)事件周期結(jié)束條件滿足時(shí)，如果規(guī)則存在預(yù)訂者，則躍遷到Requested狀態(tài)，否則躍遷到Unrequested狀態(tài)。

3 中間件系統(tǒng)架構(gòu)

中間件系統(tǒng)作為一個(gè)軟件系統(tǒng)(或稱組件)，在實(shí)現(xiàn)一定功能、性能要求之外，可理解性、可擴(kuò)展性、可修改性(或稱可重構(gòu)性)、可插入性、可重用性等質(zhì)量屬性都將作為軟件設(shè)計(jì)的要求被提出來。

近十余年來，面向?qū)ο笏枷霂缀跞嬲碱I(lǐng)軟件設(shè)計(jì)領(lǐng)域，成為最主流的分析、設(shè)計(jì)方法。而近數(shù)年來，對(duì)設(shè)計(jì)模式的研究也已日臻完善，模式幾乎已成為一種“更高級(jí)編程語言”(相比于Java、C++等高級(jí)編程語言)被廣泛應(yīng)用。

面向?qū)ο笏枷搿⒃O(shè)計(jì)模式都是以實(shí)現(xiàn)軟件的可理解、可擴(kuò)展、可修改、可插入、可重用等目標(biāo)為己任的，本文也將應(yīng)用面向?qū)ο笏枷搿⒖寄Ｊ秸Z言，對(duì)中間件的軟件架構(gòu)做一個(gè)初步的探討，下文的例子如涉及高級(jí)編程語言，均采用Java語言[2]。

3.1 封裝、隔離處理流程中的各個(gè)節(jié)點(diǎn)

將中間件的業(yè)務(wù)流程中的各個(gè)節(jié)點(diǎn)分作不同模塊處理，可以獲得封裝、高內(nèi)聚、低耦合等優(yōu)勢(shì)，參見圖5。

其中，報(bào)告上傳模塊，負(fù)責(zé)實(shí)現(xiàn)不同類型的報(bào)告上傳方式，如HTTP、JMS等；API接口模塊，負(fù)責(zé)隔離應(yīng)用系統(tǒng)和中間件核心業(yè)務(wù)邏輯處理模塊，向應(yīng)用系統(tǒng)提供中間件API接口；中間件核心業(yè)務(wù)邏輯處理模塊，負(fù)責(zé)中間件核心業(yè)務(wù)，包括數(shù)據(jù)接收過濾、數(shù)據(jù)分組、報(bào)告生成、規(guī)則對(duì)象的狀態(tài)跳轉(zhuǎn)等；閱讀器通信模塊，負(fù)責(zé)中間件系統(tǒng)與閱讀器的通信。

3.2 門面模式、工廠模式對(duì)外部暴露

API接口

為了避免后臺(tái)應(yīng)用系統(tǒng)，即中間件的客戶端過分耦合，采用門面模式(Facade)對(duì)系統(tǒng)內(nèi)部、外部實(shí)現(xiàn)清晰的隔離。處理流程可參見圖6所示的序列圖。客戶端僅僅與Facade類建立聯(lián)系，如果Facade接口定義得足夠清晰，客戶端可以對(duì)中間件的內(nèi)部實(shí)現(xiàn)一無所知，這體現(xiàn)了面向?qū)ο笾械姆庋b性。

類的設(shè)計(jì)參見源代碼示例，從中可以看出，采用簡(jiǎn)單工廠模式(Simple Factory)能夠在客戶端不知情的情況下，靈活地替換API實(shí)現(xiàn)類的版本。中間件API接口清晰地定義了中間件提供的操作，客戶端只須知道工廠類(APIFactory)能夠得到中間件API接口的實(shí)例即可。

中間件API接口MiddlewareAPI：

public interface MiddlewareAPI {

void define(String specName， ECSpec spec);

void undefine(String specName);

void subscribe(String specName， String uri);

void unsubscribe(String specName， String uri);

EPCReports poll(String specName);

EPCReports immediate(ECSpec spec);

}

工廠類APIFactory：

public class APIFactory {

public static MiddlewareAPI getAPIInstance(){

}

}

API的實(shí)現(xiàn)類A：

public class Client {

public static void main(String[] args) {

MiddlewareAPI api = APIFactory.getAPIInstance();

api.define(\"a new spec\"， new EPCSpec());

}

}

3.3 狀態(tài)模式模擬規(guī)則的狀態(tài)機(jī)

規(guī)則在其生命周期中擁有不同的狀態(tài)，在每個(gè)狀態(tài)對(duì)一系列操作都有著不同的表現(xiàn)，于是可以利用狀態(tài)模式(state)來模擬規(guī)則的狀態(tài)機(jī)，將不同狀態(tài)的不同表現(xiàn)作為可變化因素封裝起來，參見代碼示例。

規(guī)則狀態(tài)接口ECState：

public interface ECState {

void subscribe(String specName， String uri);

void unsubscribe(String specName， String uri);

EPCReports poll(String specName);

}

未被請(qǐng)求狀態(tài)類ECStateUnrequested：

public class ECStateUnrequested implements ECState {

}

已被請(qǐng)求狀態(tài)類ECStateRequested：

public class ECStateRrequested implements ECState {

}

激活狀態(tài)類ECStateActive：

public class ECStateActive implements ECState {

}

規(guī)則類ECSpec：

public class ECSpec {

private ECState state;

public ECState getState() {

return state;

}

public void setState(ECState state) {

this.state = state;

}

}

這樣，在針對(duì)規(guī)則實(shí)施相應(yīng)操作的時(shí)候，就可以直接把相應(yīng)操作委派給其狀態(tài)屬性(ECState)去做即可。比如，ECSpec的subscribe操作，只需一行代碼“state.suscribe(specName， uri);”即可。其中，specName、uri為臨時(shí)變量，具體取值在方法調(diào)用之前確定。

由面向?qū)ο蟮亩鄳B(tài)性特征，根據(jù)state字段目前所指向的對(duì)象來動(dòng)態(tài)確定由ECState接口的哪一個(gè)具體的實(shí)現(xiàn)類的代碼來完成工作。ECState接口的實(shí)現(xiàn)類根據(jù)實(shí)際情況確定是否需要在處理過程中修改ECSpec對(duì)象的狀態(tài)屬性(state)，此處在應(yīng)用狀態(tài)模式時(shí)，需要設(shè)計(jì)多個(gè)定時(shí)器類來輔助狀態(tài)機(jī)的跳轉(zhuǎn)[3]。

3.4 策略模式切換多種報(bào)告上傳、命令下發(fā)方式

事件周期結(jié)束之后，中間件需要組裝報(bào)告上傳給規(guī)則的預(yù)訂者，即應(yīng)用系統(tǒng)。上傳的方式有多種，如HTTP、Socket、JMS等等。中間件的核心邏輯處理模塊不應(yīng)該關(guān)心具體的上傳技術(shù)，相應(yīng)工作應(yīng)交給報(bào)告上傳模塊來做，核心邏輯處理模塊只須完成自己的工作，然后把一定格式的數(shù)據(jù)通過報(bào)告上傳模塊發(fā)送，參見代碼示例。

報(bào)告發(fā)送接口ReportSender：

public interface ReportSender {

void sendReport(ECReports reports);

}

通過Http方式發(fā)送報(bào)告的ReportSender接口實(shí)現(xiàn)類ReportSenderByHttp：

public class ReportSenderByHttp implements ReportSender {

public void sendReport(ECReports reports) {

}

}

通過Socket方式發(fā)送報(bào)告的ReportSender接口實(shí)現(xiàn)類ReportSenderBySocket：

public class ReportSenderBySocket implements ReportSender {

public void sendReport(ECReports reports) {

}

}

通過JMS方式發(fā)送報(bào)告的ReportSender接口實(shí)現(xiàn)類ReportSenderByJms：

public class ReportSenderByJms implements ReportSender {

public void sendReport(ECReports reports) {

}

}

報(bào)告發(fā)送示例客戶端類

SendReportWorker：

public class SendReportWorker {

private ReportSender sender;

private ECReports reports;

public void setReports(ECReports reports) {

this.reports = reports;

}

public static void main(String[] args) {

SendReportWorker worker = new

SendReportWorker();

worker.sender.sendReport(reports);

}

public void setSender(ReportSender sender) {

this.sender = sender;

}

}

這樣，發(fā)送消息的工人類可通過設(shè)置ReportSender的實(shí)例來靈活設(shè)置其發(fā)送方式。

同樣，中間件的清點(diǎn)命令下發(fā)，即中間件與閱讀器之間的接口，也存在多種方式，如Socket、SOAP等，也可采用類似的設(shè)計(jì)。

3.5 觀察者模式處理上報(bào)消息

閱讀器的消息上報(bào)轉(zhuǎn)換為消息對(duì)象，對(duì)消息對(duì)象的接收、分發(fā)可采用經(jīng)典的觀察者模式實(shí)現(xiàn)。

4 中間件發(fā)展方向

4.1 與閱讀器管理系統(tǒng)的融合

中間件是閱讀器與后臺(tái)應(yīng)用系統(tǒng)之間的橋梁，而閱讀器通常有設(shè)備管理需求，比如軟件版本下載、設(shè)備告警管理、參數(shù)配置等等，閱讀器管理系統(tǒng)也是直接與閱讀器交互的軟件模塊。于是，如何處理好中間件與閱讀器管理系統(tǒng)之間的關(guān)系成為一個(gè)亟待解決的問題。

從軟件部署(部署在同一臺(tái)主機(jī)上)、軟件模塊重用(重用閱讀器通信模塊)等角度考慮，中間件與閱讀器管理系統(tǒng)的融合勢(shì)必成為中間件本身的一個(gè)優(yōu)勢(shì)。

4.2 對(duì)多標(biāo)準(zhǔn)標(biāo)簽的支持

RFID技術(shù)在國(guó)內(nèi)外的發(fā)展和應(yīng)用方興未艾，國(guó)際上多個(gè)標(biāo)準(zhǔn)組織都試圖統(tǒng)一RFID標(biāo)準(zhǔn)，但在一定的時(shí)期內(nèi)，勢(shì)必出現(xiàn)多標(biāo)簽并存的情況。于是，對(duì)多標(biāo)準(zhǔn)標(biāo)簽的支持也是中間件系統(tǒng)的一個(gè)發(fā)展方向。

4.3 對(duì)多廠商閱讀器的支持

中間件與閱讀器之間的接口、通信方式以及信息格式，也無法做到統(tǒng)一標(biāo)準(zhǔn)。對(duì)多廠商閱讀器的支持、至少對(duì)少數(shù)幾家主流廠商的閱讀器的支持，已經(jīng)是對(duì)中間件所提出的基本要求。

5 參考文獻(xiàn)

[1] EPCglobal Inc. The EPCglobal architecture Framework [R]. 2005.

[2] EPCglobal Inc. The application level events specification [R]. 2005.

[3] GoF. Design patterns [EB/OL]. http://www.tiempolibresite.com/index2.php?option=com_contentdo_pdf=1id=489.

收稿日期：2007-05-22

作者簡(jiǎn)介

王振宇，碩士，畢業(yè)于華中科技大學(xué)。現(xiàn)工作于中興通訊股份有限公司研發(fā)體系CDMA研究所，三級(jí)主任工程師。負(fù)責(zé)RFID相關(guān)的中間件、網(wǎng)絡(luò)設(shè)備管理、各類企業(yè)應(yīng)用等軟件系統(tǒng)的分析、架構(gòu)；長(zhǎng)期從事面向?qū)ο筌浖_發(fā)、敏捷軟件開發(fā)等領(lǐng)域的研究。

杜江，桂林電子工業(yè)學(xué)院碩士畢業(yè)。中興通訊股份有限公司研發(fā)體系天津研究所所長(zhǎng)、RFID產(chǎn)品總經(jīng)理，現(xiàn)負(fù)責(zé)RFID產(chǎn)品經(jīng)營(yíng)、RFID系統(tǒng)總體設(shè)計(jì)。曾長(zhǎng)期從事3G CDMA大型通信系統(tǒng)的研發(fā)工作，并負(fù)責(zé)CDMA基站系列化規(guī)劃、系統(tǒng)方案制訂、產(chǎn)品演進(jìn)規(guī)劃工作。

張建，哈爾濱工業(yè)大學(xué)碩士畢業(yè)。中興通訊股份有限公司研發(fā)體系天津研究所二級(jí)主任工程師、RFID產(chǎn)品總工，現(xiàn)負(fù)責(zé)RFID產(chǎn)品系統(tǒng)設(shè)計(jì)、RFID中間件技術(shù)、RFID空中接口技術(shù)研究。長(zhǎng)期從事3G平臺(tái)開發(fā)工作，曾承擔(dān)國(guó)家“863”計(jì)劃高性能IPv6路由器項(xiàng)目的研究開發(fā)工作。