Naming in the Internet of Things

Yijian Li, liyjian at (A paper written under the guidance of Prof. Raj Jain) DownloadPDF


As a key component of a Internet architecture, naming scheme is at the center of the change brought by the vision of Internet of Things (IoT). Traditional naming schemes like IP and URI are experiencing some big challenges and have been modified and extended to cope with all the issues. Other naming schemes are also proposed for specific reasons. The construction of new naming schemes within future Internet architecture projects has brought new ideas and new solution despite they are pretty immature at this stage.

Keywords: naming, naming scheme, IoT, IPv6, 6LoWPAN, IPv6 over Low power Wireless Personal Area Networks, URI, uniform resource identifier, AAID, Access Address/Identifier, GS1 identification key, sensor UID, IoT@Work, CCN, Content-Centric Network, NDN, Named Data Networking, MobilityFirst, GUID, Global unique identifier.

Table of Contents

1. Introduction

The naming scheme is an important component of any kind of Internet architecture. With the arriving of Internet of Things (IoT), naming schemes became parts of the solutions to the new challenges that lie ahead. Some are based on IP structure which is the cornerstone of today’s Internet. Some are brand new schemes part of future Internet architectures aiming to solve the tricky problems such as mobility and security for good. In this paper, we will discuss some representative naming schemes including those based on traditional architecture (sections 2 and 3) and the new ones (sections 5 and 6). Between them, section 4 will focus on the way naming schemes can be constructed and the motivation for new naming schemes in the context of IoT.

2. Naming scheme based on IP

IP is the fundamental structure of today’s Internet and IPv6 is expected to be the base of IoT in the future. But the traditional system, which typically lacks mobility and security inherently, is way behind the growing needs. The extensions of IPv6 and alternative solutions built on IPv6 have been proposed as the effort to let IP move into the future Internet.

2.1 IP, the Domain Name System (DNS) and Uniform Resource Identifier (URI)

The most common naming scheme in the current Internet is with no doubt uniform resource identifier which is used to identify a name of a web resource. The IP structure and related technologies provide reliable connection after the resources are located. IP address itself is also an identifier as it reveals the location and identity of a host or network interface. The Domain Name System (DNS) enables people to use URI, which is more friendly compared to IP address, to connect to certain web resource without knowing the IP address of it.

The Internet is now connecting millions of web resources together via the three systems, i.e. IP, URI and DNS, mentioned above. As the information technology evolves at an astonishing rate, however, traditional structures have begun to struggle to keep up with the change. IoT which is the future of the Internet presents the trickiest challenges. With all the infrastructure and standards built on these systems, it will be unwise to totally discard them. A lot of efforts has been done to adjust and extend these systems, mainly IP, to keep them usable in the future Internet.

2.2 IPv6 and IPv6 over Low power Wireless Personal Area Networks

IPv6 is the final solution for the originally very limited IP address space. By providing 10^38 possible addresses [Atzori10], IPv6 will meet the needs of not only the constant growing Internet nowadays, but also IoT which will contain 50 to 100 billion connected things by 2020 [Jara12]. Despite having had a slow start, IPv6 is still being assumed to be the natural selection for future Internet. Small and low power sensors and devices which are not designed to implement IP in the first place will also be an important part of IoT. This requires IPv6 to be extended to cope with these kind of devices.

IPv6 over Low power Wireless Personal Area Networks (6LoWPAN) is a solution provided by the Internet Engineering Task Force (IETF). So far most of the personal area network of these low power devices and sensors with limited processing capabilities are using specifications like ZigBee and WirelessHART which are based on the Institute of Electrical and Electronics Engineers (IEEE) 802.15.4 standard. The way 6LoWPAN extends IPv6 to these devices is to allow IP packets to be transmitted over IEEE 802.15.4 based networks through encapsulation and header compression mechanisms [Wiki2]. With IPv6, these previously separated nodes could be integrated into bigger IP network and ultimately the whole IoT. We can use URI and/or IP address to locate and connect to these small devices around us.

If IPv6 can be extended to small objects connected via wireless network, then there comes another issue that how to put radio-frequency identification (RFID) tag which has been standardized by EPCglobal into the IPv6 framework. As one of the most widely used naming schemes, RFID tag uses 64-96 bits identifier and is the ID of millions of small objects. By now two major approaches [Atzori10] has been discussed. The first one is to use an agent to map the RFID identifier to a 64 bits field and then apply it as the interface ID of the IPv6 address. Another one is the RFID information is carried as the payload of the IPv6 packet.

2.3 Glowbal IP protocol and Access Address/Identifier (AAID)

One of 6LoWPAN’s inherent disadvantages is that it has a relatively long overhead which highly limits the size of payload with in a IEEE 802.15.4 frame. 6LoWPAN requires a 26-41 bytes overhead. Taking the 25 bytes with the extended MAC address into account, overhead will occupy up to 52% of the 127 byte-long Maximum Transfer Unit (MTU) provided by IEEE 802.15.4 standard. This will cause the system to be severely inefficient. In [Jara12], authors proposed a solution to this problem in which a new naming scheme, Access Address/Identifier (AAID), is included.

Glowbal IP protocol, an alternative to 6LoWPAN, enables IPv6 to connect to a IEEE 802.15.4 based network. AAID is a key part of this protocol because it can significantly shorten the length of overhead, which is a big trouble in 6LoWPAN framework. When a connection between a client and a node is set up, a 32 bits AAID is generated by hashing source IP, destination IP and destination port of each node. The typical overhead of IPv6 will be replaced by a much shorter AAID when the initialization process is done. The reduced 22-35 bytes overhead means there will be 40% to 60% more space in the payload. A gateway or a border router does the translation job, as showed in Figure 1 below, between the AAID within a IEEE 802.15.4 based network and the global IPv6 network while it negotiate with the node to generate the AAID.

On the other hand, the mobility and muti-homing issue which comes along almost every IP based solution is still a big challenge for Glowbal IP protocol and AAID. It will be much more complicated to generate and manage AAIDs when things are moving.

Figure 1. AAID translation between IEEE 802.15.4 and IPv6 network

Figure 1. AAID translation between IEEE 802.15.4 and IPv6 network

3. Other Naming schemes based on current Internet architecture

Besides IP related solutions, some other naming schemes have been developed to deal with IoT needs in certain areas such as manufacture industry, logistics and sensor network. Although they may not have the potential to be the cornerstone of future IoT, they will have a place in the future due to their great performance in specific tasks.

3.1 GS1 Identification Keys and the Object Name Service (ONS)

GS1 is an international non-for-profit organization dedicated to the design and implementation of global standards and solutions to improve the efficiency and visibility of supply and demand chains globally and across sectors [GS1]. Standardizing the method of naming millions of small objects is an essential part of their work. They introduced the GS1 Identification Keys as the naming scheme in the standard. The key steps of assigning a GS1 Identification Key include getting a company prefix, assigning numbers and selecting bar code and its related parameters. The keys can be used to keep track of the status and location of the objects globally.

The Object Name Service (ONS), developed also by GS1, enables the objects using GS1 Identification Keys to be located via Internet. The DNS is leveraged here to locate the specific item in the way that ONS transforms the GS1 Identification Keys into a format that DNS could understand [EPC13]. As DNS is available all over the Internet and it requires no modification to DNS servers, this naming scheme can be integrated into the traditional structure with limited extra cost.

Several IoT projects, such as SmartAgriFood and CEN TC225 [Bauer13], have taken this as their primary naming schemes. Although some disadvantages discovered in practice will limit its function in future IoT, it still has its value as an efficient system cover millions of small objects.

3.2 Sensor Web Enablement and Sensor UID

Sensors are applied in many places in everyday life, from traffic monitors to satellite imaging devices. They are indispensable in future IoT because they are the main sources for real time data. Sensor Web Enablement (SWE) standards, developed by Open Geospatial Consortium (OGC), enable developers to make all types of sensors, transducers and sensor data repositories discoverable, accessible and usable via the Web [SWE].

Among all the major SWE standards, Sensor Model Language (SensorML) is the one directly related to the naming scheme for sensors. It provides the standardized model and Extensible Markup Language (XML)-encoding which is used to describe different kinds of sensor related processes. One of the description collected is the metadata of sensors or sensor system. The metadata can be mined and used to retrieve the important parameters one of which is the identifier, i.e the name of the sensor. In [Hu11], the authors created a SensorML-based template and adopted the Sensor UID and Platform UID defined by International Standard Organization (ISO) 19130 as the identifiers in the metadata. In this way, the sensors, especially remote sensors, have the ability to let others discover them within a standard framework [Wiki1].

SensorML is an early work for descriptions of IoT related data and the usage of XML caused severe limitations on semantic interoperability which is a big issue because the connection and communication between devices in different scenarios will be everywhere.

3.3 IoT@Work naming scheme based on semantic ontology

The Semantic Web is a proper solution for the interoperability issue. In fact the URI mentioned in section 2 is an example of semantic ontology. It is a base standard for the Resource Description Framework (RDF) which is a family of World Wide Web Consortium (W3C) specifications. Apart from URI, other semantic ontologies support different kinds of naming schemes. In this section we’ll talk about one case of them.

IoT@Work is a European Research Cluster on the Internet of Things (IERC) project mainly focused on factory automation systems auto-configuration and improved security [Bauer13]. In the project, to address the events happening in a factory production context, they devised a mechanism called Event Notification Service (ENS) which adopts a publish/subscribe model instead of the request/response one in traditional system. Also Namespace, a hierarchy structure dedicated to solve the naming issues, is built in order to let ENS function properly.

In a Namespace, a set of published events related to a certain need or service are organized together in the form of a tree which is shown in figure 2 below. The leaf nodes in it are normally refer to a physical entity like a certain robot of a production line while the intermediate nodes are virtual entity implemented to simplify the way subscribers get the information they want. Each node has four major attributes which are Name, Description, EntityURI and a URI. Among the four, Name is the identifier of the node and the other three is used to accelerate and improve the handling of the event. Because the nodes of different Namespaces are typically uncorrelated, under totally different hierarchy there could exist leaf nodes named in the same way.

Figure 2. An example of IoT@Work ENS Namespace

Figure 2. An example of IoT@Work ENS Namespace

The hierarchy naming structure is particular good for communication between client and object. However, to the Machine to Machine (M2M) communication mode which will be critical in the future IoT, this way is inefficient. Mobility will be a big trouble for this scheme, too.

4. Evolving Internet into the future via new naming schemes

The new requirements proposed by IoT are affecting the naming scheme which is a part of the basic structure. A rapid change of the naming scheme is happening. New schemes are being developed via several major methods and will play a key role in future Internet architecture.

4.1 The trend brought by IoT and new requirement for naming scheme

IoT is a complicated vision of the future Internet. It is hard to summarize the trend it will bring, for there are too many areas need to be taken into to account. Nonetheless several major issues are universally considered important. They are connectivity, scalability, mobility, management and security. Additionally the mammoth number of objects involved in IoT makes the challenges much more difficult. Even with the progress achieved in cloud computing, big data and many other frontiers, the traditional Internet structure still requires major modification or ,to the authors of [1Li12], a clean-slate redesign of the current infrastructure.

Naming issue naturally is an essential part of the structure and the daily operation of the Internet. Currently IP and URI are doing the excellent job in naming and locating the resources available online. Some other schemes like those mentioned in section 3 are designed for specific tasks which is beyond the reach of IP and URI. But what the IoT really needs is one naming scheme that can be the base of the whole IoT and can integrate all kinds of sub naming schemes into one framework. IPv6 with appropriate extensions is a promising candidate as long as it can fix some inherent problems like mobility and security in IoT services.

In the vision, IoT will provide various services to accommodate service need on different level such as personal, enterprise or scientific research. In [Gigli11], IoT services are categorized into four types: identity related services, information aggregation services, collaborative aware services and ubiquitous services. Each service has its own demand when it comes to naming issues. For instance, information aggregation services may not require that each object has a unique name which is mandatory in identity related services. This means that the chosen naming scheme of the future IoT should be flexible enough to provide any certain kind of service.

4.2 The variety of naming schemes

Identification is one of several functions performed by a name. In IoT this function is the most important one because finding one object is pretty hard when there are billions of things available. In our daily life, license plate and social security number is examples of identifiers. Identifier can be globally unique, like fingerprint, or unique only within a certain scope, like zip code.

Identifiers are usually the target of naming schemes related to IoT. In [Bauer13], authors listed four primary methods used to construct an identifier. They are random data, hierarchy identifier, encoding additional information (e.g. manufacturer, locator), by cryptographic operations (e.g. hash of public key). One scheme can apply several methods in the same time. In table 1, the methods used by each scheme mentioned in this paper including the two new schemes will be discussed later are listed. As a matter of fact, these methods are sufficient for constructing any new naming schemes.

When devising a new name scheme, generally there are two approaches, reusing a scheme already there or define a new one. The latter approach requires a mapping mechanism to integrate itself into an existing scheme in order to provide service in a much broader scope. That’s exactly what AAID has done and RFID based schemes such as GS1 identification keys haven’t done.

Table 1: Methods of constructing naming scheme adopted by various scheme
Project or Architecture Naming Scheme Method applied
IPv6 URI hierarchy identifier
encoding additional information
IPv6 IPv6 hierarchy identifier
Glowbal IP Protocol AAID encoding additional information
GS1 GS1 identification keys random data
encoding additional information
SWE Sensor UID encoding additional information
IoT@Work Name of a node
within a namespace
hierarchy identifier
encoding additional information
NDN Name of the data hierarchy identifier
encoding additional information
cryptographic operations
MobilityFirst GUID encoding additional information
cryptographic operations

4.3 Future Internet Architectures and their naming schemes

Future Internet Architecture (FIA) is a project funded by National Science Foundation (NSF) aiming to build up a secure and highly dependable information technology infrastructure for the future Internet. Among the five projects in FIA, Named Data Networking (NDN) and MobilityFirst are the two trying to construct a new naming scheme which can be applied to IoT. Compared to the extensions and solutions based on traditional structure, NDN and MobilityFirst are taking a much more radical way as they are redesigning the fundamental structure of the Internet. Hopefully these changes will solve the major problems, mainly about mobility and security, in today’s Internet services for good. The details of these changes will be discussed in the following two sections.

The naming schemes are at the center of these changes for naming issue is closely related to how we view the object or the data in IoT. This is exactly what the changes are about. Traditional structure like TCP/IP’s host-centric and point to point communication model [Zhu13] is a big obstacle to completely solving the mobility issue. The construction of the new naming schemes doesn’t jump out of the box as Table 1 shows while the new naming schemes are paying more and more attention to security issues by involving cryptographic operations in the early stage of naming.

5. Named Data Networking (NDN)

Being a future Internet architecture project, NDN aims to topple the TCP/IP communication paradigm and replace it with a content/data-centric network structure. A new naming scheme which are similar to URI is at the center of this trial. The name of the data will perform several key functions such as routing, securing and content delivery. High expectation is paralleled by big challenges.

5.1 The idea of Content-Centric Network (CCN) and NDN

Named Data Networking (NDN) follows the idea of Content-Centric Network first proposed by Van Jacobson [Baid12]. Content distribution which is a significant function of today’s Internet is performed inefficient in the TCP/IP host-centric, point to point paradigm. During the process of getting a content of interest over the Internet, we need to know the location, i.e. IP address, before we can set up the connection. This leads to the translation service provided by DNS. To the users who are interested only in the content, these steps seems irrelevant.

In a content-centric network architecture as CCN and NDN are developing, in order to retrieve the content they want, all they need to do is to send interest with name. The web server listening to an incoming interest with certain name prefix will create and send back the data packet directly based on the name of the content [Burke12]. In other words, the name of the content or the data will replace IP in the future Internet and act as the universal component in Internet protocol stack [Zhang11]. The Hourglass architecture which is the principle of the design is showed in figure 3.

Figure 3. Hourglass architecture of TCP/IP based and NDN based Internet

Figure 3. Hourglass architecture of TCP/IP based and NDN based Internet

5.2 Naming scheme of NDN

The form of the name is similar to URI. [Jacobson13] illustrated an example:


This name could represent segment 3 of version 1 of the video demo.mpg which is stored in the server at UCLA.

It is a hierarchically structured name as the architecture has designed. Flat names are also allowed in the NDN when the data is local. But the routing function of name of the date and the scale of the future NDN routing system make flat name useless in most cases. The routing system knows the boundary in a name, i.e. “/”, while it doesn’t interpret meaning of the name. Consequently choice of the name is up to the corresponding application. One scenario will be considered very normal in IoT. That is data is generated in real time and the client doesn’t have the specific knowledge of how the data is named. Right now these kind of knowledge are manually propagated via major websites, social network or email. In NDN, this needs to be done in an automated way. There are two way to achieve goal: designing an deterministic algorithm that enables both sides have the same result or letting the client put more parameters of the data which are called interest selectors in NDN in the interest sent to the server. The first way will be an important component of the naming scheme because the algorithm will decide how the name is constructed.

The world-wide service provided by NDN demands that the name should be unique globally while uniqueness eliminates certain names that can be very useful within a specific scope. A new name space management strategy is wanted.

5.3 The role of the naming scheme in NDN

What IP is doing in today’s Internet is what name is expected to do in NDN architecture. The fact locating and routing depends on the naming of the data means the choice of the name would affect many aspects of the operation of the Internet. Scalable routing, network delivery and application development will be improved if a proper naming mechanism is introduced. Especially the scalable routing issue will be a big challenge for NDN in future IoT. Since NDN directly routes data packets on the name and IoT will have billions of objects needs to be named, the routing table will grow to a size no commercial router can support if the naming scheme fails to constrain the complexity of the name structure.

Security, another top issue, is associated with the naming scheme. On a data-centric network, the best way to secure the content is to tie a key to the name of the data and the key is signed into the data when the data is going to be transmitted [Zhang11]. Compared to securing the communication channel in the TCP/IP paradigm, the new way directly encrypts the data. This will significantly improve the quality of service in the whole network because the less components are involved, the less chance integrity of the data is compromised.

NDN has been proved to be much more efficient in content distribution [Yuan13] and be feasible in the context of IoT [Burke12]. Nonetheless, if NDN wants to be the basic architecture of the future Internet, more solutions including a comprehensive naming scheme are needed.

6. MobilityFirst

Another strong candidate of future Internet architecture is MobilityFirst. The key idea of it is separating the name from network address to achieve much greater mobility performance. Global unique identification (GUID) and other related mechanisms are introduced to provide basic MobilityFirst services. The comparison between NDN and MobilityFirst offers an interesting perspective.

6.1 The architecture of MobilityFirst

MobilityFirst is another future Internet architecture project funded by NSF. From its name we literally know that it is mainly focused on mobility issue. Mobility has always been referred to the biggest problem of IP structure even before the idea of IoT. Any other IP based solution can not totally get rid of it. The most prominent innovation in MobilityFirst is the separation of naming and addressing [2Li12]. The naming scheme adopted is a global unique identification (GUID). What makes it different from URI is that it is detached with its location, i.e. IP address for URI.

This idea is not new. Locator/Identifier Separation Protocol (LISP) developed by Internet Engineering Task Force (IETF) applied this paradigm to deal with the mobility issue in the existing IP network. But what MobilityFirst proposed is supporting it at network layer which demands a complete redesign of the network architecture.

In the architecture of MobilityFirst, despite the GUID and network address is separated from each other, the network still maintains the mapping between the two. MobilityFirst implements two routing scheme, GUID and network address based, in the same time which make the network much more flexible. Consequently four basic network services should be available in MobilityFirst: 1.Global Name Resolution Service, 2.Hybrid GUID/network address routing, 3.Delay-tolerant network (DTN) transport and 4.Name Assignment Service (NAS) [1Li12]. Among them, the last service are directly linked to the generation and management of GUID. The details of GUID and NAS will be discussed in the next subsection.

6.2 Global unique identifier (GUID) and Name Assignment Service (NAS)

The owner’s public key and a sequence number coming from the hashing of certain attribute, such as MAC address or URI of the content is the two parts of a GUID. The structure is showed in figure 4 below. The fact that the structure is simple while inherent secure is highly desirable in IoT context.

Figure 4. The structure of GUID

Figure 4. The structure of GUID

The uniqueness of GUID is achieved by the unique public key assigned by the NAS which will map the a description of the content, typically in the form of a string, to a unique GUID. By choosing a NAS for his/her network object, the owner can publish new resources on the Internet. People who want to retrieve this object will only have to simply look up the corresponding GUID in NAS and then the object is accessible. Since the public key and hashing of the private information is combined together when the GUID is created, the security is done by the naming scheme just like NDN.

Muti-homing is another feature of GUID in MobilityFirst because the same content could be in several different places on the Internet simultaneously. For example, an electronic book could be available in multiple libraries. In this scenario, a GUID will be tied to all the network addresses it is in. The point to multipoint mapping is done by Global Name Resolution Service which is also a basic service provided by MobilityFirst.

6.3 The role of GUID in MobilityFirst

Instead of implementing routing mechanism only depends on name which is the case in NDN, MobilityFirst retains the network address routing along with the GUID based routing. Indeed this will increase the complexity of the routing mechanism. But the usage of traditional routing technique will bring advantages which will neutralize or even exceed the negative effects since IP routing has been proved pretty effective.

The hybrid routing method will not degrade the role of GUID in the whole picture. The safeguard built in the GUID is one of the most crucial improvement of MobilityFirst. And more importantly, supporting mobility is the key concept of the entire structure. The separation and the mapping between GUID and its one or multiple network addresses give the named object an outstanding mobility with limited overhead. When the object moves to a new location, all it needs to do is to update its GUID to network address mapping in Global Name Resolution Service and then the traffic will seamlessly goes to the new location. This results in a much more better performance in mobility context [Baid12]. MobilityFirst looks promising in future IoT as mobility will be critical to almost every IoT services. But same as NDN, MobilityFirst needs more comprehensive solutions to cope with all kinds of challenges proposed by IoT.

6.4 The comparison between naming schemes of NDN and MobilityFirst

Being the counterparts in the future Internet architecture project, NDN and MobilityFirst have some features in common while having more fundamental differences. The naming schemes are both key component in each architecture. The comparison between the two will give us a clear big picture of development of the naming scheme in the future Internet architecture. Table 2 lists the common points, advantages and disadvantages of the two naming schemes. All the content in the table has been discussed in previous sections.

Table 2: The comparison between naming schemes of NDN and MobilityFirst
Name of the data/NDN GUID/MobilityFirst
common points 1.Built in security mechanism
2.Detached from network address
3.Automated content distribution
4. Need a total redesign of Internet infrastructure
advantages 1.Simpler routing mechanism only
depends on name
2. Much more Efficient content distribution
1.Exploiting the effective traditional network
address routing technique
2. Much less mobility overhead
disadvantages Scalability of the routing table More complex routing rules


In this paper, we discussed the solutions based on the existing architecture. But those solutions, like 6LoWPAN and AAID, still face some inherent issues. More extensions and modifications are needed to bring some fundamental changes to the IP architecture. Some other solutions such as GS1 identification key perform very well in certain areas and can be very efficient doing specific tasks. They may not be able to be implemented in the scope of the entire Internet, but they should be considered to be integrated into future IoT basic structure.

Since some challenges brought by IoT are very hard to deal with within tradition paradigm, new naming schemes along with future Internet architecture is proposed. The methods used to construct them is already there. By introducing some radical idea, projects like NDN and MobilityFirst are able to offer some innovative solutions which will topple the existing Internet structure while get rid of some IoT issues for good. However these solutions still have a long way to go. They need much more comprehensive mechanism and techniques in order to compete with IP architecture in future IoT. In one word, the door is open and everyone has a chance.

8. References

*The references are listed by the importance.

  1. [Bauer13] Martin Bauer and,"Catalogue of IoT Naming, Addressing and Discovery Schemes in IERC Projects V1.7", IERC-AC2-D1, 2013,
  2. [Jara12] A.J.Jara,M.A.Zamora and A.F.Skarmeta,"GLoWBAL IPv6: An adaptive and transparent IPv6 integration in the Internet of Things",Mobile Information,IOS Press,2012,pages 177-197,
  3. [Atzori10] Luigi Atzori,Antonio Iera,Giacomo Morabito,"The Internet of Things: A survey",Computer Networks,Volume 54,Issue 15,2010,Pages 2787–2805,
  4. [Burke12] Jeff Burke,"Named Data Networking:Cyberphysical Applications Research",PPT,UCI,2012,
  5. [Zhang11] Lixia Zhang,"Evolving Internet into the Future via Named Data Networking",PPT UCLA,2011,
  6. [1Li12] Jun Li,Yan Shvartzshnaider,John-Austen Francisco,Richard P. Martin and Dipankar Raychaudhuri,"Enabling Internet-of-Things Services in the MobilityFirst Future Internet Architecture",World of Wireless,Mobile and Multimedia Networks (WoWMoM),2012,
  7. [Zhu13] Zhenkai Zhu,Alexander Afanasyev and Lixia Zhang,"A New Perspective on Mobility Support",Technical Report NDN-0013,2013,
  8. [Baid12] Akash Baid,Tam Vu and Dipankar Raychaudhuri,"Comparing Alternative Approaches for Networking of Named Objects in the Future Internet",INFOCOM,2012,
  9. [Gigli11] Matthew Gigli,Simon Koo,"Internet of Things: Services and Applications Categorization",Advances in Internet of Things,2011.1, Pages 27-31,
  10. [2Li12] Jun Li,Yanyong Zhang,Kiran Nagaraja and Dipankar Raychaudhuri,"Supporting Efficient Machine-to-Machine Communications in the Future Mobile Internet",Wireless Communications and Networking Conference Workshops (WCNCW),2012,
  11. [Yuan13] Haowei Yuan and Patrick Crowley,"Experimental Evaluation of Content Distribution with NDN and HTTP",INFOCOM,2013,Pages 240-244,
  12. [Jacobson13] Van Jacobson and,"Named Data Networking (NDN) Project 2012 - 2013 Annual Report",NDN Project,2013,
  13. [EPC13] EPCglobal.Inc.,"GS1 Object Name Service (ONS) Version 2.0.1",2013.1,
  14. [OGC12] OGC White Paper,"OGC Sensor Web Enablement: Overview And High Level Architecture",OGC,2012,
  15. [Hu11] Chuli Hu, Nengcheng Chen, and Chao Wang, "Remote sensing satellite sensor information retrieval and visualization based on SensorML." Geoscience and Remote Sensing Symposium (IGARSS), 2011 IEEE International. IEEE, 2011,
  16. [SWE] "SWE",
  17. [GS1] "GS1",
  18. [Wiki1] "SensorML",
  19. [Wiki2] "6LoWPAN",

9. List of Acronyms

Acronym Definition
6LoWPAN IPv6 over Low power Wireless Personal Area Networks
AAID Access Address/Identifier
CCN Content-Centric Network
DNS Domain Name System
ENS Event Notification Service
FIA Future Internet Architecture
GUID Global unique identification
IEEE Institute of Electrical and Electronics Engineers
IoT Internet of Things
NAS Name Assignment Service
NDN Named Data Networking
NSF National Science Foundation
ONS Object Name Service
RFID radio-frequency identification
SensorML Sensor Model Language
SWE Sensor Web Enablement
XML Extensible Markup Language

Last Modified: December 10, 2013
This and other papers on latest advances in computer networking are available on line at
Back to Raj Jain's Home Page