efficient naming, addressing and profile services in internet-of-things sensory environments

Ad Hoc Networks xxx (2013) xxx–xxx

Contents lists available at SciVerse ScienceDirect

Ad Hoc Networks

journal homepage: www.elsevier .com/locate /adhoc

Efficient naming, addressing and profile services inInternet-of-Things sensory environments

1570-8705/$ - see front matter � 2013 Elsevier B.V. All rights reserved.http://dx.doi.org/10.1016/j.adhoc.2013.02.008

⇑ Corresponding author. Tel.: +86 (0) 10 58748833; fax: +86 (0) 1058748330.

E-mail addresses: [email protected] (C.H. Liu), [email protected] (B.Yang), [email protected] (T. Liu).

1 Diamond Building 19A, Zhongguancun Software Park, Haidian District,Beijing 100193, China.

2 IBM Software Group, 3/F Ring Building, Zhongguancun Software Park,Haidian District, Beijing 100193, China. Tel.: +86 (0) 10 58748433; fax: +86(0) 10 58748330.

Please cite this article in press as: C.H. Liu et al., Efficient naming, addressing and profile services in Internet-of-Things sensory ements, Ad Hoc Netw. (2013), http://dx.doi.org/10.1016/j.adhoc.2013.02.008

Chi Harold Liu a,⇑,1,2, Bo Yang b,2, Tiancheng Liu a,2

a Internet-of-Things Infrastructure Management, IBM Research, Chinab Emerging Technology Institute, IBM China Development Laboratory, China

a r t i c l e i n f o a b s t r a c t

Article history:Received 26 July 2012Received in revised form 8 December 2012Accepted 22 February 2013Available online xxxx

Keywords:Internet-of-ThingsNaming and addressingMiddlewareSystem designs and implementation

We present a naming, addressing, and profile server (NAPS) as a middleware to bridge dif-ferent platforms in Internet-of-Things (IoT) sensory environments. Given massive amountof heterogeneous devices deployed across different platforms, NAPS serves as the key mod-ule at the back-end data center to aid the efficient upstream sensory data collection, con-tent-based data filtering and matching, and downstream efficient control by applications.While previous research efforts only focus on a specific standard or protocol, we aim todesign a middleware component servicing dynamic application needs, and sensors/actua-tors deployment and configurations across different platforms. Specifically, we propose acomplete design of NAPS, including its key functionalities, system flows, interfaces, andindividual module design. We further propose a unique device naming and addressing con-vention, and show its applicability to a few widely-used standards and protocols. We alsopropose an efficient identifier generation scheme; and we demonstrate a full implementa-tion of the above designs with a case study, including a service registration portal. Finally,performance evaluation is done against the system throughput.

� 2013 Elsevier B.V. All rights reserved.

1. Introduction

The Internet-of-Things (IoT) is a novel paradigm rapidlygaining wide attention from academia, industry and gov-ernment agencies [1,2]. Its basic concept is that ‘‘. . . thingshaving identities and virtual personalities operating insmart spaces using intelligent interfaces to connect andcommunicate within social, environmental, and user con-texts. . .’’ [3]. These global networked things include RadioFrequency Identification (RFID [4]) tags, ZigBee sensors,

smart phones, etc. An example is that the US Departmentof Environmental Protection deploys thousands of waterpollutant and water level sensors in Hoover Dam to period-ically monitor its water quality and potential hazardousscenarios.

Nevertheless, the lack of a de facto standard architectinga naming, addressing and profile server (NAPS), as a mid-dleware [5] interoperable with heterogenous platformshas become a key limiting issue on its proliferation todeployment [6]. The research community are hearing thestrong desire from application developers to avoid learningheterogenous communication/networking protocols inuse, but be provided a homogeneous naming and address-ing convention, so that they are able to retrieve the datafrom sensors and control the actuators of different plat-forms and network domains. Towards this end, a higherlayer of device naming-addressing mapping should be pro-vided to integrate with legacy systems and different plat-forms. As for device naming, the convention should

nviron-

http://dx.doi.org/10.1016/j.adhoc.2013.02.008

mailto:[email protected]




http://www.sciencedirect.com/science/journal/15708705

http://www.elsevier.com/locate/adhoc


2 C.H. Liu et al. / Ad Hoc Networks xxx (2013) xxx–xxx

contain key elements of device meta-data, such as devicetype and domain information; while for addressing, its for-mat allows the granularity of efficient accessibility andaddressability to the physical world. Profile services arealso needed to aid the application query and system con-figurations, like device status and presence. Furthermore,sensing tasks are always achieved by a group of deviceswith similar sensing capabilities, and thus NAPS shouldprovide device group management functionalities, suchas to create, update, read, and delete (CURD) groups (andits tree-structured subgroups). In this way, applicationdevelopment logic is greatly simplified where only a devicegroup name is needed and NAPS handles the internal map-ping. As a middleware, it should extend its usability byproviding abundant external interfaces.

IPv4, IPv6 and Dynamic Name Service (DNS) are usuallyconsidered as the candidate standard for naming andaddressing, however due to the lack of communicationand processing capabilities of many small and cheap de-vices (like RFID tags) it is quite challenging to connectevery ‘‘thing’’ with an IP. Furthermore, with the increasingamount of end devices, even IPv6’s address space may notenough. On the other hand, industry standards have putmuch effort in each application domain. EPCglobal [7] usesa 96-bit binary sequence to identify each RFID tag, and theobject name service (ONS) for URL translation. OPC-UA [8]defines client–server based models for industrial produc-tion line solutions, where an abstract address space isformed by a mesh topology. In it, each node represents asensor in the production stage and the edge between twonodes represents the stage-by-stage relationship duringthe production. As an overall service architecture, ETSI[9] proposed a solution interworking with 3GPP machinetype communication (MTC) standard [10], to support ma-chine-to-machine (M2M) communications when upgrad-ing from traditional cellular networks where each deviceis with a unique international mobile subscriber identity(IMSI) and is IP addressable. Furthermore, as a service layerarchitecture, it defines a variety of service capabilities (SCs)including a Network Reachability, Addressing, and Reposi-tory (NRAR) SC. However, it has no technical details thisfar. Our goal in this work is to work with any service plat-forms as a middleware at the back-end data center. There-fore, all these efforts pay attention only to a specificnetwork or application domain, however not applicableas a common platform managing different technologiesand standards.

1.1. Scope and assumptions

Motivated by these facts, Fig. 1 shows an overall archi-tecture from the physical phenomenon all the way up tothe data center, considered in this paper. Devices such assensors and actuators sense/control the physical world,which are interconnected either wirelessly or wiredthrough a variety of access network technologies. A fewknown examples are cellular networks (2G/3G/LTE), IEEE802.11/802.15 series of standards for WiFi, ZigBee, andBluetooth, RFID readers and tags, and wireline technolo-gies like power-line communications (PLC), etc. Usually

Please cite this article in press as: C.H. Liu et al., Efficient naming, addrments, Ad Hoc Netw. (2013), http://dx.doi.org/10.1016/j.adhoc.2013.02

there exists a gateway interconnecting the access networksand the backbone Internet.

Data are then routed either through the carrier publicnetwork or IoT private network. For the former, standardlike 3GPP MTC is defined to upgrade the existing backbonecellular network to manage M2M devices. For the latter,most service layer architectures, like EPCglobal RFID archi-tecture or OPC-UA client–server model, leverage existingtransport layer protocols such as CoAP [11] over UDP,and HTTP over TCP. In the service layer, ETSI M2M servicearchitecture can interwork with 3GPP MTC via interwork-ing function (IWF) that enables seamless integration ofM2M SC layer with cellular MTC devices. That is, M2MSCs can invoke and leverage cellular MTC functions to opti-mize and support better M2M services. Meanwhile, cellu-lar MTC functions can be enhanced for M2M SCs.Companies like InterDigital and Juniper Networks have thiskind of solution [12,13].

Towards this end, there is lack of a common platforminteroperable with different platforms to hide this hetero-geneity and provide a transparent naming service to appli-cations. We therefore design an IoT - applicationinfrastructure (IoT-AI) and its management platform (outof scope of this paper), as shown in the figure. The keytechnical entablements of IoT-AI are: application gateway(AG), NAPS and its service registration portal (Portal), andreal-time operational database (RODB). AG coordinatesthe data filtering and processing, and control messagedelivery based on a uniform device naming and addressingconvention in NAPS. The goal is to have applications accessdevices across different platforms without knowing theirlanguages in detail, but focusing on the development logiconly. The position of NAPS extends the functionality com-parable to DNS in the Internet, to the profile services suchas storage and query. We next present three assumptionsof this work.

First is service discovery. Since the scope of NAPS is amiddleware component at the back-end data center tohide the heterogenous protocols and standards, here weassume that service discovery has already been success-fully performed by each platform individually, and storedin our NAPS repository. Examples are service discovery ser-ver enhanced from ETSI M2M service architecture by Inter-Digital [12], discovery service set in OPC-UA standard, andprotocols like Universal Plug and Play (UPnP) [14], etc.

Second is the authentication, authorization andaccounting (AAA). Although it is not the focus of this work,the design can largely leverage the Network Security Capa-bility (NSEC) SC in ETSI M2M service architecture. It uses akey hierarchy, composed of root key, service key, andapplication keys. Root key is used to derive service keysthrough authentication, and key agreement between thedevice or gateway and the M2M SCs at the M2M Core.The application key, derived from service key, is uniqueas per M2M application. Issues like distributed denial-of-service (DDoS) attack will be discussed in Section 7.

Finally, we assume that wireless imperfection like pack-et errors and interference have been handled by the com-munication stack of each access networks. Solutions fromPHY layer techniques (e.g., antenna techniques, modula-tion and coding) and MAC/network layer protocols (e.g.,

essing and profile services in Internet-of-Things sensory environ-.008


Man

agem

ent

OnlineAnalysis

OfflineAnalysis

Monitor andControl

AGNaming, Addressingand Profile Server

(NAPS)RODB

RESTful and JDBC APIs

IoT - AI

AAA

Industry Applications

Middleware

TransportLayer

PHY/MAC Layer

Applications Portal …

Data Center

RESTful and JDBC APIs

Device Hardware

Physical World

Cellular(2G/3G/LTE)

IEEE 802.11IEEE 802.15, etc.

(WiFi, Bluetooth, ZigBee)RFID Wireline

(PLC, etc.)

Transport Protocols(CoAP/UDP, HTTP/TCP)

EPCglobalArchitecture

IoT Private Network

3GPP MTC

ETSI M2M Service Architecture

Carrier Public Network

IPv4/IPv6

Access Networks

OPC-UAArchitecture

…

Fig. 1. An overall architecture considered in this paper.

C.H. Liu et al. / Ad Hoc Networks xxx (2013) xxx–xxx 3

scheduling and routing) are a few examples. Therefore, anywireless issues are completely transparent to the servicelayer operations, or the NAPS middleware considered inthis paper.

1.2. Contribution and paper organization

Our contributions are summarized as fourfold. First, wepropose a complete and detailed design of NAPS, includingits key system flows, interfaces, and individual module de-signs. Second, we propose a unique device naming andaddressing convention interworking with different plat-forms, and we show its applicability to a few widely-usedstandards and protocols. Third, we propose an efficientidentifier generation scheme, not only used during datatransportation, but also to facilitate the data filtering andmatching. Fourth, we provide CURD operations on device,device type, and device group profiles, in the RESTful de-sign style [15] over HTTP at runtime. Meanwhile, we pro-vide a JDBC library so that external applications canaccess large amount of profile information (in the scale ofgigabyte), where HTTP falls in short. Finally, we demon-strate its usage by a case study in a smart building environ-ment and show performance evaluation result on systemthroughput. To the best of our knowledge, this is the firstpiece of work to tackle the fundamental design issues ofnaming, addressing and profile services as a middlewareacross different platforms by demonstrating its usagethrough a real implementation. A summary of importantacronyms used in this paper is listed in Table 1.


The rest of this paper is organized as follows. Related re-search activities are introduced in Section 2. System con-text and flows are described in Section 3. Section 4presents the detailed system design and implementationissues. Next, performance evaluation is given in Section 6.After discussing the a few related practical issues in Sec-tion 7, and a conclusion is drawn in Section 8.

2. Related work

EU FP7 project IoT-Architecture (IoT-A) extensively dis-cussed the existing architectures, protocols, and platforms[16]. Besides, in [17] authors propose a framework to inter-connect sensors running 6LoWPAN [18], where IEEE802.15.4 and IPv6 were considered to connect wireless de-vices to the Internet. In [19], they provide an XML schemato encode device profile information including its localname. Web-of-things (WoT, [20]) make use of popularWeb languages for building applications involving smartthings and users.

As for industrial standards, based on DNS, the pure IPsolution [21] is favored due to the recent development ofIPv6 to connect ‘‘things’’ for IoT. EPCglobal [7] specializesin use of RFID in the information rich and trading net-works, especially for logistics. In it, similar to DNS, an ob-ject name service (ONS) is designed to translate a 96-bitbinary sequence to a URI, which directs the query to a(set of) database(s) called EPC information service forinformation retrieval and update. OPC-UA [8] defines anaddress space where devices are interconnected to form



Table 1Summary of important acronyms.

Acronyms Meaning

IoT Internet-of-ThingsM2M Machine-to-MachineSC Service capabilityNAPS Naming, addressing, and profile serverRFID Radio frequency identificationCURD create, update, read and deleteNRAR Network reachability, addressing and repositoryOPC-UA OLE for process control – Unified ArchitectureIoT-AI Internet-of-Things application infrastructureRODB Realtime operational databaseAG-FEP Application gateway – front-end processorAG-BE Application gateway – back-endAG-CC Application gateway – command controllerAAA Authentication, authorization and accountingIBM WAS-

CEIBM Websphere Application Server – CommunityEdition

devID device identifierJava PO Java persistent objectJava DAO Java Data Access ObjectAPI Application Programming InterfaceURI uniform resource identifierXSD XML Schema DefinitionJDBC Java Data Base ConnectivityJVM Java virtual machine

Applications Portal

AG-CC

AG-BE NAPS

AG-FEA

RODB

RESTful RESTful

RESTful

JDBC

REStfulJDBC

JDBC

RESTful

Fig. 2. System context of NAPS and the associated application-layerinterfaces.


a mesh topology. The connectivity represents the produc-tion line sequence, where the directional edge called ‘‘ref-erence’’ links the next stage of behavior. ETSI M2M servicearchitecture [9] assumes each M2M device is IP address-able. In 3GPP MTC [10], they propose to use the IMSI asthe internal identifier for signalling and charging, whileproviding external identifiers to include domain informa-tion under the control of a network operator, and flexiblyallocated descriptions as the customer friendly localidentifier.

On the other hand, naming and addressing for wirelesssensor networks have been extensively investigated [22–25]. The first kind of approaches rely on the efficient ad-dress allocation among nodes, where in [26,27] the as-signed addresses are reused spatially and represented byvariable length of codewords. This was later extended in[28] which used the prefix-free Huffman encoding of nodeaddresses based on the energy map, where nodes with lit-tle battery life left will have the advantage of a short ad-dress and check period. [29] proposed the ‘‘attributed-based naming’’. In [30], clients use an intentional nameto request a service without explicitly listing the end-nodethat ultimately serve the request. This level of indirectionallows applications to seamlessly continue communicatingwith end-nodes even though the mapping from name toend-node addresses may change during the session. Final-ly, unique identifier generation problem is investigated in[31], where they designed a correlated lookup scheme witha distributed hash table to improve the performance ofidentifier management.

However, none of these schemes are motivated fromthe service layer as part of the middleware at the back-end data center, nor tackle the fundamental problem ofproviding a homogenous, both human and machine under-standable, and unique naming and addressing convention


across different platforms. Furthermore, none of them sup-port profile services and legacy system integration.

3. System flows

To support the high scalability requirement, we furtherdecompose AG into four modules, front-end processor(FEP, for data collection and format transformation), com-mand controller (CC, for application command parsingand translation from NAPS), back-end processor (BE, forrule-based data filtering and matching), and messagequeue (MQ, for publish-subscribe based topic services[32]). Then, users can identify its bottleneck and scaleup/out the corresponding component. For example, to de-ploy MQs for large number of applications in a Cloud.The list of components that interact with NAPS either off-line or at runtime are AG-FEP, AG-CC, AG-BE, applications,portal, and RODB, as shown in Fig. 2 for system context andassociated interfaces. It is worth noting that the overallIoT-AI platform is only used as an example to demonstratethe system flow of NAPS, whereas its applicability can ex-tend to any external component with similar interfaces.We next present three key system flows, service registra-tion and configurations, upstream data collection anddownstream command delivery. In all aspects, an AAA ser-ver interacts with NAPS for security authentication andauthorization, and we left the details for future work.

3.1. Device registration and configurations

As discussed earlier, service discovery is performed atindividual platform beneath the data center service layer,and NAPS only provides a set of interfaces to facilitatethe device registration, either automatic or offline. The reg-istered capabilities include the ones offered by devices, de-vice types, and device groups, and thus the repositorystores the corresponding profile information. The providedinterfaces are based on the RESTful design style wherestandard HTTP request/response is used to transport thedata. It is worth nothing that before the response is re-turned to the client, we generate a unique device identifier,or ‘‘devID’’ for the rest of the paper (see Section 4.3). It con-tains key elements of the device meta data. Note that thisdevID generation process is also applicable when device



AG-FEP AG-BE AppMQ

NAPS

data

RESTdevName devID

devID devName devNameAG

AAA

AG-FEP AG-BE AppMQ

AG-CC

NAPS

cmd@devNamecmd@grpName

cmd@devNamecmd@grpName

cmd@grpName

cmd@devIDs

cmd@devIDscmd@devAddrs

AGcmd@devAddrs

AAA

AG-FEP AG-BE App MQ

AG-CC

NAPS

criterion

grpName(s)/devName(s)

• List of Supported Criterions– Blurred device/group names– Device/group location– Device/group domain

AG

AAA

(a)

(b)

(c)Fig. 3. System flow: (a) upstream data collection, (b) downstream command delivery, and (c) application query.


type and device group are registered. For service bootstrap,other components like AG and RODB can establish JDBCconnection to retrieve these meta data from the database.

3.2. Upstream data collection

As shown in Fig. 3a, when receives the raw data from anIoT platform, AG-BE translates the devID to the corre-sponding device name (devName) as more friendly to theapplication. Meanwhile, AG-BE makes use of devID to per-form efficient content-based data filtering and matching.For example, one application configures a topic on MQ toaggregate and average the room humidity data in a smartbuilding environment. Then, since the designed devID con-tains key elements of device meta data such as associateddomain information and device type, it helps to categorize,filter and select the exact set of raw data from the massive


data pool. This can be achieved by masking certain en-coded profile parameters. To save the overhead, we use de-vID as the unique identifier in the transport (e.g.. throughthe carrier public network and IoT private network asshown in Fig. 1), while using devName containing a setof human-readable properties for applications.

3.3. Downstream command delivery

Fig. 3b shows the downstream system flow when con-trol messages are initialized by the application to specificdevice groups. First, device (group) name is passed to theAG-CC, and the latter retrieves the (list of) devID(s) fromNAPS over the RESTful interface. Then, AG-FEP translatesthe devID(s) to the corresponding device address(es) fromNAPS, in which it specifies how to address the command(s)to the exact (group of) device(s). In this way, similar to the



RESTful API

DeviceProfiles

Device Group Profiles

Container(IBM WAS-CE)

JDBC

Persistent Object

Device Type Profiles

IBM DB2

REST Toolkit JDBC Toolkit

Services

Data Access Object(DAO) JDBC Library

Device Domain Profiles

Fig. 4. NAPS component design.


functionality of DNS in the Internet, NAPS performs thename-to-address resolution. It is worth noting that ouraim is not to design completely new transport protocolsto inter-operate with heterogenous network domains likecellular networks and ZigBee. However, we only define athin layer for address resolution, as a uniform conventionto unify and cooperate different platforms. In our address-ing convention (see Section 4.2), it specifies the way toroute the command to the Internet gateway, which is IPaddressable, such as the M2M gateway in ETSI M2M ser-vice architecture, OPC-UA server, or WiMax base station(as considered in the case study). In a hierarchy, thesegateways further route the command to the next levelgateway (e.g.. the ZigBee coordinator) which maintainsits own addressing mechanism to the device.

3.4. Application query

Application developers may be same as, or as a futuretrend, different from the device owners. Therefore, theirdevelopment logic entirely relies on identifying the rightset of devices from the physical world, which may eventu-ally belong to different network domains/platforms. To-wards this end, since the device, device type and devicegroup profiles are registered and stored in NAPS repository,we allow search services to retrieve a list of devices anddevice groups with certain geographical, domain, and de-vice name information. Furthermore, this process can becoupled with downstream command delivery procedurewhere a retrieved list of device and device group namesare used to issued commands to the physical world.

3.5. Integration with different IoT platforms

Nearly all third-party device vendors and platformoperators have their own naming mechanism, and it islikely that they also have already developed their ownapplications. Therefore, to ease the integration process,the exposure of the proposed uniform device naming isnot the most convenient way. Towards this end, NAPS pro-vides the translation between our uniform naming conven-tion and the legacy naming, offering shared services todifferent vendors and applications. We thus provide twoRESTful interfaces, getDevOldNamebyDevName() andgetDevNamebyDevOldName(), where the former is usedwhen the upstream data are received by the application at-tached with our device name, and thus to be translated tothe legacy name, and the latter is used when applicationsissue commands to the actuators by translating the legacynaming to the proposed one. In this way, existing namingplatforms like 3GPP MTC and EPCglobal can be seamlesslyintegrate with our NAPS middleware.

4. System designs and implementations

Since one of the functionality of NAPS is to store theregistered profile information, among many choices, ourimplementation uses IBM DB2 as the relational databaseto store all devices, device types and device groups relatedprofile information. A JDBC library is used as an interface


for the Web container (where Java code resides) to accessthe database (see Fig. 4). We choose IBM WAS-CE as thiscontainer that hosts an Apache Tomcat application serverand other necessary programming supports. Within theWeb container, NAPS implements the data persistency,data access object (DAO), service layer, and RESTful APIs;and in parallel, JDBC library and client-side toolkits. Next,we show key functionalities of each internal module.

Java PO: Java persistent object, which specifies the one–one correspondence from a Java object to the database en-tries, columns, and relations. Persistency is also imple-mented by using the open source packages like ApacheopenJPA.

DAO: basic database operations, like delete, get, query,save, update, and above operations in batch are definedand implemented by using the Java PO.

Services: in this layer, RESTful resource URIs aredecomposed into the Java PO consistent with the samedatabase design, e.g., entry names, column names and theircorresponding values. Then, HTTP method calls are trans-lated into internal APIs which will be further decomposedinto database basic operations defined in the DAO layer.Service logics are also maintained, and in particular for de-vice deletion related operations, this layer will help checkthe related device group profile and perform the updateaccordingly.

JDBC library: provides a wrapper from the JDBC opera-tions to the Java package.

RESTful API: serves as the external interface to sendand/or receive response/request to the clients.

For sake of completeness, we also describe table designson IBM DB2, as shown in Fig. 5. Four key tables are device,device type, device group, and device domain tables, withthe one-to-many mapping between the device types anddevices, many-to-many mapping between devices and de-vice groups, and one-to-many mapping between devicedomain and devices.



Device Profile

PK devID:long

devName:stringaddress:stringprotocol:string

FK1 devTypeID:longsamplingInterval:doubletimeSeriesFlag:booleanlocation:stringsn:stringdomain:string

FK2 ruleID:longstatus :intdevID_old:stringcontrollable:booleanreadwrite:intmobile:boolean

Device Type Profile

PK devTypeID:long

devTypeName:stringdataSchema:stringmanufacturer:stringpersistentFlag:booleantimeItemTag:int

Group Profile

PK grpID:long

grpName:stringcreateTime:longlifetime:longcreator:stringremark :stringstatus:intseq:int

Dictionary

PK DictID:long

DictName:stringDescription:stringGroupID :stringState:int

1

* 1

JDBC Account Profile

PK UserID:long

UserName:stringPassword:stringIPaddress:stringAccessControl:int

FK: status,

FK: manufacturer

FK: protocol, status

*

*

1

Domain Rule Profile

PK ruleID:long

ruleName:stringseq:intlevels:intassignment:string

Domain Node Profile

PK domainNodeID:long

domainNodeName:stringFK1 ruleID:long

parentID :longlevel:intseq:int

*1

*

1

Junction Table - Dev/Grp

FK1 devID:longFK2 grpID:long

grpName:stringdevName:sting

Rule Assignment

FK1 ruleID:longlevelIndex:intnoNodeperLevel:intbits:int

* 1

Device Domain

Device Device Type Device Group

Fig. 5. Table designs for device, device type, device group and device domain tables.


4.1. RESTful interfaces

We expose RESTful APIs to external users. In REST, cli-ents initiate requests to servers that process requests andreturn appropriate responses, neither the client nor theserver need to store the transitional states between the ex-changed messages. This restriction isolates the client ofchanges in the server side. REST uses a set of HTTP meth-ods, known as POST, GET, PUT and DELETE, correspondingto a complete set of CURD operations. To this end, this is aperfect technology to describe application activitiesincluding profile browsing, look-up, update and delete.

The requests and responses in REST are built around thetransfer of ‘‘representations’’ of ‘‘resources’’. We define re-sources in NAPS as the device, device type, and devicegroup meta-data, rather than the ‘‘actions’’ on it. For in-stance, to retrieve an entire device record, one should usethe GET method requesting the URI as: . . . /devices/de-

vid/{id}, where the devid denotes the devID as the keyto the device profile table entry. Fig. 6 shows the proposedtree-based URI structure. Followed by the NAPS IP addressand port,3 three types of root resources are defined, i.e.. de-vices, device types, and device groups. After, we use the for-

3 or server URL, and if considering the cluster deployment, this addresscorresponds to the address of server dispatcher, allowing to direct the clientrequest to the corresponding NAPS.


mat of attribute name-value to explicitly indicate a specificleaf resource as the operand. For example, if one writes‘‘. . . devices/devid/{724487363}’’, then it maps to the re-cord entry with its key equals to devid and value equals to724487363. However, if detailed attribute name-value infor-mation is omitted, like ‘‘. . . devices/’’, ‘‘. . . devices/⁄’’ or‘‘. . . devices/devid/⁄’’, then it operates on all leaf re-sources (all devices in this case). It is worth nothing thatour design also supports the multiple leaf resource opera-tions under one root resource, i.e.. we use ‘‘&’’ to concatenatemultiple values, e.g.. ‘‘. . . /devices/devid/{id1}&{id2}&{id3}’’.

We next explain the use of four HTTP methods on ourRESTful resource.

POST: to submit the data from the client to be pro-cessed at a target resource, resulted in the creation of anew or an update of the existing resources. The data are in-cluded in the body of the request, in the format of XML. Weuse this method to register a new profile.

GET: to request the information the specified resource,e.g.. making a request GET in . . . /devices/devid/

{724487363} will return as a response to the device recordwith devID = 10. We use this method to retrieve the profile.

PUT: updates the a resource’s particular set of informa-tion, and if request URI does not exist, it allows to create anew resource. In our example, if one aims to update the se-rial number of a device, clients make a PUT request to: . . . /



devices

devtypes

PUT createDevProfiledevid/{devid} POST updateDevProfiledevid/{devid} GET getDevProfiledevname/{devname}/devid GET getDevIDbyDevNamedevid/{devid}/devname/ GET getDevNamebyDevIDdevid/{devid}/addr GET getDevAddrdevid/{devid} DELETE delDevProfilesearch?key1={val1}&key2={val2}& GET searchDev

PUT createDevTypeProfiledevtypeid/{devtypeid} POST updateDevTypeProfiledevtypeid/{devtypeid} GET getDevTypeProfiledevtypeid/{devtypeid} DELETE delDevTypeProfile

groups PUT createGrpProfilegroupid/{groupid} POST updateGrpProfilegroupid/{groupid} GET getGrpProfilegroupid/{groupid}/devidlist/{devid} POST addDev2Grpgroupid/{groupid}/devidlist/{devid} DELETE delDevfrmGrpgroupid/{groupid} DELETE delGrpProfilegroupname/{groupname}/devidlist GET getDevIDbyGrpName

http://<serverURL>

Fig. 6. RESTful URI design for NAPS.


devices/devid/{724487363}/serialnumber/{456WEFGA}, where 456WEFGA is the refreshed data. Weuse this update an existing profile.

DELETE: to delete a specified resource without an XMLbody. For instance, if one requests URI: . . . /devices/de-

vid/{724487363}, it deletes the device record with de-vID = 724487363, however the service layer will check itsrelations to the device group to make sure the mappingis also removed. We use this method to delete an existingprofile.

Tables 2 and 3 show RESTful APIs to retrieve and searchdevices (under condition), respectively.

4.2. Naming and addressing convention

We propose a novel naming convention for devices anddevice groups across different platforms in a form of:

dev://domain-series/devtype/legacy-name,grp://domain-series/target/policy/grp-name,

where the prefix distinguishes its category (as for de-vices or device groups), followed by a series of device do-main information. The device domain is organized in atree structure, written in the above naming conventionback trace from the leaf to the root node of the domain

Table 2RESTful API to get device profile information.

URI http://<serverURL>/devices/devid/{724487363}&. . .

/paging?startindex=0&count=100http://<serverURL>/devices/devid/⁄

/paging?startindex=0&count=100Method GETQuery string startindex: start index, default = 0

count: No. of records needed., default = 50Returns 200 OK & XML response

404 Not Found500 Internal Error


tree. After the domain series, for devices we use the devicetype information to further categorize all devices associ-ated with a domain node on the leaf of the tree, and finallythe legacy naming (e.g.. serial number) from the produc-tion phase. Meanwhile, device groups use the monitoringtarget (e.g.. the room temperature) and grouping policyfor detailed classification.

Device domain information refers to either their de-ployed geographical information, or logical organizationof these devices. In NAPS, we allow to store multiple devicedomains, and each domain indexed r is a tree structurewith depth dr and width of each level as

wir ;8i ¼ 1; . . . ; dr

� �. In other words, domain r is composed

of total Nr ¼Pdr

i¼1wir domain nodes. We call the ‘‘partition’’

of a domain tree by parameters dr ; wir

� �� as the ‘‘domain

rule’’, and the corresponding data structure representationas ‘‘rule assignment’’. For example, the rule assignmentparameters are number of bits to store the domain nodesin each level of the tree. The meta data of each node in-clude the name, its parents and children, and other proper-ties; see Fig. 5. In practice, project managers of an IoTsystem will carefully plan the device deployment at a siteof interest, where the first step is to plan an overall devicedomain. For example, in a smart building environment,how many temperature and humidity sensors of what de-vice type should be deployed at which location, and thisdeployment stage eventually specifies a domain tree struc-ture, and stored in NAPS repository.

Table 3RESTful API to search devices under condition.

URI http://<serverURL>/search?key={val1}&key={val2}&. . .

Method GETQuery

stringKey = location, domain, devname, devtype

Returns 200 OK & XML response404 Not Found500 Internal Error



Table 4Examples of device addressing convention with different protocols.

Protocol Example

OPC-UA nodeID@opcua/<OPCUA-ServerURL>ZigBee short-address@zigbee/<coordinatorIP:port>RFID binary-epc@rfid/<readerIP:port>IP-based <ip-address:port>@httpBluetooth MAC-address@bluetooth/<receiverIP>WiFi 192.168.x.x@wifi/<access-point-IP>USB VendorID-ProductID@USB/<ip-addr>


As for device addressing convention, we propose to usethe format:

address� 1@protocol� 1= . . . =address� n@protocol� n|fflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl{zfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl}non�IP networks

=IP

� address;

to accommodate heterogenous protocols and standards inuse across different platforms. To allow the granularity ofaddressing the device in a hierarchy, we repeat the ele-ment ‘‘address@protocol’’ one after the other from the de-vice to the Internet gateway, which is IP addressable (asthe last part of the convention). Table 4 shows a few exam-ples for well-known protocols. An example of naming a de-vice with our address convention is presented in Section 5.

4.3. Generating the devID

As mentioned earlier, when device profile informationis registered either manually or automatically from eachIoT platform, a devID is automatically generated. We pro-pose to use a 64-bit long integer. It is used when the dataand control messages transfer between the access network,carrier public network and IoT private network, to save thecommunication overhead over any character-based nam-ing. However, one cannot randomly generate this sequenceto avoid potential collision when a cluster of NAPS are de-ployed in a cloud environment. Meanwhile, the allocationof these 64 bits should have to support other components.For instance, AG will deploy its policy-based rule enginelike MQ topic according to the device domain information,where one example is that applications may efficientlyquery all devices with mobility for their connectivity andpresence at runtime by simply masking a portion of thisdevID. Towards this end, we propose the following design,as shown in Table 5. The category field identifies the typeof sequence in the database (for devID this field equals to1), followed by the device type, controllable flag, read/write access flag, and mobility indicator. The last part is aseries of domain information, starting from the domainrule sequence r and back trace from the leaf to the root do-main nodes of that domain rule. A detailed example will bepresented in the next section.

4 We assign domain node IBM, Floor 3, and room 308 as (1) B, (11) B, and(100) B, respectively, see Fig. 8. Meanwhile, the upper-most 28bits are filledby zeros.

5. A case study

5.1. Device deployment, naming and addressing format

In this section, we demonstrate the use of NAPS in a realsmart building scenario. As shown in Fig. 7, we deploy


three temperature sensors, one humidity sensor, onealarm, and one camera, all wirelessly connected by ZigBeewith a central ZigBee coordinator. All devices are deployedin room 308 at Floor 3 of IBM Research in Beijing, China. Inparticular, three temperature sensors form a multi-hopwireless network. Then, in order to assist the device nam-ing, we first define the device domain as shown in Fig. 8.This phase is usually associated with the initial planningstage, where project managers decide the location, devicetype, and amount of sensors for deployment. In this exam-ple, we use sensors’ deployed geographical information toform the device domain tree. Without loss of generality, wedenote the domain rule index r = 1 with depth dr=1 = 3 andwidth of three levels as w1

r¼1 ¼ 1;w2r¼1 ¼ 3;w3

r¼1 ¼ 6,respectively. Collectively, we have Nr=1 = 10 domain nodesin total. Then, domain rule assignment tells the number ofbits used to encode these domain nodes, as 1 bit, 2 bits, and3 bits for three layers, respectively. Based on this, wesequentially allocate bits to each domain node, as used la-ter for devID generation of each sensor, as shown in the fig-ure. Besides, we also register the device type informationin NAPS repository, and use encoding (010101) B,(010110) B, (010111) B and (011000) B to represent tem-perature, humidity, alarm and camera, respectively.

Based on the proposed naming convention and devIDgeneration scheme in Sections 4.2 and 4.3, Table 6 summa-rizes the result. Take temperature sensor 1 for example, itsgenerated devID is 0xAA450000000F001, where ID cate-gory=(00001) B, device type ‘‘temperature’’=(010101) B,control flag ‘‘controllable’’=(0) B, r/w flag ‘‘read only’’=(01)B, mobility flag ‘‘static’’=(0) B, domain rule ‘‘IBMsite’’=(00101) B, domain series = ð0 . . . 0|fflfflffl{zfflfflffl}

28

111100Þ B,4 and

‘‘sequence’’=(1) B. Furthermore, users may create a devicegroup to monitor the ‘‘average’’ room temperature on a dailybasis, then we generate its naming as: grp://

rm308.floor3.IBM/temperature/daily-average/

group1. To do this, a user deploys a rule in the AG, and sim-ply mask 0xAA000000000F000 with the devID of the col-lected data, or ð1 010101|fflfflfflfflffl{zfflfflfflfflffl}0 . . . 0|fflfflffl{zfflfflffl}

37

1|{z}IBM

11|{z}Floor3

100|{z}room308

0 . . . 0|fflfflffl{zfflfflffl}10

ÞB.

Behind the access network (ZigBee based sensor net-work in this case), we deploy a WiMax subscriber station(SS) in the same room that connects the ZigBee coordinatorby a USB cable. At the Floor 1 of the building, we house asmall but compact data center comprised of an AG (on anIBM Workload Deployer) and a NAPS server (our Java codeis running on an IBM System x3650). AG connects to theWiMax base station (BS), which is implemented as a soft-ware-defined radio system on hardware IBM Systemx3650. By using a remote radio head (RRH), BS extendsthe communication range to cover the entire building.The communication channel between SS and AG is thestandard WiMax air interface. WiMax employs a connec-tion oriented MAC layer and each connection is identifiedwith a set of 16-bit connection identifiers (CIDs). Uponentering into networks, the SS is assigned with three CIDs



WiMax

NAPS

ZigBee

Zigbee coordinator

USBWiMax SS

fiber

Temperature sensors humidity sensor

camera

Floor-1 Data center

warning alarm

Floor-3 Room 308

RRH

WiMax BS

AG

Ethernet

Fig. 7. Device deployment in a smart building environment.

(1)B

(1)B

(10)B

(11)B

(1)B

(10)B

(11)B

(100)B

(101)B

(110)B

Fig. 8. Device domain structure for the considered smart buildingscenario.

Table 5Bit allocation for devID (in total 64 bits).

ID category Device type Control flag r/w flag Mobile flag Domain rule Domain series Sequence

5 bits 6 bits 1 bit 2 bits 1 bit 5 bits 34 bits 10 bits


in each direction, i.e.. the basic CID used for initial registra-tion derived from its 48-bit MAC address, primary manage-ment CID used for connection management andauthentication, and secondary management CID used formanagement messages such as DHCP. In addition, each ter-


minal is allocated with transport CIDs for data services.Upon service discovery and registration, SS sends the listof capabilities to AG in the REG-REQ message, and thenAG responds with a REG-RSP message along with sup-ported capabilities. Finally, SS will acknowledges REG-RSP with ACK.

As for addressing, SS and AG are provided with a publicroutable IP address through DHCP secondary managementCID, ZigBee coordinator is addressable through the VID andPID on the connected USB port, and sensors are accessiblethrough internal 16-bit short address assigned by the coor-dinator when they first join the network. Therefore, foreach sensor, its addressing convention is

short� address@zigbee=VendorID

� ProductID@USB=

< SS’s IP address > :

Assuming that 9.186.1.133 is the IP address of WiMax SS,Table 7 summarizes the result.



Table 6Device naming format and devID of six ZigBee sensors.

Device devName begin with dev://rm308.floor3.IBM devID

temp. sensor 1 . . ./temperature/DER452SA 0xAA450000000F001temp. sensor 2 . . ./temperature/LDKE4512 0xAA450000000F002temp. sensor 3 . . ./temperature/235S4FDE 0xAA450000000F003humidity sensor . . ./humidity/98SWLK12 0xAC450000000F001warning alarm . . ./alarm/273FDS43 0xAFC50000000F001camera . . ./camera/091ASEKL 0xB1C50000000F001


5.2. A device registration portal

We implement a Web-based registration portal to sup-port service registration functionality, assuming that thediscovery phase has been achieved by individual platformalready like ETSI M2M or OPC-UA. In our case, WiMax usesCIDs for service discovery. It is worth noting that the pro-vided RESTful interfaces fully support the automatic regis-tration procedure from these legacy systems, and for nowwe show a way for manual configurations. As shown inFig. 9, authorized users can log-in the system and create,view, or remove device types. Then, user creates device do-main information as in Fig. 10a, and register new devicesas in Fig. 10b. Since the device domain is already config-ured, when adding a new device, the user simply selectsa domain node where the device belongs to, either geo-graphically or logically, as shown in Fig. 11a. Finally, devicegroup is managed by adding registered devices to a group;see Fig. 11b. All these operations are achieved by callingthe provided RESTful APIs, as shown in Section 4.1.

As an example, Fig. 12 shows the XML body attachedwith the RESTful request POST: http://<serverURL>/devices to create the device profile for temperature sen-sor 1. In the representation, device name, device address,location, domain information are all encoded.

6. Performance evaluation

Since the previous section has verified the correctnessof our model and system by deploying six sensors as a casestudy, in this section, we aim to evaluate the server perfor-mance in terms of throughput when the number of devicesreaches certain amount. We testify two offered externalinterfaces, namely: (a) JDBC API for large amount of devicemeta-data retrieval (more in the configuration phase) and(b) RESTful API for information query at runtime. To runthe JDBC API pressure test, we set up the environment byinstalling the IBM DB2, client side code (in Java EclipseGalileo 3.5.0) on the same Thinkpad W500 workstation;

Table 7Device addressing format of six ZigBee sensors.

Device Addressing

temp. sensor 1 0x4FE2@zigbee/03F0–2D12@USB/9.186.1.133temp. sensor 2 0x4FE3@zigbee/03F0–2D12@USB/9.186.1.133temp. sensor 3 0x4FE4@zigbee/03F0–2D12@USB/9.186.1.133humidity sensor 0xD3E1@zigbee/03F0–2D12@USB/9.186.1.133warning alarm 0xF2A1@zigbee/03F0–2D12@USB/9.186.1.133camera 0x82AD@zigbee/03F0–2D12@USB/9.186.1.133


and therefore the computational costs are more comingfrom the I/O side instead of the network. Furthermore,we set the JVM heap size to 512 MB for Java object creationin batch. When running the tests, we call the JDBC API tofetch the device profile records in different batch sizes,where each record is approximately 20 KB. Fig. 13 showsexperimental results. For fixed batch size (e.g.. 10,000 re-cords), we observe a relatively linear increase of system re-sponse time while increasing the total number of devicerecords in the database, showing our system scales wellwith the amount of devices in an IoT environment. Forfixed total number of devices, the response time also in-creases steadily with different batch sizes. Meanwhile, ifone aims to retrieve five million device profiles (approxi-mately 100 GB in total), the average response time isaround 33 min, equivalent to the system throughputaround 404 Mbps.

We next show the performance of RESTful APIs, and Ta-ble 8 demonstrates the pressure test result when searchingdevices under conditions. We use Apache JMeter [33], andimplement the client side code (in Java Eclipse Galileo3.5.0) on a Lenovo Thinkpad W500 workstation. The sta-tion connects to the internal WLAN (interface card sup-ports IEEE 802.11b/g). Server is implemented on an IBMThinkCentre M58p machine, with 1 Gbps Ethernet connec-tion, so that the client and server are within the same LAN,and wireless network should cost most. The used URI isGET http://9.186.x.x:8080/search?devname={pol-lutant}, i.e., to search for all pollutant sensors. We ob-serve that after the system experiences some fluctuationsit quickly reaches the steady state, the average achievablethroughput is around 500–600 transactions per second(tps), i.e., 500–600 transactions can be simultaneouslyadd successfully processed with responses. The throughputslightly decreases when increasing the total number of de-vice records. Meanwhile, the system response time in-creases slightly that scales well with the total number ofrecords, and to search devices within five million records(100 GB), and average response time is around 61 ms.

7. Discussion

7.1. DDoS attacks

Apart from AAA, security issues like DDoS protectionshould also be considered. Although leaving detailed inves-tigations for the future, we review and discuss a few well-known mechanisms to prevent DDoS attacks. First is in-gress filtering [34], where packets coming into the network



Fig. 9. NAPS registration portal. (a) view a list of device types and (b) add a new device type.


are filtered if inconsistent with the source IP addresses.Second is the router throttle mechanism [35] proposed atthe routers close to the victim, to proactively regulateincoming packets to a moderate level, thus reducing theamount of flooding traffic. Similarly, the key idea of push-back is to identify and control high bandwidth aggregatesin network [36]. This upstream rate-limiting is called push-back and can be propagated recursively to routers furtherupstream. Fourth, since the source addresses of floodingpackets are faked, various traceback techniques [37] have


been proposed to find out the origin of a flooding source.Finally, based on the distinct protocol behavior of TCP con-nection establishment and teardown, the TCP SYN floodingis detected [38].

Meanwhile, commercial solutions are also availableparticularly for M2M scenarios such as the one providedby du Telecom [39] through a layered network. The scala-bility of their protect services can detect and handlethreats of flexible size, using multiple methods of detectionand mitigation.



Fig. 10. NAPS registration portal. (a) add/view a new device domain in a tree structured and (b) register a new device profile.


Please cite this article in press as: C.H. Liu et al., Efficient naming, addressing and profile services in Internet-of-Things sensory environ-ments, Ad Hoc Netw. (2013), http://dx.doi.org/10.1016/j.adhoc.2013.02.008


Domain Path

Domain Rule Tree

Domain Node

(a)

(b)Fig. 11. NAPS registration portal. (a) select the device domain information from the existing domain tree and (b) add/remove devices to/from a devicegroup.


Please cite this article in press as: C.H. Liu et al., Efficient naming, addressing and profile services in Internet-of-Things sensory environ-ments, Ad Hoc Netw. (2013), http://dx.doi.org/10.1016/j.adhoc.2013.02.008


<?xml version="1.0" encoding="UTF-8"?><tns:req xmlns:tns="http://IoTNAPS.org/"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://IoTNAPS.org/req_createDevProfile.xsd ">

<tns:number>1</tns:number><tns:profile><tns:devName>dev://rm308.level3.IBM/temperature/DER452SA</tns:devName><tns:address>0x4FE2@zigbee/03F0-2D12@USB/9.186.1.133</tns:address><tns:protocol>zigbee</tns:protocol><tns:devTypeID>21</tns:devTypeID> <!-- temperature: (010101)B<tns:samplingInterval>4</tns:samplingInterval><tns:timeSeriesFlag>true</tns:timeSeriesFlag><tns:location>rm308.floor3.IBM</tns:location><tns:sn>DER452SA</tns:sn><tns:domainRuleID>5</tns:domainRuleID> <!-- domain rule ``IBM site``: (00101)B<tns:domain>rm308.floor3.IBM</tns:domain><tns:status>1</tns:status><tns:devID_old>DER452SA</tns:devID_old>

</tns:profile></tns:req>

Fig. 12. The XML body attached with the RESTful URI to register a new device profile for temperature sensor 1.

0 1 2 3 4 50

500

1000

1500

2000

2500

3000

3500

No. of device profile records stored in NAPS (million)

Aver

age

quer

y re

spon

se ti

me

(sec

ond) 100K device profiles

50K device profiles10K device profiles

5K device profiles

Fig. 13. Average JDBC query response time versus the number of device profile records stored in NAPS, w.r.t. to different periodic batch fetching size.

Table 8Pressure test results on RESTful API to search device names containing keyword ‘‘ibm’’.

Device record No. of requests Avr. (ms) Median (ms) 90% Line (ms) Min (ms) Max (ms) Thrpt (tps)

10 k 264,644 17 11 29 2 3042 584.60500 k 287,615 38 27 46 1 7069 544.511 M 277,728 48 36 54 2 8183 535.815 M 255,494 61 52 72 1 22,551 508.26


7.2. Compatibility with IPv6

As discussed earlier in the scope of this work, we are notdevising a new transport layer protocol, but aim to inter-operate with heterogenous IoT platforms. In this sense,IPv6 based networks (like 6LowPan) is one kind of suchsolutions to be integrated with our NAPS middleware. Aspresented in this paper, NAPS performs the uniformname-to-address resolution, comparable to the functional-ity of DNS in the IP world. Furthermore, it provide abun-


dant RESTful APIs for device, device type, and devicegroup profile services. During the downstream commanddelivery, once the addressing is obtained from NAPS, it willforward it to the corresponding Internet gateway, such asthe M2M gateway in ETSI M2M service architecture,OPC-UA server, or WiMax base station (as considered inthe case study). In a hierarchy, these gateways furtherroute the command to the next level gateway (e.g.. the Zig-Bee coordinator) which maintains its own addressingmechanism to the device. In this way, we do not attempt


to ‘‘escalate’’ the IPv6 naming up to the middleware layer,and thus able to go around the issue of potential insuffi-ciency problems when the number of devices is massivebeyond the capacity of IPv6.

8. Conclusion

In this paper, we presented NAPS, a middleware to sup-port device naming, application addressing and profilestorage and look-up services in IoT sensory environments.Different from all previous efforts only focusing on a spe-cific standard/protocol, our design can work with anyexisting systems and platform to assist the upstream datacollection and identification, content-based data filteringand matching, downstream control message delivery, aswell application query. Our contributions were the pro-posal of such a complete and detailed design, includingits key functionalities, system flows, interfaces, and indi-vidual module designs, the proposal of a unique devicenaming and addressing convention with applicability towidely-used standards and protocols, the proposal of anefficient identifier generation scheme, and finally a realcase study in a smart building environment. Performanceevaluation showed that a single node commodity servercan achieve average throughput around 500–600 tps, withsystem response time 61 ms to search devices within fivemillion devices.

Acknowledgments

We would like to thank anonymous reviewers for theirvaluable suggestions and comments to improve the qualityof this work.

References

[1] L. Atzori, A. Iera, G. Morabito, The internet of things: a survey,Comput. Networks 54 (15) (2010) 2787–2805.

[2] D. Miorandi, S. Sicari, F.D. Pellegrini, I. Chlamtac, Internet of things:vision, applications and research challenges, Ad Hoc Networks 10 (7)(2012) 1497–1516.

[3] INFSO d.4 networked enterprise & RFID INFSO g.2 micro &nanosystems, in: Co-operation with the Working Group RFID of theETP EPOSS, 2008.

[4] J.-L. Chen, M.-C. Chen, C.-W. Chen, Y.-C. Chang, Architecture designand performance evaluation of RFID object tracking systems,Comput. Commun. 30 (9) (2007) 2070–2086.

[5] K. Gama, L. Touseau, D. Donsez, Combining heterogeneous servicetechnologies for building an internet of things middleware, Comput.Commun. 35 (4) (2012) 405–417.

[6] L. Roalter, M. Kranz, A. Moller, A middleware for intelligentenvironments and the internet of things, in: ACM UIC’10, 2010.

[7] EPCglobal. <www.epcglobalinc.org/>.[8] OPC Unified Architecture (UA). <www.opcfoundation.org/ua/>.[9] ETSI Machine-to-Machine Communications (M2M); Functional

Architecture, Draft ETSI TS 102 690 v0.10.4 (2011-01).[10] 3GPP TS 22.368 v11.0.0, Service Requirements for Machine-Type

Communications.[11] CoAP. <http://tools.ietf.org/html/draft-ietf-core-coap-04>.[12] Standardized Machine-to-Machine (M2M) Software Development

Platform, White Paper, InterDigital, Inc.[13] Machine-to-Machine (M2M) – the Rise of the Machines, White

Paper, Juniper Networks, Inc.[14] UPnP. <http://www.upnp.org>.[15] R.T. Fielding, Architectural Styles and the Design of Network-Based

Software Architectures, Ph.D. Thesis, 2000.[16] Internet-of-things architecture (IOT-A) project deliverable d3.1 –

initial m2m api analysis.


[17] A.P. Castellani, N. Bui, P. Casari, M. Rossi, Z. Shelby, M. Zorzi,Architecture and protocols for the internet of things: a case study,in: IEEE PerCom Workshops’10, 2010, pp. 678–683.

[18] 6LoWPAN. <http://datatracker.ietf.org/wg/6lowpan/charter/>.[19] B. Silverajan, J. Harju, Developing network software and

communications protocols towards the internet of things, in: IEEECOMSWARE ’09, 2009, pp. 9:1–9:8.

[20] D. Guinard, V. Trifa, E. Wilde, A resource oriented architecture for theweb of things, in: IEEE IoT’10, 2010.

[21] N. Kong, N. Crespi, G. Lee, J. Park, Internet-draft: the internet ofthings – concept and problem statement (18 October 2010).

[22] M.Y. Uddin, M.M. Akbar, Addressing techniques in wireless sensornetworks: A short survey, in: IEEE ICECE’06, 2006, pp. 581–584.

[23] M. Ali, Z. Uzmi, An energy-efficient node address naming scheme forwireless sensor networks, in: IEEE INCC’04, 2004, pp. 25–30.

[24] F. Ye, R. Pan, A survey of addressing algorithms for wireless sensornetworks, in: IEEE WiCom’09, 2009, pp. 1–7.

[25] Z. Du, C. Zhang, Y. Su, D. Qian, Y. Liu, Two-tier dynamic addressassignment in wireless sensor networks, in: IEEE TENCON’09, 2009,pp. 1–6.

[26] C. Schurgers, G. Kulkarni, M.B. Srivastava, Distributed assignment ofencoded mac addresses in sensor networks, in: ACM MobiHoc’01,2001, pp. 295–298.

[27] R. Fonseca, S. Ratnasamy, J. Zhao, C.T. Ee, D. Culler, S. Shenker, I.Stoica, Beacon vector routing: scalable point-to-point routing inwireless sensornets, in: USENIX NSDI’05, 2005.

[28] F.D. Kronewitter, Dynamic huffman addressing in wireless sensornetworks based on the energy map, in: IEEE MILCOM’08, 2008, pp.1–6.

[29] J. Elson, D. Estrin, Random, ephemeral transaction identifiers indynamic sensor networks, in: IEEEE ICDCS’01, 2001, pp. 459–468.

[30] J. Heidemann, F. Silva, C. Intanagonwiwat, R. Govindan, D. Estrin, D.Ganesan, Building efficient wireless sensor networks with low-levelnaming, in: ACM Symp. on Oper. Syst. Principles (SOSP’01), 2001, pp.146–159.

[31] Q. Shen, Y. Liu, Z. Zhao, S. Ci, H. Tang, Distributed hash table based idmanagement optimization for internet of things, in: IEEE IWCMC’10,2010, pp. 686–690.

[32] IBM Websphere MQ. <www.ibm.com/software/integration/wmq/>.[33] Apache JMeter. <http://jmeter.apache.org/>.[34] P. Ferguson, D. Senie, Network Ingress Filtering: Defeating Denial of

Service Attacks Which Employ IP Source Address Spoofing.[35] D. Yau, J. Lui, F. Liang, Y. Yam, Defending against distributed denial-

of-service attacks with max–min fair server-centric router throttles,IEEE/ACM Trans. Network. 13 (1) (2005) 29–42.

[36] J. Ioannidis, S.M. Bellovin, Implementing pushback: router-baseddefense against ddos attacks, in: NDSS’02, 2002

[37] Z. Gao, N. Ansari, Tracing cyber attacks from the practicalperspective, IEEE Commun. Mag. 43 (5) (2005) 123–131.

[38] H. Wang, D. Zhang, K.G. Shin, Detecting syn flooding attacks, in: IEEEINFOCOM’02, vol. 3, 2002, pp. 1530–1539.

[39] du Telecom <http://www.du.ae>.

Dr. Chi Harold Liu is a research scientist withthe Department of IoT Infrastructure Man-agement at IBM Research – China. He holds aPh.D. degree from Imperial College, UK, and aB.Eng. degree from Tsinghua University,China. Before joining IBM Research – China, heworked as a PostDoc researcher at DeutscheTelekom AG in Berlin, Germany. He has beeninvolved in EU-FP6 MEMBERANE Project, andthe US Army-UK MoD co-funded ITA Projecton sensor and mesh networks. In 2009, he wasa visiting researcher at IBM T.J. Watson

Research Center in Hawthorne, USA. His current research interestsinclude the Internet of Things (IoT), context-aware computing, and pro-tocol designs for ad hoc, sensor and mesh networks. He has published
more than 30 prestigious conference and journal papers, technicalreports, and project deliverables. He also has filed a few EU/China patents.Harold also has served as Founder and General Chair of the InternationalWorkshop on IoT Enabling Technologies (IoT-ET 2012), in conjunctionwith IEEE WCNC 2012, International Workshop on Networking andObject Memories for the Internet of Things (NOMe-IoT 2011), in con-junction with ACM UbiComp, and the TPC, Session Chair, Industry Chair ofmany conferences, including IEEE Infocom M2MCN 2011, IEEE ICEBE

http://www.epcglobalinc.org/

http://www.opcfoundation.org/ua/

http://tools.ietf.org/html/draft-ietf-core-coap-04

http://www.upnp.org

http://datatracker.ietf.org/wg/6lowpan/charter/

http://www.ibm.com/software/integration/wmq/

http://jmeter.apache.org/

http://www.du.ae



2011/2012, PESARO 2011/2012, etc. Recently, Harold has been inter-viewed by EEWeb.com as a featured engineer. He is a peer reviewer ofmajor journals and conferences, and a member of IEEE and ACM.

Bo Yang, IBM Software Group, China Devel-opment Laboratory, 3/F Ring Building, ZGCSoftware Park, Beijing, China. 100193 ([email protected]). Dr. Yang is a lead architectin the Emerging Technology Institute of IBMChina Development Laboratory. He received aB.S and Ph.D. degree in 1997 and 2001respectively in computer science from Tsing-hua University. He subsequently joined IBMResearch – China where he worked on dis-tributed system, cloud computing and nextgeneration communications. He moved to

IBM China Development Laboratory in 2012 and is now taking thearchitect role of cloud computing. Bo is an IBM Master Inventor and has


filed more than 30 patents and author or co-authored more than 20technical papers.

Dr. Tiancheng Liu is a Research Staff Memberand Manager of IoT infrastructure manage-ment at IBM Research – China. In this capac-ity, Tiancheng is leading research projectsrelated to system management technologiesin distributed environments. Tianchengreceived his Bachelor in 2000 and Ph.D. in2006 in Computer Science from Peking Uni-versity, China, and joined IBM right after. Hismain interests are distributed middleware,system management, Cloud computing andIoT technologies.



efficient naming, addressing and profile services in internet-of-things sensory environments

Documents