Universal Integration of the Internet of Things through an IPv6 ... - D2.4.pdfImplementation and testing report on IPv6-based IoT6 features for the Service Layer Contract Due Date

Universal Integration of the Internet of Things through an IPv6-based Service Oriented Architecture enabling heterogeneous components interoperability

Grant agreement for: Collaborative project

Grant agreement no.: 288445

Start date of project: 1 October 2011 (36 months duration)

Deliverable D2.4 Implementation and testing report on IPv6-based IoT6 features for the Service Layer

Contract Due Date 30/11/2013

Submission Date 31/01/2014

Version v1.0

Responsible Partner University College London (UCL)

Author List Socrates Varakliotis, Peter Kirstein, Rafael Marin-Perez, David Fernandez, Pablo Lopez, Antonio Skarmeta

Dissemination level PU

Keywords Internet of Things, 6LoWPAN, GLoWBAL, IPv6, API, Digital Object Architectures, Handle System, persistent identifiers, QoS, security, ubiquitous access, scalable and efficient routing, IoT gateways, service networks

Project Coordinator: Mandat International (MI)

Sébastien Ziegler [email protected]

mailto:[email protected]

D2.4 Implementation and testing of IPv6-based features

v1.0 IoT6 D2.4 Page 2

Table of Contents 1 Executive Summary ......................................................................................................... 5

2 Introduction ...................................................................................................................... 7 2.1 The Scope of T2.4 ...................................................................................................... 7 2.2 Structure of the Document ......................................................................................... 8

3 6LoWPAN ....................................................................................................................... 10 3.1 Addressing ................................................................................................................ 10 3.2 Input/Output Packet .................................................................................................. 10 3.3 Fragmentation ........................................................................................................... 10 3.4 Header Compression ................................................................................................ 11

3.4.1 Compression-related functions ............................................................................. 11 3.5 UDP transport layer .................................................................................................. 12 3.6 API interface for IEEE 802.15.4 technology ........................................................... 12 3.7 Testing of 6LoWPAN. ............................................................................................. 15

4 GLoWBAL-IPv6 ............................................................................................................. 16 4.1 API interface for IEEE 802.15.4 technology ........................................................... 18 4.2 Implementation of GLoWBAL-IPv6 applications. .................................................. 20 4.3 Evaluation of GLoWBAL-IPv6 ............................................................................... 21

5 IPv6 Addressing Proxy .................................................................................................. 23 5.1 API interfaces for X10, CAN and KNX technologies ............................................. 25

5.1.1 API functions for X10 technology ....................................................................... 25 5.1.2 API functions for CAN technology ...................................................................... 26 5.1.3 API functions for KNX technology ..................................................................... 27

5.2 Evaluation of IPv6 Addressing Proxy ...................................................................... 28 5.2.1 Scalability evaluation ........................................................................................... 28

6 Overview of Provision of IoT Services using the Handle System .............................. 30 6.1 Introduction .............................................................................................................. 30 6.2 The Current IoT6 Repositories and Gateways ......................................................... 31 6.3 The Digital Object Identifiers and the Handle System............................................. 31

7 Some Features of the Handle System ........................................................................... 34 7.1 Handles as Persistent Identifiers .............................................................................. 34 7.2 Handle Syntax .......................................................................................................... 34

7.2.1 Handle syntax for IoT applications ...................................................................... 35 7.3 Handle Resolution and relevance to IoT applications .............................................. 36 7.4 Administering Handles – Security Provisions and Implications .............................. 37

7.4.1 Handle security provisions and the IoT ................................................................ 39 7.5 Handle System Scalability ....................................................................................... 39

7.5.1 Storage scalability ................................................................................................ 40 7.5.2 Performance scalability ........................................................................................ 41

7.6 Security aspects ........................................................................................................ 42 7.6.1 Authentication ...................................................................................................... 42 7.6.2 Server Certification .............................................................................................. 43 7.6.3 Security Services in Handle ................................................................................. 43

7.7 Handle Value Types ................................................................................................. 43 7.8 Template Handles ..................................................................................................... 46

7.8.1 The Template Delimiter ....................................................................................... 46

8 Digital Objects for the IoT ............................................................................................. 48



8.1 Use of the Handle System in the IoT ....................................................................... 48 8.2 Gateways and Functional Separation ....................................................................... 49 8.3 DO Registration ........................................................................................................ 50

8.3.1 Auto-configuration of IoT services and resources using Handle ......................... 51

9 The Operations in Automated Building Management ................................................ 52 9.1 Introduction .............................................................................................................. 52 9.2 SAaaS Operations .................................................................................................... 52 9.3 DO Registration ........................................................................................................ 53 9.4 Compound Operations .............................................................................................. 53 9.5 Re-Use of past IoT6 work ........................................................................................ 54

9.5.1 The GLoWBAL-IPv6 protocol and object identifiers .......................................... 54 9.5.2 The Digcovery system and operations with object identifiers ............................. 56 9.5.3 Comparison of Handle System to the DNS system for IoT purposes .................. 56

9.6 Advantages of using Handle in a IoT integration approach ..................................... 58 9.6.1 Global secure service ........................................................................................... 58 9.6.2 Novel business process description ...................................................................... 58

10 Programmability ............................................................................................................ 60 10.1 Clients and the client library .................................................................................... 60 10.2 Batch Processing ...................................................................................................... 60 10.3 HTTP Proxy (REST API) ........................................................................................ 60 10.4 IPv6, REST and Secure access ................................................................................. 61 10.5 Links with the Digcovery System ............................................................................ 62 10.6 Interfacing legacy ABM Systems............................................................................. 62

11 Conclusions ..................................................................................................................... 63

12 References ....................................................................................................................... 64



Table of Figures Figure 1: JN5139 mote from the Jennic company ................................................................... 15

Figure 2: Sequence diagram of AAID sending module ........................................................... 17

Figure 3: Sequence diagram of AAID receiving module ......................................................... 17

Figure 4: AAID Gateway defined in the multi-protocol card (left) and also based on the IEEE 802.15.4 USB Ethbridge (right). .............................................................................................. 21

Figure 5: Performance evaluation for the AAID mapping in AAID Gateway and AAID node. .................................................................................................................................................. 22

Figure 6: Summary of the mapping performance for 500 sessions. ......................................... 22

Figure 7: Multi-protocol card used for the evaluation of IPv6 addressing proxy .................... 23

Figure 8: Evaluation framework of IPv6 addressing proxy ..................................................... 23

Figure 9: Average of times in the IPv6 mapping processing with application or routing modes .................................................................................................................................................. 29

Figure 10: The Handle resolution process ................................................................................ 36

Figure 11: Secure end-to-end Handle administration from DeviceNets to the Internet. .......... 39

Figure 12: Logical separation of Handle Service to Servers and Sites .................................... 40

Figure 13: Functional separation of gateways to processes ..................................................... 49

Figure 14: Direct linkage of DOA systems with the IoT ......................................................... 61

List of Tables Table 1: Pre-defined Administrative Types ............................................................................. 44

Table 2: Non-administrative Types .......................................................................................... 45

Table 3: Prefix Handle Values ................................................................................................. 45



1 Executive Summary This Deliverable is presented in two parts: The first part evaluates many features of the IPv6 stack, which were implemented in the earlier tasks. In the earlier Deliverables, the developments themselves were described, but their evaluation was minimal. In particular, three developments were examined in the context of their use by the other Work-Packages. The three aspects were: the 6LoWPAN implementation, the GLoWBAL system and the addressing proxy.

6LoWPAN is the network protocol for sending IPv6 packets over IEEE 802.15.4 wireless systems. The implementation used was one that comes with the Contiki release, and we describe the addressing, fragmentation, header compression and API. A particular choice of compression algorithm is recommended resulting in the whole implementation being revised.

The GLoWBAL implementation describes how individual session information is maintained between a source node outside the gateway and a 6LoWPAN device. Since resources in the gateway are limited, the tables formed include a time-to-live of each entry. An evaluation of the scalability of the system is given. On a specific platform, the process took about 7ms for each of the three technologies investigated – X10, BACnet and KNX.

The IPv6 addressing proxy defines the mechanisms for mapping automatically an IPv6 address as used in IoT6 and the three different legacy technologies used. Here one also evaluated the difference between using a different daemon for each technology, and sharing one for all the technologies. In the evaluation, it was shown that with a common daemon, the time taken to do the mapping in a specific Linux gateway varied between 25 milliseconds and 30 milliseconds for the different technologies. By using separate daemons, this could be cut by 50% - 60%.

The second part of this Deliverable is additional to what was promised in the DoW. Since the basic activities contracted had been accomplished (except perhaps a full implementation of secure operation), we decided to step back and consider whether a complete complementary approach might have advantages. In most of the previous IoT6 work, the individual sensors and actuators have been associated with an IPv6 address. It was realised that a key requirement was to associate the device with its resources in a repository, and that a globally distributed name resolution system was needed. Much of the infrastructure for this was provided by the Digcovery system, with the accompanying use of specific repositories and heavy reliance on the DNS – since it was designed to store addresses in a globally distributed and scalable form. Many have considered that one should differentiate between the name and the location of a node. While this differentiation is difficult with the limited address space of IPv4, it becomes more achievable with IPv6. We postulated further that all entities, whether IP addressable or otherwise, should be associated with a name – which for brevity we might call a Handle. By means of a suitable hierarchic structure of the name, one could route to it in the Name Space just as the DNS can be used to devise routes in the address space. This idea was not original; it was initially applied to digital documents by Bob Kahn at CNRI, who has developed a whole Digital Object Architecture (DOA) to deal with such digital objects (DOs). Based on these concepts, CNRI has developed a whole system with several basic components: a Naming Syntax, a Name Resolver, a Registry and links to various repositories. Moreover, a globally distributed implementation of the concept has been deployed with freely available server and client modules. It operates as a global service, and some of its concepts have just been adopted by the ITU in a recent recommendation. Considerable emphasis has been placed on scalability and performance – by replication, caching and clustering. Unlike the DNS, it has employed a strong security infrastructure at all stages of its design and implementation.



Moreover, partially as a result of our on-going discussions with CNRI, the current release has become IPv6-compliant, and the next one will include REST interfaces.

The system has been applied mainly to the media and document industry; a study of the system indicates that it is a superb match for the real needs of IoT and, in this respect, we have had strong cooperation from CNRI. Because the concepts are so different from what has been done before in IoT6 WP2, it was necessary to provide an in-depth description of the salient features of the Handle System. We have then shown how its features provide such a good match for the needs of IoT generically. IoT6 has concentrated on Automated Building Management (ABM), so the operations needed in IoT6 and the DOs that can represent ABM devices that can be implemented using the Handle syntax are shown. We then show how functions like the IoT6 addressing proxy and the legacy-dependent sensing and actuation processes can be re-located outside the current gateways – but with in-built security. As a result, these processes should also be locatable in computing clouds; it would then become an optimisation issue of which process must run on local clouds and which can be remote. The detailed validation of this activity will be done in the third year under WP7.

The extension of this work to Digital Objects in no way detracts from the essentially IPv6 nature of this project. We do conclude that dealing with identifiers, groups of objects and security are better dealt with in the hierarchic Identifier Name Space than the IPv6 Address Space. Nevertheless, the DOs will always contain IPv6 addresses in their attributes, all communications routing takes full advantage of the benefits that IPv6 gives. This matter is fully explained in the text.



2 Introduction 2.1 The Scope of T2.4 The DoW is a contractual document, and hence the work described in the DoW is the least that must be covered. At the same time, there are no further Deliverables in this Work-Package. For this reason, if there are important additional areas of work that come into the general ambit of WP2 and WP3, this is the logical place to report them. This is particularly important if there is work done during the first two years that will be validated in WP7 in the third year.

The DoW for Task 2.4 is quite explicit:

T2.4: Test and implementation of IPv6 connectivity M13-M26 (Task leader: UCL) This task will work in close cooperation with the WP3 on Open Service Layer. It will integrate and evaluate the mechanisms identified and developed in the previous tasks, which are relevant for the Internet of Things and which could be used by the service layer like: discovery, self-configuration, very large address space, mobility, ubiquitous access, QoS, multicast functionalities, security and authentication. It should provide a coherent and complete stack for the connectivity layer and test it.

This description gives the authors problems for several reasons. It was conceived over two years before this task was due to start, and therefore could not envisage the developments which would take place in the first year of the project. Second, much of the integration work was already done in Task T2.3. Finally, while there was an initial interpretation of the DoW, both the needs of the subject and the progress of the project have modified the scope of this Task.

Already in the earlier tasks WP2 has worked in close cooperation with the WP3 Open Service Layer. WP2 integrated and evaluated the mechanisms identified and developed in the previous tasks, which are relevant for the Internet of Things and which could be used by the service layer like: discovery, self-configuration, very large address space, mobility, ubiquitous access and multicast functionalities. In Task T2.4 these functions should have been integrated and tested in a stack suitable for WP3. We have gone way beyond that. All except mobility and multicast have been integrated with the services of WP3 and distributed to the partners. They have integrated them with the work of WPs 4-6, and the results were demonstrated already at the second project review.

Mobility, multicast and QoS are a little different. In the second review, mobility in the sense of working in a mobile way with mobile telephones was demonstrated. This requires, of course, no features of the IPv6 stack directly. In the DoW, was meant IPv6 Mobile IP (MIP6). In the IPv6 stack, this does not require additional features - except that the mobile node must update its binding with the Care-of Server, which requires IPSec in the standard. It also requires a Server with the Care-of Address feature incorporated. As stated in D2.3, these features are supported in some of the Linux and Contiki stacks used in the project.

Multicast does not require anything special in the stack. It is a feature used in many of the basic IPv6 services, and must therefore be supported in the basic stacks. Its features are thus already integrated and tested – though its use in applications has not been explored.

QoS is in a different category. In the Year 1 project review, QoS was interpreted as use of the Flow Label, and the work of demonstrating this feature was transferred to Task T3.2 – and was demonstrated in the second project review.



Security is in yet another category. Task T2.2 analysed many of the features required for secure operations, and demonstrated that the low-level algorithms often used could be implemented with TinyOS, the operating system UL was using (not the Contiki used by the other partners in small devices). However, there was no attempt in Tasks T2.2 or T2.3 to implement secure operations in the total system – though there can be a requirement for authentication in the service stack set up for the partners – which we call the IoT6 stack.

What was not attempted, and is vital not only for WP2 but for the whole project, is an evaluation of what functions can be enabled by IPv6 that might bring extra value to IoT. Nor has there been earlier in the project a consideration of how the important authentication and authorisation functionality should be provided. It should be emphasised, that these activities are not part of the “IPv6 stack”. The provision of authorisation and security are not particularly impacted by IPv6 – though some functions are facilitated by it. Another requirement highlighted in the Reviewers’ comments at the latest project review was the importance of scalability. One part of this is addressed automatically by the sheer address size of IPv6; however, another is the need for scalability in the salient components.

It is the specification of how such security services could be provided in a manner compatible with the rest of the project that is one of the main outcomes of Task T2.4. A discussion of where IPv6 features could facilitate IoT is a secondary outcome. Neither of these impacts the implementation of most of the activities of the other Work-Packages; they require just the stack that they have received from Task T2.3. The provision of services that can be shown to scale is a very important aspect; we show how the solution proposed here achieves also this aim. The activities that we describe here are fitting final activities for WP2. Their validation in the context of specific Use Cases is a subject of the WP7 validation activity.

2.2 Structure of the Document While many aspects of the IPv6 stack were implemented in the earlier Tasks, and in particular Task T2.3, the evaluation of these developments was minimal. In Sections 3-5, we undertake such an evaluation of many of the features that were presented in Task T2.3. This is in strict accordance with the DoW description of Task T2.4. In Section 3 there is an evaluation of the 6LoWPAN implementation, and in Section 4 of the GLoWBAL system. Another aspect was the addressing proxy, and here the evaluation is carried out in Section 5.

The remainder of this Deliverable is additional, and is more in the nature of a specification of a Systems Architecture. We postulate in Section 6, that IoT would be particularly well served by considering each end device as a Digital Object (DO). There is already a system called Handle that has defined a Digital Object Architecture (DOA) that has been developed for manipulating DOs securely. In Section 7 we outline the principal characteristics of Handle – including its reliance on a hierarchic structure and its use of a Name Resolver Service (NRS), which is intrinsically involved with Digital Objects and their secure manipulation. There are many other features associated with the Handle System (HS). These include fine-grained security provisions – including secure authorisation to access the resources – and other techniques to secure the administration features of the system. There are other features like templates for constructing Handles of similar pattern. Moreover, the requirements for scalability were envisaged from the outset, and implementation has been designed with the need for clustering the servers from the beginning. Thus, this solution is very capable of being scaled up into very large numbers of components. In Section 8 we then consider how the Handle System can be applied to IoT, and its components. One such component is the sort of complex DO represented by the gateways described in the earlier WP2/WP3 work. We consider in this section how its functionality could be decomposed into separate processes. The Handle System could take over some of the functionality of such components, and could



route any operations to processes that embrace more of the functionality. We consider here also aids to the automatic registration of objects facilitated by the Handle System.

The main Use Case pursued in the IoT6 project is Automated Building Management (ABM). Thus it is important to show how Handle would help in the implementation of an ABM management system. In Section 10 we then consider the provisions in the system for programmability, and how this work links in to the previous thread of the IoT6 activity. Here we consider also some of the aspects of Sensing and Actuation as a Service (SAaaS). The Handle Service has been compared to the DNS. There are similarities, but we discuss also the differences. An important aspect is the capability of programmable features of Handle interfaces. In Section 10 these aspects are considered in some detail, and we discuss how activity based on Handle relate on the one hand to HTTP and REST interfaces, on the other the links to previous IoT6 work on Digcovery and legacy ABM systems. Finally, some conclusions are drawn in Section 11.



3 6LoWPAN 6LoWPAN [1] is a Working Group in IETF which defines the use of IPv6 on IEEE 802.15.4 links. 6LoWPAN has been implemented in several Operating Systems such as Contiki [2]. In particular, Contiki implements addressing, fragmentation, and header compression of 6LoWPAN protocol. The Contiki implementation is based on RFC4944 [3] (Transmission of IPv6 Packets over IEEE 802.15.4 Networks), the Internet draft “Interoperability Test for 6LoWPAN” [4] and the Internet draft “Compression format for IPv6 datagrams in 6LoWPAN Networks” [5]. In the following we describe the 6LoWPAN implementation of addressing, fragmentation, and header compression.

3.1 Addressing In Contiki, 6LoWPAN currently only supports 802.15.4 64-bit addresses based on RFC4944. RFC4944 defines address configuration mechanisms based on 802.15.4 16-bit and 64-bit addresses, fragmentation of IPv6 packets below IP layer, IPv6 and UDP header compression, a mesh header to enable link-layer forwarding in a mesh-under topology, and a broadcast header to enable broadcast in a mesh-under topology. The format of an 802.15.4 address is defined in uip.h with the structure uip_802154_longaddr.

The IPv6 local-link addresses of the nodes are determined automatically using Stateless Address Auto-configuration [6]. Each node appends its link-layer 6 bytes address to the local-link network prefix (fe80::0/64). When the function tcpip_process is started, the address configuration is done, followed by some IPv6 ND [7] messages which are exchanged (such as Duplicate Address Detection and Router Solicitation). If a router is present, it may give some extra addresses to the node such as the prefix of global address (aaaa::0/64). In Contiki, the 6LoWPAN implementation can operate with both addressing schemes.

3.2 Input/Output Packet 6LoWPAN is called by the MAC layer when a 6LoWPAN packet is received and by the transport layer when an IPv6 packet needs to be sent. It is initialised from the MAC layer, which calls the function sicslowpan_init (giving as argument a pointer to the mac_driver structure). The main 6LoWPAN functions are implemented in the sicslowpan.h and sicslowpan.c files. They are used to format packets between the 802.15.4 and the IPv6 layers. 6LoWPAN also creates a few IPv6 and link-layer dependencies.

At initialisation, the input function in sicslowpan.c is set as the function to be called by the MAC upon packet reception. At packet reception, the link-layer copies the 802.15.4 payload in a memory buffer, and sets its length. It also stores the source and destination link-layer addresses as two networking addresses for sender and receiver.

It then calls the sicslowpan_input function. Similarly, when the IPv6 layer has a packet to send over the radio, it puts the packet in the buffer (uip_buf), sets the length(uip_len) and calls the sicslowpan_output function. The output function is set as the tcpip_output function.

3.3 Fragmentation Fragmentation is enabled by setting the SICSLOWPAN_CONF_FRAG compilation option. To support fragmentation, Contiki provides two functions described below:

• Output function: When an IP packet, after header compression, is too big to fit in an 802.15.4 frame, it is fragmented in several packets which are sent successively



over the radio. The packets are formatted as defined in RFC 4944. Only the first fragment contains the IP/UDP compressed or uncompressed header fields.

• Input function: This function takes care of fragment reassembly. We do not assume that the fragments are received in order. When reassembly of a packet is on-going, we discard any non-fragmented packet or fragment from another packet. Reassembly times out after SICSLOWPAN_REASS_MAXAGE = 20s.

As we do not support a complex buffer allocation mechanism, we define for now a new 1280 bytes buffer (sicslowpan_buf) to reassemble packets. At reception, once all the fragments have been received, we copy the packet to the buffer(uip_buf), set the length(uip_len), and call the function tcpip_input.

In addition, MAC_MAX_PAYLOAD defines the maximum payload length in an 802.15.4 frame. Currently, it is constant and equal to 102 bytes (the 802.15.4 frame can be maximum 127 bytes long, and the header 25 bytes long).

3.4 Header Compression The implementation supports the header compression scenarios defined in [4]. This defines an interoperability scenario which was used between wireless sensor devices. In [5], it defines a stateful header compression mechanism which should soon deprecate the stateless header compression mechanism defined in RFC4944. It is much more powerful and flexible, in particular it allows compression of some multicast addresses and of all global unicast addresses.

The SICSLOWPAN_CONF_COMPRESSION compilation option defines the compression scheme supported. We support HC1, HC01, and IPv6 compression. HC1 and IPv6 compression are defined in RFC4944, HC01 in [5]. What we call IPv6 compression means sending packets with no compression, and adding the IPv6 dispatch before the IPv6 header.

If at compile time IPv6 “compression” is chosen, packets sent will never be compressed, and compressed packets will not be processed at reception. If at compile time either HC1 or HC01 are chosen, we will try to compress all fields at sending, and will accept packets compressed with the chosen scheme, as well as uncompressed packets. Note that HC1 and HC01 supports are mutually exclusive.

3.4.1 Compression-related functions

When a packet is received, the input function is called. Fragmentation issues are handled, then we check the dispatch byte: if it is IPv6, we treat the packet inline. If it is HC1 or HC01, the corresponding decompression function (uncompress_hdr_hc1 or uncompress_hdr_hc01) is called.

When a packet needs to be sent, we try to compress it. If only the IPv6 compression support is enabled, we just add the IPv6 dispatch before the 802.15.4 payload. If HC1 or HC01 support is enabled, we call the corresponding compression function (compress_hdr_hc1 or compress_hdr_hc01) to compress the packet as much as possible.

In HC1, if the IPv6 Flow Label is not compressed, we would need to copy the fields after the Flow Label starting in the middle of a byte (the Flow Label is 20 bits long). To avoid this, we compress the packets only if all fields can be compressed. If we cannot, we use the IPv6 dispatch and send all headers fields inline. This behaviour is the one defined in [4]. In the same way, if the packet is an UDP packet, we compress the UDP header only if all fields can be compressed. Note that HC1 can only compress unicast link local addresses. For this reason, we recommend using HC01.



HC01 uses address contexts to enable compression of global unicast addresses. All nodes must share context (namely the global prefixes in use) to compress and uncompress such addresses successfully. The context number is defined by 2 bits. Context 00 is reserved for the link local context. Other contexts have to be distributed within the LoWPAN dynamically, by means of ND extensions yet to be defined. Note that if you want to test global address compression (i.e. 0xaaa::0), you need to configure the global contexts manually.

3.5 UDP transport layer The procedure to send and receive UDP datagrams is very easy. The UDP connection must be filled with the other node's IP address and the destination port used, and the local port number may be specified. Then the functions called are:

• struct uip_udp_conn * udp_new (const uip_ipaddr_t *ripaddr, u16_t port, void *appstate)

o This function creates a new UDP connection. If the connection is used to send data to a specific host, the arguments ripaddr (remote IP address) and port must be filled adequately, otherwise ripaddr may be set to NULL and port to 0 in order to accept any incoming datagram. appstate is a pointer to some data that will be passed to the process when UDP events will occur. The function returns a pointer to the connection that will be used by all the other functions afterward. The function chooses a local port number arbitrarily.

• udp_bind(conn, port) o This macro binds an open UDP connection to a local port number. The

specified port will be the source port used to send datagrams as well as the listening port for incoming datagrams.

• uip_newdata() o This macro indicates if there is data available on the connection. If so it

can be accessed from the pointer uip_appdata and the length obtained by uip_datalen().

3.6 API interface for IEEE 802.15.4 technology For 6LoWPAN, an API interface is implemented in the api_6lowpan.h and api_6lowpan.c files in the core/net directory. These files provide the API interface for application layer to communicate via 6LoWPAN protocol. The main functions implemented for 6LoWPAN are described below.

• void api_6lowpan_bindTCPPort (unsigned short port) o This function binds a TCP connection to a local port. This function sets up

a new TCP connection. The function will automatically allocate an unused local port for the new connection. The local port number is changed to network byte order. Parameters:

• port The local port number. Returns:

• None.

• void api_6lowpan_bindUDPPort( struct uip_udp_conn* conn, unsigned short port)



o This function binds a UDP connection to a local port. This function sets up a new UDP connection. The function will automatically allocate an unused local port for the new connection. The local port number is changed to network byte order. Parameters:

• conn A pointer to the uip_udp_conn structure for the connection.

• port The local port number. Returns:

• None.

• void api_6lowpan_closeSocketTCP(void) o This function closes a previous IPv6/TCP connection.

Parameters: • None.

Returns: • None.

• void api_6lowpan_closeSocketUDP(struct uip_udp_conn * conn)

o This function closes a previous IPv6/UDP connection. Parameters:

• conn The UDP connection in a pointer to a structure uip_udp_conn.

Returns: • None.

• uip_ipaddr_t * api_6lowpan_getIPv6Address(void)

o This function gets the IPv6 address of the node. Parameters:

• None Returns:

• IPv6-address of the node in a structure uip_ipaddr_t.

• MAC_ExtAddr_s * api_6lowpan_getLocalAddress(void) o This function gets the local address of the node.

Parameters: • None

Returns: • MAC-address of the node in a structure MAC_ExtAddr_s.

• struct uip_conn* api_6lowpan_openSocketTCP(unsigned short

address_dst[8], unsigned short port_dst) o This function opens a new socket IPv6/TCP to a destination node. This

function is used to start a new connection to the specified port on the specified host. It allocates a new connection identifier, sets the connection to the SYN_SENT state and sets the retransmission timer to 0. This will cause a TCP SYN segment to be sent out the next time this connection is periodically processed, which usually is done within 0.5 seconds after the call to uip_connect(). Parameters:



• address_dst The IPv6 address of the destination node in an array of unsigned short.

• port_dst The port of the destination node. Returns:

• The TCP connection in a pointer to a structure uip_conn.

• struct uip_udp_conn* api_6lowpan_openSocketUDP(uint16_t * address_dst, uint16_t port_dst)

o This function opens a new socket IPv6/UDP to a destination node. This function sets up a new UDP connection. The function will automatically allocate an unused local port for the new connection. Parameters:



• The UDP connection in a pointer to a structure uip_udp_conn.

• void api_6lowpan_print_local_ipv6_address(void) o This function prints local IPv6 address.

Parameters: • None.

Returns: • None.

• void api_6lowpan_sendTCP(uint8_t * data, uint16_t len)

o This function sends data through the current TCP connection. Parameters:

• data A pointer to the array of data. • len The length of data.

Returns: • None.

• void api_6lowpan_sendUDP (struct uip_udp_conn * conn, uint8_t * data,

uint16_t len) o This function sends data through an UDP connection.

Parameters: • conn A pointer to the uip_udp_conn structure for the

connection. • data A pointer to the array of data. • len The length of data.

Returns: • None.

• void api_6lowpan_receiveUDP(uint8_t* data, uint16_t len, struct

uip_udp_conn* conn) o This function receives data through an UDP connection.

Parameters:



• conn A pointer to the uip_udp_conn structure for the connection.

• data A pointer to the array of data. • len The length of data.

Returns: • None.

• void api_6lowpan_setIPv6Address(uint16_t * address)

o This function sets the IPv6 address of the node. Parameters:

• The IPv6 address in an array of unsigned short. Returns:

• None.

3.7 Testing of 6LoWPAN. To test 6LoWPAN, two applications are provided in the client-api-6lowpan-testing.c and server-api-6lowpan-testing.c files in the apps/app-api-6lowpan directory. The client application sends periodic messages to the server device using the IPv6/UDP connection. The server application receives and processes packets from the client device using the IPv6/UDP connection.

The evaluation of the 6LoWPAN protocol is performed by two JN5139 devices [8] from the Jennic company with 802.15.4 radio as shown in the next figure. The server application starts in the process definition. First a UDP connection is created, specifying remote IP address and port as 0, indicating it's a listening connection. Then the local UDP port is bound to 50000, which means the connection listens on that port. Finally, an infinite loop is entered waiting for TCP/IP events, and calling a handler function when these occur.

Figure 1: JN5139 mote from the Jennic company

When the server receives data from the client, the handler function checks if new data is available from the buffer uip_buf. If so, it prints the received data for debug as well as the sender IP address and port, then prepares a response datagram. The connection information must be updated in order to send the response to the emitter of the message. Therefore, the ripaddr and rport fields of the UDP connection structure are filled with the sender information extracted from the received IP packet. Then the function for sending the packet is invoked. Finally the UDP connection structure is updated back to its original state (with remote IP address and port set to 0) in order to be able to receive datagrams from any host.



4 GLoWBAL-IPv6 The GLoWBAL-IPv6 protocol has been proposed to provide for an Access Address/Identifier (AAID) which simplifies every parameter from IPv6 communications (source and destination address/port, 36 bytes) in a single 4-byte communication identifier. Thus, the 41 bytes from the IPv6/UDP headers based on 6LoWPAN with global IP addressing can be significantly reduced. This achieves an effective frame format for global communications, and also a mechanism to support global communications in networks that do not have native support for IPv6. The details of the protocol have been fully described in [9].

This section describes the implementation of GLoWBAL-IPv6 using the Jennic JN5139 platform with 802.15.4 radio. In addition, a Jennic USB ethbridge acts as AAID gateway to collect all the received packets for AAID nodes through its 802.15.4 radio and manages the traffic from Internet network via a USB port that emulates an Ethernet interface.

In GLoWBAL-IPv6, each Jennic device implements a table L2G that allows saving a maximum of MAX_AAID_ENTRIES. When the table L2G is full then the new AAID entry is discarded. For avoiding this failure situation, each AAID entry has a maximum time to be stored in the table before it is removed. Moreover, the tableL2G prevents AAID duplicates because the hash function generates the same AAID identifier for different connections of IP-source, IP-destination, Port-source and Port-destination. Here, we introduce the most common fields of each entry in the L2G table:

IP6_SRC: IPv6 address of the source node.

IP6_DST: IPv6 address of the destination node.

PORT_SRC: 16-bits port of the source node.

PORT_DST: 16-bits port of the destination node.

AAID: 32-bits identifier of the access address.

TIMEOUT: maximum time after removing the AAID entry.

In additional, Jennic devices employ three types of packets to guarantee a reliable wireless communication between an AAID node and an AAID gateway over 802.15.4 wireless technology.

DATA: packets for sending the data payload of an application. This contains AAID dispatch, AAID identifier and payload.

ACK: packets for confirming the reception of SETTING and DATA packets. This contains an error code if there is some failure in the communication between the AAID node and AAID Gateway.

SETTING: packets for establishing a new AAID entry for a session between a source node of 802.15.4 network and a destination node of Core network. This contains AAID dispatch, AAID identifier and inline fields of IP-source, IP-destination, Port-source and Port-destination.

Below we describe the functionalities of each AAID node. Its operation is divided in the following modules two modules:

Sending Module: This module sends the data payload required by an application layer via the 802.15.4 radio interface. First, it checks that the AAID identifier is previously used and available in its L2G. Otherwise, a setting packet is transmitted to include the AAID identifier in the L2G mapping table of the AAID Gateway.



Figure 2: Sequence diagram of AAID sending module

Receiving Module: This module manages the packets received by each Jennic device using 802.15.4 radio interface. It indicates the three types of packets according to the AAID entries stored in its table L2G. This checks the possible error in the AAID communication such as duplicated AAID, no-stored AAID and full table L2G.

Figure 3: Sequence diagram of AAID receiving module

Here we describe the functionalities of the AAID Gateway. Its operation is divided in the following modules two modules:

Native-network Module: This corresponds with the module allocated in the Jennic-USB ethbridge to manage the traffic generated from the native devices with the AAID technology



support to the Core Network. This identifies and knows deeply the connection and session information for each device, since this manages the L2G table. This module hears the radio transmission, in this case IEEE 802.15.4 technology. This checks that the AAID is previously used and available in the L2G, or it is a set message and requires including in the L2G mapping table.

Core-Network Module: This is also allocated in the Jennic-USB ethbridge to manage the incoming traffic from the Core Network to the specific technologies and specifications. This module is an application, which is listening in promiscuous mode the messages received from the global network via the USB port. Once a message is received, this receiver maps the IPv6 destination address to the correspondent AAID and follows the mapping specifications in order to detect if this is from a previous session, or it is required to set up a new AAID. Then, the ethbridge manages the AAID communication with the AAID node specified with the IPv6 destination address.

4.1 API interface for IEEE 802.15.4 technology For GLoWBAL-IPv6, an API interface is implemented in the api_glowbalip.h and api_glowbalip.c files in the core/net directory. These files provide the API interface for application layer to communicate via GLoWBAL-IPv6 protocol. The main functions implemented for GLoWBAL-IPv6 are described below.

• uint32_t api_glowbalip_calculateAAID (uip_ip6addr_t * ip6addr_src, uip_ip6addr_t* ip6addr_dst, uint16_t port_src, uint16_t port_dst)

o This function receives data through an AAID connection. Parameters:

• aaid The AAID identifier of the connection. • data A pointer to the array of data. • len The length of data.

Returns: • None.

• bool api_glowbalip_closeSocketAAID(uint32_t aaid)

o This function closes a previous IPv6/AAID connection. This receives as parameter the AAID identifier of the opened connection. Parameters:

• aaid The AAID identifier of the connection. Returns:

• bool. TRUE indicates all right. FALSE indicates a wrong AAID identifier.

• uip_ip6addr_t * api_glowbalip_getDestinationAddress(uint32_t aaid) o This function gets the source IPv6-Address of the specific AAID

connection. Parameters:


• The IPv6 Address of my Jennic mote.

• uint16_t api_glowbalip_getDestinationPort(uint32_t aaid) o This function gets the destination Port of the specific AAID connection.



Parameters: • aaid The AAID identifier of the connection.

Returns: • The Port of my Jennic mote.

• uip_ip6addr_t * api_glowbalip_getIPv6Address(void)

o This function gets the IPv6 address of the node. It has not any input parameter and returns the IPv6 address of the device. Parameters:

• None Returns:

• IPv6-address of the node in a structure uip_ip6addr_t.

• MAC_ExtAddr_s * api_glowbalip_getLocalAddress(void) o This function gets the local address of the node. This has not any input

parameter and returns the MAC-layer address of the device (i.e. EUI-64 identifier). Parameters:

• None Returns:

• MAC-address of the node in a structure MAC_ExtAddr_s. • uip_ip6addr_t * api_glowbalip_getSourceAddress(uint32_t aaid)

o This function gets the source IPv6-Address of the specific AAID connection. Parameters:


• The IPv6 Address of the Jennic mote.

• uint16_t api_glowbalip_getSourcePort(uint32_t aaid) o This function gets the source Port of the specific AAID connection.

Parameters: • aaid The AAID identifier of the connection.

Returns: • The Port of my Jennic mote.

• void api_glowbalip_init(void)

o This function initialises all modules of GLoWBAL-IP communications. Parameters:

• None. Returns:

• None.

• uint32_t api_glowbalip_openSocketAAID (uip_ip6addr_t* ip6addr_src, uip_ip6addr_t* ip6addr_dst, uint16_t port_src, uint16_t port_dst)

o This function opens a new socket IPv6/AAID to a destination node. This function sets up a new AAID connection. The function will automatically allocate an unused local port for the new connection. Parameters:





• The AAID identifier of the connection.

• bool api_glowbalip_sendAAID(rimeaddr_t * rimeaddr_dst, uint32_t aaid, uint8_t * data, uint16_t len)

o This function sends data through an AAID connection. This has three input parameters for indicating the AAID identifier of the opened connection, the payload and the length to transmit. rimeaddr_dst must be the MAC-Address of the ethbridge-mote if the destination node is outside the local area network. rimeaddr_dst must be the MAC-Address of the Destination-mote if the destination node is inside the local area network. Parameters:

• rimeaddr_dst The MAC-Address of the next-hop mote.

• aaid The AAID identifier of the connection. • data A pointer to the array of data. • len The length of data.

Returns: • bool. TRUE indicates all right. FALSE indicates a wrong

AAID identifier.

• void api_glowbalip_receiveAAID(uint32_t aaid, uint8_t *data, uint16_t len) o This function receives data through an AAID connection.

Parameters: • aaid The AAID identifier of the connection. • data A pointer to the array of data. • len The length of data.

Returns: • None.

• void api_glowbalip_setIPv6Address(unsigned short address[8])

o This function sets the IPv6 address of the node. It has one input parameter with the MAC-layer address of the device (i.e. EUI-64 identifier). Parameters:

• The IPv6 address in an array of unsigned short. Returns:

• None.

4.2 Implementation of GLoWBAL-IPv6 applications. For GLoWBAL-IPv6, two applications were implemented in the client-api-glowbalip-testing.c and server-api-glowbalip-testing.c files in the apps/app-api-glowbalip directory. The client application sends periodic packets to the server device. The server application receives and processes data frames from the client device.

In addition, a GLoWBAL-IPv6 ethbridge is implemented to make the integration of sensor networks easy. The ethbridge builds a bridge between a IEEE 802.15.4 wireless sensor



network and Ethernet-based LAN infrastructures. It offers a USB CDC Ethernet interface, and an IEEE 802.15.4 compliant radio interface. Plugged into the USB port, it emulates a serial communication port for communication with the radio interface on the device. The ethbridge is freely programmable using the Contiki Operation System including the GLoWBAL-IP/IPv6 dual-network stack: the GLoWBAL-IP stack for communicating with devices in the wireless sensor network and the IPv6 stack for communicating through the Ethernet to any IPv6 machine.

The ethbridge receives messages from Jennic nodes using the GLoWBAL-IPv6 protocol and resend via USB-Ethernet in IPv6 protocol. The ethbridge receives messages from the PC daemon using the IPv6 protocol and resend via IEEE 802.15.4 in the GLoWBAL-IPv6 protocol. The ethbridge also processes Neighbour Solicitation messages from PC daemon using Neighbour Discovery protocol and resend Neighbour Advertisement. The GLoWBAL-IPv6 ethbridge is implemented in the ethbridge-glowbalip.c file in the apps/app-ethbridge-glowbalip directory.

4.3 Evaluation of GLoWBAL-IPv6 To evaluate GLoWBAL-IPv6, an AAID Gateway was deployed in a multi-protocol based on an ARM CPU and an embedded Linux OS, and also in an IEEE 802.15.4 USB ethbridge based on the Jennic JN5139 chip.

Figure 4: AAID Gateway defined in the multi-protocol card (left) and also based on the IEEE

802.15.4 USB Ethbridge (right).

The platform for the AAID Gateway is presented in the left of the figure. It is based on the 32 bit processor ARM9@400Mhz, with 256MB LPDDR RAM memory, and 256MB NAND memory, which supports Linux OS. This offers an Ethernet 10/100Mbps (A), 2 USB 2.0 ports (B), 4 Serial RS232 ports (C), Bluetooth 2.1 with HDP profile compliant with BlueGiga (D), GPRS from WaveCom (E), IEEE802.15.4 ZigBee from Jennic (F), 24 inputs/outputs among digital/analogue/relays (G), a compact flash support for data logging (H), and a touch screen LCD (I). Finally, other interesting capabilities include continuous sensing such as real-time watch, 5 high precision timers, 2 analogue/digital converters for analogue signal processing, a random number generator for security seeds, and IPv6 stack support.

In addition, the USB ethbridge node is shown in the right of the figure. It is based on the Jennic JN5139 module. This also has a 32-bit processor OpenRISC. This supports the IEEE802.15.4 stack, and ZigBee Pro. It is also possible to set it up with 6LoWPAN, but for this evaluation it has been defined with the basic IEEE 802.15.4 stack. This is connected to the PC through the USB port. Thereby, it is easily programmable and allows debugging the results through the emulated serial port. In the following, we present the evaluation carried over this platform, where the AAID approach has been implemented.



The GLoWBAL-IPv6 protocol was evaluated by measuring the performance and scalability of this system and the interactivity and mapping process between the AAID node and the AAID Gateway over the IPv6 network of the University of Murcia. The AAID mapping performance has been evaluated in the above-mentioned multi-protocol card. This multi-protocol board is in charge of mapping between the multiple technologies and its corresponding IPv6 addresses and vice-versa. In the AAID node, the incoming packets are pre-analysed to determine the session from the coming packet, and post-processed in order to include the AAID information to the payload.

The mapping process has been evaluated with a flow of packets between a server host and an AAID node with 500 consecutive requests (each one with different port). Over this evaluation, it has been calculated the total time for processing the mapping and the reply. Therefore, it is calculated the transmission time as the difference between the total time, and the time calculated locally in the AAID Gateway and AAID node for the processing. The result is divided by 2, in order to consider only the time for transmission in one way, not for the full round-trip.

The results are presented in the next figure; As mentioned the data presentation distinguishes between the processing in the AAID Gateway, the processing in the AAID node and the one-way transmission time (half of the round-trip transmission time).

Figure 5: Performance evaluation for the AAID mapping in AAID Gateway and AAID node.

In addition, a summary of the results are shown in the following table, in which the minimum, maximum, and average for each one of the times considered is calculated. The mapping processing does not introduce a high delay.

Figure 6: Summary of the mapping performance for 500 sessions.

Specifically, the mapping processing in the AAID gateway is practically instantaneous, and it is only a little bit higher in the AAID node. This also presents an average time of 22 milliseconds. Therefore, it is totally suitable to carry out this mapping processing. Note that the transmission times are low, since it was evaluated with a server located at the same network.



5 IPv6 Addressing Proxy The IPv6 addressing Proxy [11] has been implemented in a multi-protocol card which is presented below.

Figure 7: Multi-protocol card used for the evaluation of IPv6 addressing proxy

This multi-protocol card is based on the Atmel ARM9 processor running at 400MHz (32-bit) with 256MB LPDDR RAM and 256MB NAND memory, which supports Linux OS. This board supports, through its extension interfaces (serial RS232 and SPI ports), the technologies for industrial and building automation. More specifically, the extension interfaces support Control Area Networks (CANs), X10 and European Industrial Bus (EIB)/Konnex (KNX). This multi-protocol board is in charge of mapping between the multiple technologies and their corresponding IPv6 addresses and vice-versa (see the next deployment scenario).

Figure 8: Evaluation framework of IPv6 addressing proxy

The implemented scenario is composed of the following software modules and clients:

Transceiver Driver: Software in the multi-protocol card manages the traffic generated from the legacy technologies to the Core Network. This software identifies and has detailed knowledge about the node’s technology. This is needed to build the IPv6 address following the mapping techniques presented in D2.1. The software listens to the native interfaces in



accordance with the technology used for each device (e.g. X10, EIB/KNX, CAN), i.e. Serial Ports.

Receiver Module (Daemon): Software in the multi-protocol card manages the incoming traffic from the Core Network to the specific sensor system. This software listens for messages sent by the Clients. Once a message is received, this receiver decodes the IPv6 destination address and technology. It follows the mapping specifications in order to make a message in the format of the requisite technology.

Remote Client Application: A client in this infrastructure is some device which is received information about a sensor located e.g. a remote server. This client has two options. On the one hand, it can be aware of the mapping and try to understand the native features of the device from a transformation of the IPv6 address information related to the technology being used. On the other hand, a recommended option is to abstract data from the technology and to define homogeneous Web Services based on RESTful/CoAP.

Now, we will focus on an explanation of the mapping processing in the Receiver module (daemon). First, this defines the function checking technology. Its operation will depend on where the technology id is allocated. Second, the Receiver knows with which technology should be used in the mapping processing. In the mapping process, it is necessary to take care of some typical situations in the IPv6 parsing:

A field is set to 8 bits, corresponding to a complete byte. This case is the easiest, and we only have to check the value of this byte.

A field is set to a number of bits smaller than 8 within a byte. In order to extract it, a division is needed and we will obtain the value if it is at the beginning or a module operation will be necessary if it is at the end of the byte.

A field is set in different bytes. In this case, we will need to obtain the value of each one and to do a multiplication for the corresponding power of 2 in each byte.

A field is set in two different bytes, so we need to extract the corresponding part of each byte and reset the value of each part in their proper proportion.

The most complex case is the mapping specification. In order to decrease the delay and increase the scalability of the mapping processing, multiple daemon can be defined with each listening to a different interface, rather than having only one daemon listening to every request on one network interface. For that reason, the possibility of discriminating the technology at the network layer instead of the application layer was considered.

The best case for this routing-based discrimination would be if the ISP provides us with an IPv6 network with 48 bits of netmask. In this case, we would be able to set up different networks and a virtual interface for each network could be set up. In this scenario, the kernel is in charge of managing the routing of the message to the correct interface.

To take full advantage of this scheme, in our case we had to set up 3 daemons, one for each technology. This is because a daemon can listen only to one sub-network. Indeed, we might even need to define multiple daemons to one technology, carrying out a division per line, in order to increase the scalability. Here we note that in the future it will be possible to process the daemons in a parallel architecture (multiple CPUs).

In the case of only one daemon for all the technologies, it will need to check which technology is being used in the mapping. This is because potentially there can be requests from different technologies. Below, a performance evaluation comparing the two approaches is presented.



For that reason, this evaluation is focused on: the evaluation of the overload and processing time required for the IPv6 addressing proxy through the mean time for the translation from each independent receiver module for each technology, and on an evaluation about the scalability through the performance with a flow of requests in order to evaluate, which of the approaches is more relevant, a common daemon or a daemon for each sub-network/interface.

5.1 API interfaces for X10, CAN and KNX technologies For IPv6 Addressing Proxy, an API interface is implemented for each technology. These implementations provide the interface for the application layer to establish IPv6 communication via the addressing proxy protocol. In the next subsection, the main functions implemented for each technology are described.

5.1.1 API functions for X10 technology

• uint8_t* api_proxy_getAddress_x10(void): o This function gets the X10 address of the device.


Returns: • The identifier of the X10 device.

• int api_proxy_send_x10(struct x10_mapping* x10_addr, uint8_t * frame, uint16_t len):

o This function sends a data frame to a local X10 device.

Parameters: • X10_addr The X10 address of the destination device. • frame The pointer of the data frame. • len the length of the frame to transmit.

Returns: • The result of the function.

• void api_proxy_receive_x10(struct x10_mapping* x10_addr, uint8_t * frame, uint16_t len):

o This function receives a data frame from a local X10 device.

Parameters: • X10_addr The X10 address of the source device. • frame The pointer of the data frame. • len the length of the frame received.

Returns: • None

• int api_proxy_parse_ipv6_to_x10(struct in6_addr* ip, struct x10_mapping * x10_addr):

o This function converts the global IPv6 address of a node to its local X10 address.

Parameters: • X10_addr The identifier of the X10 device • ip The IPv6 address of the X10 device



Returns: • The result of the function

• int api_proxy_parse_x10_to_ipv6(struct x10_mapping * x10_addr, struct in6_addr* ip):

o This function converts the local X10 address of a node to its global IPv6 address. This combines the local X10 address with a pre-established prefix for the X10 technology.

Parameters: • X10_addr The identifier of the X10 device • ip The IPv6 address of the X10 device


5.1.2 API functions for CAN technology

• uint8_t* api_proxy_getAddress_can(void): o This function gets the CAN address of the device.


Returns:

• The identifier of the CAN device.

• int api_proxy_send_can(struct can_mapping* can_addr, uint8_t * frame, uint16_t len):

o This function sends a data frame to a local CAN device.

Parameters: • can_addr The CAN address of the destination device. • frame The pointer of the data frame. • len the length of the frame to transmit.

Returns:

• The result of the function.

• void api_proxy_receive_can(struct can_mapping* can_addr, uint8_t * frame, uint16_t len):

o This function receives a data frame from a local CAN device.

Parameters: • can_addr The CAN address of the source device. • frame The pointer of the data frame. • len the length of the frame received.

Returns:

• None

• int api_proxy_parse_ipv6_to_can(struct in6_addr* ip, struct can_mapping * can_addr):

o This function converts the global IPv6 address of a node to its local CAN address.



Parameters: • can_addr The identifier of the CAN device • ip The IPv6 address of the CAN device


• int api_proxy_parse_can_to_ipv6(struct can_mapping * can_addr, struct in6_addr* ip):

o This function converts the local CAN address of a node to its global IPv6 address. This combines the local CAN address with a pre-established IPv6-prefix for the CAN technology.

Parameters: • CAN_addr The identifier of the CAN device • ip The IPv6 address of the CAN device


5.1.3 API functions for KNX technology

• uint8_t* api_proxy_getAddress_knx(void): o This function gets the KNX address of the device.


Returns:

• The identifier of the KNX device.

• int api_proxy_send_knx(struct knx_mapping* knx_addr, uint8_t * frame, uint16_t len):

o This function sends a data frame to a local KNX device.

Parameters: • knx_addr The KNX address of the destination device. • frame The pointer of the data frame. • len the length of the frame to transmit.

Returns:


• void api_proxy_receive_knx(struct knx_mapping* knx_addr, uint8_t * frame, uint16_t len):

o This function receives a data frame from a local KNX device.

Parameters: • knx_addr The KNX address of the source device. • frame The pointer of the data frame. • len the length of the frame received.

Returns:

• None



• int api_proxy_parse_ipv6_to_knx(struct in6_addr* ip, struct knx_mapping * knx_addr):

o This function converts the global IPv6 address of a node to its local KNX address.

Parameters: • knx_addr The identifier of the KNX device • ip The IPv6 address of the KNX device

Returns:


• int api_proxy_parse_knx_to_ipv6(struct knx_mapping * knx_addr, struct in6_addr* ip):

o This function converts the local KNX address of a node to its global IPv6 address. This combines the local KNX address with a pre-established IPv6-prefix for the KNX technology.

Parameters: • knx_addr The identifier of the KNX device • ip The IPv6 address of the KNX device

Returns:


5.2 Evaluation of IPv6 Addressing Proxy For determining the processing time for the mapping process itself the mean time for the mapping process was determined. The time difference introduced by the addressing proxy in the mapping process presents a mean time of 7.89 milliseconds for X10, 7.74 milliseconds for CAN and 7.05 milliseconds for EIB/KNX. The little differences are mainly due to the involved mathematical operations which introduce some complexity into the mapping operation.

5.2.1 Scalability evaluation

For the scalability evaluation of the IPv6 Addressing Proxy, multiple requests from a remote client were generated. Specifically, 900 consecutive requests were arranged (300 for each technology). The times are averages from the 900 requests in a window time of one minute in order to evaluate the scalability of the buffers.



Figure 9: Average of times in the IPv6 mapping processing with application or routing modes

This figure presents a comparison between the solution based on application (1 daemon) and routing mode (3 daemons). This shows a considerable reduction of the time. Clearly the routing mode from the Linux Kernel offers a more scalable solution than management at the user level, because it allows the multiple processing of packets with independent interrupts. In addition, this reduces the requirements for local buffers for queues. In the future, there could be further reduction by using platforms with multiple-cores for parallel processing.



6 Overview of Provision of IoT Services using the Handle

System 6.1 Introduction In the IoT6 project, interesting and relevant work has been done on gateways, repositories and IPv6. While the context has been Automated Building Management (ABM), many of the considerations are more general. In the next few sections, we describe a further development which has important deviations from the previous work. Particularly in ABM, but also in many other applications, there are major legacy sensor and actuation systems. Conventionally these had only local control interfaces, but more recently they have added Internet interfaces (currently only IPv4). These normally just export the local operations to ones that can be done over a network. While we would like to replace such systems by ones completely suited to the Internet, this will not happen rapidly. These systems we call DeviceNets, and their communications often does not use Internet technology. There has been a trend to try to put gateways in front of such controllers to translate between technology-independent operations, and the ones required by the specific technology. In the IoT6 project, we have put interfaces not only to such legacy systems, but also to IPv6 sensor/actuator systems running IPv6 and 6LoWPAN in the end-systems.

It has become clear that the number of end-systems that will need to be accessed over the Internet is very large – too large to be accommodated by the IPv4 address space. Moreover, the environments of the sensor/actuator systems may well be multiple-purpose, making wholesale use of NATs and IPv4 addressing impractical. For this and other reasons, we have postulated, for many IoT environments a network scene with three levels: the General Internet, the ServiceNet and the DeviceNet. The first is self-explanatory; we think it will eventually become IPv6, but that may take time. The third is the set of networks we have been describing before – which may not even be using IP internally. The second one is where the domain-specific IoT adaptation is carried out. For many environments, the ServiceNet is specific to a particular application and can be assumed IPv6 – but while this would be an advantage, it is not essential.

We have known in the past that IoT has other differences from the Internet. The importance of binding Names to IP addresses has been realised for the last 30 years, when the Domain Name System (DNS) was introduced. However, while the importance of a global DNS was realised, its functionality is rather limited by its original design objectives suited to the early Internet, where the main resources (data types) to be resolved were IPv4 addresses and names. In the IoT, we need much fuller descriptions of resources, so that digital entities (digital objects) and resource repositories become a vital ingredient. The repositories must be easy to access, and to search. For many purposes the eventual output is then the address that must be used for an operation (either in numerical IP-like form for a host/interface, or as a URI or equivalent notation for a service).

A third difference in IoT is the fine-grained nature of the authorisation required. The importance of security in the Internet has long been realised, but in the conventional Internet the authorisation required is often much more coarse-grained, and the devices themselves are more powerful and able to implement the precautions required.

In this second part of the deliverable, an overview is provided of a different approach to the IoT problem, which also serves as an evaluation, validation of IoT6 concept and significant



extension to the previous output of WP2. An overview of the approach is provided in this section; more details on specific aspects are provided in the later sections.

We will describe briefly in Section 6.2 what has been done in IoT6 to address some of these issues. In Section 6.3 a more radical approach is introduced – a Digital Object Architecture as exemplified by the Handle System that has been developed by CNRI. Most of the contents of this section are expanded in the subsequent sections. In Section 7 we delve deeper into some design features of the Handle System. In Section 8, we will then show how the concepts of DOA and their Handle System instantiations are important for IoT. In particular, in Section 8.2 we consider how gateways should be designed, and in Section 8.3 object registration is presented. Section 9 re-approaches the main Use Case scenario of IoT6 (Automated Buildings Management) in light of the developments discussed in Sections 6-8. In Section 9.5 we validate previous output of IoT6 and examine more generic approaches to GLoWBAL and the IPv6 addressing proxy for the IoT. Finally, Section 10 details programmatic access to Handle and its fit for IoT applications.

6.2 The Current IoT6 Repositories and Gateways In the 2nd year, a considerable effort has been made to make optimum use of IPv6. Thus every device in the DeviceNet is associated with an IPv6 address. This allows extensive use of a particular Service Resolution System called Digcovery to access specific local repositories, and then use the DNS to resolve commands towards specific IPv6 locations by a mapping of legacy systems identifiers with such addresses called GLoWBAL-IPv6 [9].

The translation between these IPv6 addresses and the native addresses needed for specific technologies is carried out in gateways. A special protocol mDNS [10] has been developed to ensure that the translation can be done unambiguously for each technology. This permits DNS to be used consistently throughout address resolution, and the related protocol DNS-SD to be employed for Service Discovery. The IPv6 address proxying mechanism has been described earlier in this deliverable as well as in [11]. The capabilities of the end-hosts and resources they support and operations allowed on them are described by entries in the Digcovery System. Security is provided by limiting access to the Digcovery System by passwords. A more detailed description of the Digcovery system is given in deliverable D3.3, including its limited security provisions (most of them inherent by design of the DNS subsystem that underlies it).

Because of the limited syntax capabilities of DNS, and the monolithic concept of the gateways, it is difficult to provide very fine-grained security in systems of this type. There are good facilities in the DNSSEC extension of the DNS for ensuring that DNS entries are trustworthy; these were recognised many years ago and have been well designed and implemented. Authorisation is required for creating, deleting or replicating entries. The integrity of the responses is guaranteed by the protocol. However, there is no need for authorisation in accessing the DNS and searching it for entries. Nor do DNS mechanisms protect any of the processes pointed to from its entries being used in an unauthorised manner. These are not accidental deficiencies of the DNS system; they were deliberately introduced to ensure the universality and speed of access of the total system.

6.3 The Digital Object Identifiers and the Handle System Rather than base identifiers on IPv6 addresses, it is more general to define Digital Objects. A digital object has a machine and platform independent structure that allows it to be identified, accessed and protected, as appropriate. Digital Objects have Identifiers, called Digital Object Identifiers. Bob Kahn, under whose aegis the DNS was developed while he was Director of



the relevant DARPA office, has developed the Digital Object Architecture (DOA), which provides a means of managing digital information in a network environment. The DOA enables interoperability across heterogeneous information systems.

With the considerations described in Section 6.1 regarding the network environments that the IoT6 project is trying to address in its DoW, we deduce a number of desirable properties for the network infrastructure to support the IoT:

1. A complete separation of Name and Network Address. The routing by Name may be through a complete application-domain-specific structure which has nothing to with any network topology.

2. Multiple Names for the same end-system. Thus one can choose to locate different network addresses with each name and use conventional routing techniques to access it.

3. Both the Name and the Address syntax hierarchic. The former to allow various application-domain forms of logical routing; the second to allow physically efficient forms of access.

4. The capability of authorisation (with fine-grained access permissions) based on strong-authentication techniques on the Name resolution of any node of the Name hierarchy. The Name Resolver should also be capable of high performance, and minimal or no limit on extensibility and capacity. The Name Resolution service should also be globally distributable.

5. The capability of having multiple names for a DO. This will automatically allow, in view of (4), different authorisations based on the logical path. It will also allow different attributes to be associated with each Name of the DO. (An example would be that an ABM component like a HVAC might have one Name for the occupant of the room; another for the buildings manager, and yet a third for the service engineer who may need to probe into the interior of the HVAC).

6. An extendable syntax of attributes associated with a Name. 7. A recursive capability, so that one of the attributes associated with a Name could be

another Name. 8. Use of caching in clients to avoid unnecessary duplication of effort for Name

Resolution and Access. In view of the requirement for security, the lifetime of caches must be limitable.

9. One or more repositories associated with a Name. There may be several, for instance one may represent static information, requiring only comparatively slow access and secure, even slower, update capability; another may hold transitory status information that requires less security and much faster update capability.

There are almost certainly many other properties required, and many implementations satisfying these may exist. The DNS system meets many of them – but not (1), (3) and (4). The CNRI [15] group, led by Kahn, developed the Handle System (HS) [12] as one component of the DOA just to handle such DOs and DOIs because the DNS syntax was too limited. The other two components (with associated protocols) also implemented by CNRI were the DO Repository and the DO Registry.

The Handle System (HS) includes an open set of protocols, a namespace, and a reference implementation of the protocols. The protocols enable a distributed computer system to store identifiers, known as Handles, of arbitrary resources and resolve those Handles into the information necessary to locate, access, contact, authenticate, or otherwise make use of the resources. This information can be changed as needed to reflect the current state of the identified resource without changing its identifier, thus allowing the name of the item to persist over changes of location and other related state information.



A Handle consists of a prefix and a local identifier. The syntax of the DO is a set of pairs (type, value). As with the Domain Name System (DNS) with its DNS Resource Directory (DNS-RD), the Handle Resolver (i.e. Handle server) will provide a set of such pairs, some of which include well-known data types, like URIs, INET_HOST addresses, etc. The pairs can be hierarchic, so that a DO contains descriptions and identifiers of other DOs in its parameters. Clearly some of the parameters may contain IPv6 addresses (as INET_HOST entries, see later description of data types) – but there may be several such addresses depending on different views of the parameters.

The HS incorporates an operational security system based on both private/public key pairs and passwords. The HS was developed initially with digital documents in mind, but it has evolved into a generic implementation of the DOA, supporting multiple object types, not just ‘digital documents’ (see further analysis in the following sections). It is an operational system with global distribution, many features to aid performance, resilience and scalability. It is being standardised for the ITU under ITU-T Recommendation X.1255 [15].



7 Some Features of the Handle System The following description of HS features is not an exhaustive list. We discuss features that we believe are pertinent to IoT applications and where the HS architecture can provide the necessary infrastructure and network operations to make these applications a reality with the least effort. In addition, the infrastructure satisfies many of the requirements of the IoT architectures and in particular, many of its desired functions.

7.1 Handles as Persistent Identifiers Handles are persistent identifiers for Internet resources. A Handle does not have to be derived in any way from the entity that it names – the connection is maintained within the Handle System. This allows the name to persist over changes of location, ownership, and other ‘current state’ conditions. When a named resource moves from one location to another, e.g., from an old server to a new server, the Handle is kept current by updating its value in the Handle System to reflect the new location.

The Handle System is designed to meet the following requirements for persistence.

Handles are:

• not based on any changeable attributes of the entity they identify (location, ownership, or any other attribute that may change over time);

• opaque, preferably ‘dumb numbers’ from which no potentially confusing meaning can be drawn, and from which no assumptions about ownership or use can be made;

• unique within the Handle System, avoiding collisions and referential uncertainty; • easy to make user friendly, human-readable, cut-and-paste-able, and can be embedded,

if needed; • easily fit into common systems, e.g., URI specification.

Handle resolution is:

• reliable, using redundancy, with no single points of failure and resolution time fast enough never to appear broken;

• scalable, so that higher loads are easily managed with more computers; • flexible and easily adapted to changing computing environments and new

applications; • trusted, with both resolution and administration built on proven trust methods; • built on an open architecture that encourages the community of users to build

applications on top of the infrastructure; • transparent to users who don't need to know the infrastructure details.

The above requirements for persistence fit most, if not all, the requirements of IoT architectures, including IoT6. In particular, where IETF-compliant standards have been defined for IoT operations, such as the CoRE group’s specifications of link formats and CoAP operations based on URIs, the above features cover all these aspects.

7.2 Handle Syntax Within the Handle namespace, every identifier consists of two parts: its Handle prefix, and a suffix or unique “local name” under the prefix. The prefix and suffix are separated by the ASCII character “/”. An identifier may thus be defined as



<handle> ::= <handle prefix> “/” <handle suffix>

For example, “10.1045/january2010-reilly” is an identifier (also known as a Digital Object Identifier (DOI) name, an implementation of the Handle System) for an article published in D-Lib Magazine. It is defined under the prefix “10.1045”, and its suffix is “january2010-reilly”.

Identifiers may consist of any printable characters from the Universal Character Set, two-octet form (UCS-2) of ISO/IEC 10646, which is the exact character set defined by Unicode v2.0. The UCS-2 character set encompasses most characters used in every major language written today. To allow compatibility with most of the existing systems and prevent ambiguity among different encodings, Handle protocol mandates UTF-8 to be the only encoding used for Handles. The UTF-8 encoding preserves any ASCII encoded names, which allows maximum compatibility to existing systems without causing naming conflict. The use of Universal Character Sets is a novelty in its own right, in IoT systems. A Buildings Operator or Administrator can even refer to language-localised versions of BMS s/w.

By default, Handles are case sensitive. However, any Handle service, including the global service, may define its namespace such that all ASCII characters within any Handle are case insensitive. The latter is the preferred approach in IoT environments.

The Handle namespace can be considered as a superset of many local namespaces, with each local namespace having its own unique prefix. The prefix identifies the administrative unit of creation, although not necessarily continuing administration, of the associated Handles. Each prefix is guaranteed to be globally unique within the Handle System. Any existing local namespace can join the global Handle namespace by obtaining a unique prefix, with the resulting identifiers being a combination of prefix and local name as shown above.

Each prefix may have derived prefixes. For example, once the prefix 12345 has been created, 12345.1 can be created. Derived prefix 12345.1 is therefore defined under prefix 12345. The syntax can be represented as “string.derivedstring”. In terms of Handle System technology, a derived prefix is a prefix in its own right and can be used any way that any other prefix can be used, but typically it is used as one of a set of connected prefixes.

Derived prefixes are sometimes used by organisations that assign identifiers to different categories of content or objects that they wish to keep separate. They are also used for test purposes. The prefix and the suffix, or local name, are separated by the octet used for ASCII character “/” (0x2F). The collection of local names under a prefix is the local namespace for that prefix. Any local name must be unique under its local namespace. The uniqueness of a prefix and a local name under that prefix ensures that any identifier is globally unique within the context of the Handle System.

7.2.1 Handle syntax for IoT applications

The syntax described above is the basis of the syntax we are using in IoT6. For example, UCL obtained the globally unique prefix 11175 from the international Handle registrar (currently at CNRI [15], but subject to change). Under this international prefix we can now allocate Handles at will. For example, in the buildings management Use Case of interest to IoT6, one can envisage the creation of a logical ‘next-step’ Handle for a smart building as ‘11175/EngBldg’. Then, further sub-Handles (which are Handles in their own right) are possible following the logical structure of the semantics of each application. Examples in our case, are ‘11175/EngBldg/Floor2’, ‘11175/EngBldg/Floor6/LightA’, ‘11175/EngBldg/AllSirens’, etc.



The beauty of Handles as arbitrary length opaque identifiers is that they can be neatly mapped onto URIs, which most RESTful implementations favour. The advantages become even more powerful for IoT when combined with programmatic access to a Handle server. Further details on this aspect can be found in Section 10.

7.3 Handle Resolution and relevance to IoT applications The Handle System allows identifiers (Handles) to be resolved in a distributed fashion, using dedicated clients, common clients such as web browsers using special extensions or plug-ins, or un-extended clients going through various proxies. In all cases, communication with the Handle System is carried out using Handle System protocols, and in all cases, those protocols have both a formal specification and some specific implementations.

Figure 10: The Handle resolution process

Figure 10 shows a client sending a request to the Handle System for the data associated with identifier 11175/UCLEstate. The following describes aspects of this communication structure.

• A client such as a web browser encounters a Handle, e.g., 11175/UCLEstate, on the Internet or an individual intranet, typically as a hyperlink or other kind of reference. The client sends the Handle to the Handle System for resolution. This can be done directly by a client who understands the Handle resolution protocol natively, or through a proxy server by a client which does not.

In the case of IoT clients, such as IP sensors, the proxy method is recommended. However, the queries are relatively simple and could be submitted by the end-nodes themselves, if required. There is no need to have the full Handle protocol specification



implemented on a node with reduced processing capabilities. Only the pertinent sections of the protocol that would allow the node to complete a successful request-response would suffice. It is expected that end-nodes of an IoT application would have a very clearly constrained set of capabilities specified.

• The Handle System consists of a collection of local Handle services. Each service consists of at least one primary site and any number of secondary sites, with each site containing any number of Handle servers. For resolution, each site replicates all of the identifiers in that Handle service.

This structure is independent of the application domain or end-node capabilities. It can provide the necessary infrastructure for any IoT application.

• The Global Handle Registry is responsible for knowing the locations and namespace responsibilities of the entire set of local Handle services. Each of these local services knows how to access the Global Handle Registry. This allows a resolution query to enter the Handle System at any point, and be routed to the server that knows the answer in any site within the responsible service.

There is a similarity here to the global DNS structure with root servers. However, in the most recent design development, the GHR function will be delegated to an international foundation.

• Each identifier can be associated with one or more pieces of typed data. In this example, the Handle 11175/UCLEstate is associated with, and so resolves to two URLs (it would also be possible to associate multiple instances of the same data type), and also XML and binary data. The client can request that the Handle server return to the client all of the data associated with that identifier, or all of the data of a specific type, or with a specific index value. The Handle System is a pure resolution system and carries no assumptions on what the client will or will not do with the resolution information, thus maximizing the flexibility of applications which use the Handle System as an infrastructure for naming.

The above observations are significant for IoT environments. The basic data types defined by the Handle protocol specification are sufficient enough to describe a large set of communications transactions required by the IoT. However, in various IoT application domains, one may need to define new single or composite types that fully describe the IoT resource or service as a ‘digital entity’ and further apply relational hierarchies, if the IoT digital entities so require. The system provides the technology to store the newly defined types inside structures of the Handle server. This mechanism is crucial in giving IoT applications the ability to abstract their logical components and insert them into a Handle digital object structure.

7.4 Administering Handles – Security Provisions and Implications Conducting Handle administration (i.e., creating, modifying, and deleting individual Handles) requires that you authenticate yourself to the Handle System by proving that you are who you claim to be. To authenticate yourself, you need to have an ID that uniquely identifies you, and since the Handle System is global in nature, your ID must also be globally unique. Since globally unique identifiers are the Handle System’s specialty, it is natural that administrators should be identified by Handles.

An administrator Handle contains either a public key or a secret key (password) that authenticates the individual identified by that Handle. If an administrator Handle is specified with permission to perform some operation in the Handle System, then that administrator can



perform that operation as long as he can authenticate himself against the public or secret key in the administrator Handle.

When you request your own prefix, a prefix will be created that will also serve as the administrator Handle for that prefix, so prefixes (such as 0.NA/11175) serve double-duty as administrator Handles and as prefixes. In this discussion, we will be focusing on the administrator functions of the naming authority Handle.

An administrator Handle can be queried and the values viewed using a Handle client, or by using a proxy. Your public or secret key will be associated with the administrator Handle. When you query the Handle, you will notice that there are several values associated with it. In addition, each Handle value has a unique (within the Handle) numeric index, as well as a type identifier. Some of the Handle values have special meaning within the Handle System:

• Admin Value. Every Handle must have an admin value associated with it. An admin value is of type HS_ADMIN, and specifies the permissions and Handle of the administrator who is allowed to make changes to or delete that Handle. Admin values are values of type HS_ADMIN, and for consistency are being given an index of 100 (The Handle System does not require these particular index values. The index values just need to be unique within the Handle). If there are multiple admin values, then the additional indexes are being given 101, 102, 103, and so on. Admin values specify who can perform administration, by the Handle and value index of either the administrator's authentication, or of an admin group value.

• Public Key Value. If you have a public key associated with the Handle, it will be in a Handle value with type HS_PUBKEY. Public key values for consistency are being given an index of 300 (or 301, 302, 303, etc., if you have multiple keys). It is important to remember the index because you will need to specify it along with your Handle when you authenticate yourself.

• Secret Key Value. If you have a secret key associated with your Handle, it will be in a Handle value with type HS_SECKEY. For consistency, secret key values are being given an index of 300 (or 301, 302, 303, etc. if you have multiple keys). It is important to remember this index because you will need to specify it along with your Handle when asked to authenticate yourself. This Handle value should obviously not be publicly readable, which is why secret key values do not appear in non-authenticated queries for your administrative Handle.

• Group Value. A group value contains a list of Handle values that identify public keys, secret keys, or other groups and is type HS_VLIST. If an admin value specifies a group value as an administrator, then every value in the group is considered an administrator for the Handle.

Handle administration requires an administrator to authenticate himself by providing the following information:

• Your admin Handle. (Your prefix) and the index of your public or secret key value within that Handle.

• Your private or secret key. The private and secret keys do not get sent over the Internet by the Handle System. You only need to provide this to the Handle System client software so that it can prove to any Handle server that you have this information.

In order to create an identifier under a given prefix, the owner of the prefix (the part of the Handle before the slash) must give you permission to create identifiers under that prefix. He can give you permission to create identifiers by adding your admin Handle and the index for your key value to a list of administrators who have permission to create identifiers under that



prefix. When you send the ‘create-handle’ request to the Handle System, you must provide your authentication information. If the server can verify that you are the individual identified by the admin handle (your private key matches your public key, or you enter the correct secret key) then the requested identifier will be created.

7.4.1 Handle security provisions and the IoT

The above descriptions clearly define the access control mechanisms embedded into the Handle Systems, which can be suitable to the IoT. The mechanisms provide a strong framework for authentication and authorisation that can be extended to operate in a M2M environment, involving gateways or end-nodes of an IoT subsystem and the Handle infrastructure (see details in Figure 11).

Where the nodes of an IoT subsystem are involved, further DTLS-based provisions can be applied to create secure end-to-end transactions (noted as green curved arrows). In particular, the CoAP DeviceNet-side access to the Handle infrastructure is not mandated to be secure, therefore, we foresee use of DTLS when CoAP-enabled Handle proxies are used for interaction towards a Handle Service (i.e., from DeviceNets to the ServiceNet and from DeviceNets to the Internet).

Figure 11: Secure end-to-end Handle administration from DeviceNets to the Internet.

7.5 Handle System Scalability Scalability has been a fundamental requirement and design criterion for Handle. It reflects on storage and performance issues. We examine each separately below.

The basic questions to address are whether some limits exist in the number of identifiers that can be added and whether performance decreases with the number of Handles served.

Scalability can be a relatively subjective issue. It may be addressed differently at design stage or at implementation phase. A design that is fundamentally scalable, may exhibit problems with a specific implementation instance.



Furthermore, the use of intermediary services, such as http proxies, may introduce other scalability issues, which the basic Handle System design does not and cannot address.

7.5.1 Storage scalability

The Handle System has been designed at a very basic level as a distributed system; that is, it will run across as many computers and domains as are required to provide the desired functionality.

There are three architectural concepts that have been implemented in Handle to satisfy storage scalability: Handle Servers, Handle Sites and Handle Services.

Figure 12: Logical separation of Handle Service to Servers and Sites

As shown in Figure 12 Handles are held in, and resolved by, Handle servers and the servers are grouped into one or more Handle sites within each Handle service. There are no design limits on the total number of Handle services which constitute the Handle System, there are no design limits on the number of sites which make up each service, and there are no limits on the number of servers which make up each site. Replication by site, within a Handle service, does not require that each site contain the same number of servers; that is, while each site will have the same replicated set of Handles, each site may allocate that set of Handles across a different number of servers. Thus, increased numbers of Handles within a site can be accommodated by adding additional servers, either on the same or additional computers, additional sites can be added to a Handle service at any time, and additional Handle services can be created. Every service must be registered with the Global Handle Registry, but that Handle service can also have as many sites with as many servers as needed.

The result is that the number of identifiers that can be accommodated in the current Handle System is limited only by the number of computers available.



7.5.1.1 Dimensioning storage for IoT applications

The highly scalable implementation of the DOA architecture by the Handle System is of great interest to IoT applications. There are significant benefits we could highlight in IoT6 Use Cases, like the BMS systems. For example, a particular dimensioning of a Buildings Estate to an IT infrastructure that manages it, does not have to be statically dependent on the design decisions made. Say, for example, that the UCL Estate comprised 4 buildings for 4 Faculties. Say that the College grows two-fold within 3 years of operation to 8 buildings for 8 Departments/Faculties. Any BMS system deployed to manage the 4 original facilities would require significant changes to the underlying storage and performance systems to accommodate the growth.

In the Handle case, the administrator of 11175/UCLEstate namespace has a number of design tools in his hands to accommodate the new Estate while maintaining performance. In terms of Handle management, the new Estate would follow the logical structure of the application domain and would only require the creation of new Handles. It also allows the administrator to tune performance by allocating specific sub-Handles to specific services under his control or by delegating control to the appropriate department within the Estate management division.

7.5.1.2 Default database: Berkeley DB

By default the Handle server uses a Berkeley DB Java Edition database to store Handles and Handle values as well as prefixes that are homed to the server. In addition to the above database, a Handle server uses cache.jdb as a temporary Handle cache.

7.5.1.3 Custom storage (SQL, PostgreSQL, Oracle)

Using a SQL database as storage for a Handle server allows greater control over data deposits as well as permitting complex data query.

7.5.2 Performance scalability

Performance of Handle across increasing numbers of identifiers is addressed by hashing, replication, and caching.

7.5.2.1 Hashing

Hashing is used in the Handle System to allocate evenly any number of identifiers across any number of servers within a site, and allows a single computation to determine on which server within a set of servers a given Handle is located, regardless of the number of Handles or the number of servers. Each server within a site is responsible for a subset of Handles managed by that site. Given a specific identifier and knowledge of the Handle service responsible for that identifier, a Handle client selects a site within that Handle service and performs a single computation on the Handle to determine which server within the site contains the Handle. The result of the computation becomes a pointer into a hash table, which is unique to each Handle site and can be thought of as a map of the given site, mapping which Handles belong to which servers. The computation is independent of the number of servers and Handles, and it will not take a client any longer to locate and query the correct server for a Handle within a Handle service that contains billions of Handles and hundreds of servers, than for a Handle service that contains only millions of Handles and only a few servers.



The connection between a given Handle and the responsible Handle service is determined by prefix. Prefix records are maintained by the GHR as Handles, and these Handles are hashed across the GHR sites in the same way that all other Handles are hashed across their respective Handle services. The only hierarchy in Handle System services is the two level distinction between the single GHR and all locals, which means that the worst case resolution would be that a client with no built in or cached knowledge would have to consult the GHR and one local.

7.5.2.2 Replication (mirror server)

Another aspect of Handle System scalability is replication. The individual Handle services within the Handle System each consist of one or more Handle service sites, where each site replicates the complete individual Handle service, at least for the purposes of Handle resolution. Thus, increased demand on a given Handle service can be met with additional sites, and increased demand on a given site can be met with additional servers. This also opens up the option, so far not implemented by any existing client, of optimizing resolution performance by selecting the "best" server from a group of replicated servers.

7.5.2.3 Caching

Caching may also be used to improve performance and reduce the possibility of bottleneck situations in the Handle System, as is the case in many distributed systems. The Handle System data model and protocol design includes a space for cache time-outs and Handle caching servers have been developed and are in use. (See RFC 3651 [13]).

7.5.2.4 Splitting a Handle server

A feature exists where the administrator of a Handle service can split a single Handle server into multiple Handle servers. (This is different from splitting sites consisting of multiple servers, which is a much more complicated process.) The goal of this procedure is to minimise the down time for the primary site. The database splitting process can be performed on a checkpoint/backup of the source database, and then completed using the transaction log of the source database.

7.6 Security aspects In the previous section, we discussed how the architecture ensures how the administration, storage and access of Handles can be secured (Section 7.4). To implement the secure functions, the Handle server uses cryptographic libraries that come with Java v.5 distribution (called Sun Java™ Cryptography Extension and Provider). We revisit and analyse below the key security aspects of the system implementation.

7.6.1 Authentication

The Handle System provides two forms of authentication: public key and secret key. The system can authenticate all administrators of the Handles stored in its database, main and delegated administrators in the hierarchical chain of prefixes and identifiers, allowing for fine-grained control of each structure.



7.6.1.1 Public Key authentication

Public key authentication is performed using the DSA algorithm (key length varies from 512 to 1024 bits, strength can be chosen by the user when generating keys. The default is 1024). To authenticate a client, the Handle System relies on a public key that is stored in a Handle to make it available to the public. The private key is securely stored on the computer with the Handle client that will be authenticated. To prevent unauthorised use of a private key, it can be encrypted using a symmetric algorithm (currently 56 bit DES in Handle Systems).

7.6.1.2 Secret Key authentication

Secret key authentication relies on a secure hashing algorithm, chosen by the client being authenticated (currently either MD5 or SHA1). A secret key consists of a single byte string of size ranging from 0 to 2147483648. This byte string is stored as plain text in a Handle. It is highly advisable to restrict read permissions on the Handle to ensure the secrecy of the secret key. The server functionality allows this with fine-grained permission control over Handles.

7.6.2 Server Certification

Handle clients can request that a Handle server cryptographically certify its messages with its public key. This certification can be used to verify the authenticity of Handle server transmissions. The current implementation of the Handle System uses DSA for this purpose. The DSA public key for a Handle server is stored in its site information record.

7.6.3 Security Services in Handle

There are two important differences, and one similarity, between the security services provided in Handle from those in the DNS (with its DNSSEC extension). Both have the same constraints on entry creation, deletion and replication. Both require strong authorisation with specific administration credentials. Both provide proof of source and integrity. However, Handle has two additional features: session services and access control.

Handle allows a client to establish secure sessions with a server for encrypted communication. This functionality is permitted for example when operating in batch execution mode. This is equivalent to using SSL or TLS (as used by HTTPS), as it affords protection from eavesdropping and man-in-the middle attacks (currently encrypting sessions using 56 bit DES).

Handle also can require credentials to permit access to the contents of the Handle. This feature is very important for IoT, for two reasons. First, the attributes of the Handle may reveal properties of the DO that should be protected information. Second, by requiring fine-grained authorisation to access of the Handle contents, one can greatly simplify the authorisation needs in the IoT processes. No further authorisation is required provided the relevant access is vouched for by the Handle-provided credentials,

7.7 Handle Value Types A Handle has a set of values assigned to it and may be thought of as a record that consists of a group of fields. Each Handle value must have a data type specified in its <type> field that



defines the syntax and semantics of its data, and a unique <index> value that distinguishes it from the other values of the set.

Types are identified by Handles and can be any UTF8-string. Handle System users must take care of potential conflicts introduced by custom Handle clients if users assign types that are not registered and recognised across the global Handle infrastructure.

In IoT applications, one would probably specify a set of data types that are common in the application domain or technology registered in the Handle System serving the IoT domain. For example, a particular building management infrastructure may employ a standardised legacy DeviceNet, such as a KNX or LonWorks set of A/C units. These may come pre-arranged in a networked configuration with proprietary communications (signalling) protocols. Use of such technologies with Handle may be facilitated by defining basic and compound data types that are fundamental to the operation of the legacy DeviceNet, such as LegacyXAddress, LegacyXProtocol, etc.

For interoperability purposes, how types should be defined and how they should be registered and used at global scale should be clearly defined a priori. Table 1 shows the pre-defined types that exist for Handle which have been specified for administrative purposes.

Table 1: Pre-defined Administrative Types

0.TYPE/HS_ADMIN

Values of type HS_ADMIN are encoded representations of the admin record for a Handle. This admin record defines the administrator as well as the permissions that the administrator has over the Handle.

0.TYPE/HS_PUBKEY Values of type HS_PUBKEY contain encoded information describing a public key that can be used to authenticate entities in the Handle System.

0.TYPE/HS_SECKEY Values of type HS_SECKEY are used to store UTF8-encoded text that is used as a password to access some service. Values of type HS_SECKEY should usually not be publicly readable.

0.TYPE/HS_VLIST Values of type HS_VLIST contain a list of Handle value references. Each Handle value reference consists of a Handle and an index of the value being referenced.

0.TYPE/HS_SERV

Values of type HS_SERV contain UTF8-encoded Handles that identify a Handle service (i.e., a set of HS_SITE values). When HS_SERV values are contained in a prefix Handle, resolvers retrieve the service information from the Handle referenced in the HS_SERV value.

0.TYPE/HS_ALIAS

Values of type HS_ALIAS contain a UTF8-encoded Handle. The Handle identified by the HS_ALIAS value should be resolved, and its data should be used in place of the data in the Handle containing the HS_ALIAS value. This redirection should be handled at the application level.



Table 2 shows other common types of Handles that are non-administrative. Combinations of such types are fairly sufficient to define a good subset of IoT resources and services in RESTful environments.

Table 2: Non-administrative Types

0.TYPE/URL Values of type URL are UTF8-encoded URIs that specify the location of the object identified by a Handle.

0.TYPE/EMAIL Values of type EMAIL are UTF8-encoded email addresses.

0.TYPE/DESC Values of type DESC are UTF8-encoded text descriptions of the object identified by the Handle.

0.TYPE/INET_HOST Used to identify a Handle value which has an IP address or host name.

0.TYPE/URN Used to store a value identified as a URN (type not defined or registered)

10320/loc Values of type 10320/loc specify an XML-formatted list of locations

Among the Handle values stored in every prefix are some that directly impact the behaviour of clients, servers, and the proxies. They are described in Table 3.

Table 3: Prefix Handle Values

1 HS_SITE and HS_SERV values

These values determine which LHS a client will use to resolve Handles under a prefix.

2 HS_ADMIN value

An LHS server will use this value to determine which administrators are authorised to create Handles under the prefix.

3 HS_VLIST, HS_PUBKEY, HS_SECKEY values

These values are referenced by HS_ADMIN values and so are used by servers (and clients) for authentication and authorisation. It has become customary to use the prefix Handle itself as the Handle an LHS administrator uses to authenticate.

4 An HS_NAMESPACE value with several subcomponents:

4a Delegation information

Used by clients to determine when derived prefixes should be resolved via delegation.

4b Template Handle information

Used by servers to determine how to configure themselves to respond to Handle resolution requests via template.

4c Status information Used by the proxy when it is unable to resolve a Handle under the prefix.



4d Multiple redirection information

Used by the proxy when it is unable to resolve a Handle under the prefix.

7.8 Template Handles A single template Handle can be created as a base that will allow any number of extensions to that base to be resolved as full Handles, according to a pattern, without each such Handle being individually registered. This would allow, for example, the use of Handles to reference an unlimited number of resources or service endpoints in a building (lights, switches, sockets, etc., as exhibited by sensor measurements, actuation and other operations) without each potential resource or service having to be registered with a separate Handle. If the pattern needs to be changed, e.g., a light bulb moves location or a different kind of server is used to deliver the building’s resources, only the single base Handle needs to be changed to allow an unlimited number of previously constructed extensions to continue to resolve properly.

When a server receives a resolution request for a Handle which is not in its database, it tries to determine if there is template for constructing the Handle values.

This is an extremely powerful feature of the Handle System for constructing logical processing hierarchies of IoT subsystems. In the IoT6 Buildings Management scenario, this means that the logical structure of the building’s managed components can be described algorithmically (and therefore programmatically) by use of XML within a template Handle. This feature empowers the user (building operator/administrator) with minimal system support apart from the basic ancillary functions of Handle management (secure upload of the XML description to the template Handle record, if authentication permits). It also lays a strong foundation in support of Software Defined Buildings.

7.8.1 The Template Delimiter

The way templates work is as follows.

First, the server looks for a template delimiter, which is a string dividing the original Handle into a base and an extension. The delimiter is generally defined in an HS_NAMESPACE value of the prefix Handle 0.NA/<prefix>.

An example: <namespace>

<template delimiter="@" />

</namespace>

If there is no namespace info, the server will use the “namespace” value in the “server_config” section of its config.dct configuration file. If there is no value, or if no template delimiter is defined in the namespace (either from the prefix or the config file) the server will use the “template_delimiter” value in the “server_config” section of config.dct.

If a delimiter is found, the server looks up the base Handle (i.e., the part before the delimiter). For example, in 11175/UCLEstate/EngBldg1@Light1, with delimiter @, the base Handle is 11175/UCLEstate/EngBldg1 and the extension is Light1.

A delimiter of “/” will enable an entire prefix to be templated. In this case the base Handle is considered to have no values.





8 Digital Objects for the IoT In this section we discuss how the DOA primitives, such as the identifiers and digital objects can be used to enable functions of the Internet of Things.

8.1 Use of the Handle System in the IoT There are many aspects of the HS architecture, which make it an excellent fit for IoT – though its application in this domain has been limited so far. The syntax is sufficiently rich that it is possible to define the DOs that represent sensors or actuators. These can be stored in different searchable repositories. Access control can be fine-grained. Moreover, since the access control, and hence authorisation, can be external to any gateways this allows much more sophisticated authorisation without over-loading any gateways.

The DOs may refer also to processes and/or services. Thus they may refer to the transformations to be applied in translating a technology-independent operation like reading a set of sensors or setting a set of actuators. For example, there may be defined a particular object type to represent KNX or Cisco Energywise transformations.

The way that prefixes are defined implies that composite DOs may be used in one set of applications and their constituent parts in another. For example in a Smart City application, there may be a DOI for the building as a whole. For ABM purposes, it will consist of a whole hierarchy of DOs with their own DOIs – with only differing prefixes. Thus, for example, there may be a DOI to describe all the lights in a building. There may be a further set of DOIs for the set of lights on each floor. There may then be a further set of DOIs to refer to all the lights in each room. Finally, there may need to be a DOI for each light separately, in order to identify it for control and monitoring purposes.

One type of DO attribute is a Domain Name. The Handle Resolver can operate as an alternative to the DNS. As stated earlier, it is quite feasible to describe a (composite) DO as a set of (single type) DOs, and then to associate an IPv6 address with the set. This will allow operations to be defined on the set of DOs. Whether the operation is really achievable in a group manner is very technology dependent. For example, if all lights were IPv6 enabled, they could each be associated with an IPv6 address. It would also be possible to associate a specific multicast address (m/c address) to all the lights on a floor, and yet another to all the lights in a building. All the devices in a room could be associated with another IPv6 m/c address. Thus it is possible to define DOs and their properties symbolically, and then to do different operations on different composite DOs. It may be that the group operations can be carried out as a single operation – as for example on a single m/c address. It may also require a different complex technology-dependent process for each member of the set. For example, a legacy technology may not support the equivalent concept of multicasting (or group communications). In this case, the technology-dependent gateway may be architected in a way to support multicast-to-unicast bridging operations.

Although at first sight it would seem that an ABM operator would require access to all DOs in a building, this may not be the case. For example, only an ABM operator may need to adjust an air-conditioning (A/C) unit in normal operation. However, if a fault develops in the A/C unit, it may be only the service engineer who needs to access the DOs which represent the A/C unit. Similarly, a fire department might be authorised to access quite a different set of actuators in an emergency, which was much broader than an individual ABM operator. Thus the authentication/authorisation applications could be very complex.



In IoT, unlike in the conventional Internet, the considerations are quite different. Here the nature of the end-devices is very varied. Indeed the early IoT activities considered only the devices as “things”, and most of the activity revolved around the naming of the things, classifying them and storing their descriptors as part of RFID. It was soon realised that dealing with such devices also required symbolic identification, and many different sorts of repositories have been defined and implemented in IoT work. Incidentally, the Chinese are using the HS architecture for tracking food production. Here aspects of meat and liquid changes during the production process, and thus RFID identifiers are added as the food is processed. The variable length prefix of the HS architecture is very important in this application.

8.2 Gateways and Functional Separation We have stated earlier in this document that there has been a move to put Internet interfaces on legacy controllers that allow operations previously done locally to be done remotely. This requires minimal changes to the controllers, and is therefore popular with suppliers. The end operators, be they people or processes, would often like to be spared knowledge of the technology-dependent operations. In addition, the legacy technologies do not use IP internally; therefore any remote end-to-end operation would have to be handled by a gateway to the controller. For this reason, there have been many attempts to put such translation activities into the gateways. This has been done in IoT6. While such an approach is technically feasible, it is much more difficult to obtain supplier or user acceptance. This is because it is usually impractical to completely replace the controller; suppliers have usually incorporated undocumented smarts into the product. Certainly in the ABM arena, there is a reluctance to deploy systems in which people other than the suppliers have made substantial changes. It would probably be preferable to leave a legacy controller virtually unchanged, and to put the technology-dependent operations into another server – possibly in a cloud close to the target gateway. This concept is clearly shown in Figure 13.

Figure 13: Functional separation of gateways to processes

Here, various functions needed by an IoT application (IoT6: Use Case of the Buildings Management) have been split into independent processes running on different clusters. With the current IoT6 architecture the approach is to include services like GLoWBAL (including the IPv6 Addressing Proxy), a CoAP-HTTP proxy, etc. on the DeviceNet gateway. In T2.4,



we enhance this view by re-locating these services out of the gateway. Hence, one can provide multicast-to-unicast and IPv4-to-IPv6 translation services, for example, or even mobility home agents, or CoAP-to-HTTP proxies, running as processes in separate server clusters. (The colours correspond to the protocol stack layer where the services operate.)

The use of the HS in this case can be advantageous. The HS can implement mechanisms that can obtain where such processes are running, and provide a security token to allow it to be provided. In fact, the resolver itself and the repository (see Section 8.3 below) are independent processes. Their communication is warranted by the DO architecture and associated protocols.

8.3 DO Registration The DOA architecture has facilities for DO registration. We refer to digital object registration as the process of creating a Handle record for the particular object based on its identifier.

Registration can be done into a specialised component of the DOA architecture called the Registry. However, object registration is considered a vital operation of the DOA architecture so that other components of the DOA support it. Registration can be done into the HS itself. In the rest of the document we will assume that registration is executed in the HS but we may refer to this functional component of the HS as the Registry.

The registration operation can, and should, be securely put into the Registry. Any devices could be put into the registry on installation. For certain types of devices, they can do auto-configuration of their network interfaces. In that case an ancillary operation is required to put the entry securely into the HS registry. It is also possible to send blanket queries to all the sensors, and request certain readings. From an analysis of those which reply, one can at any time make a note of how many are currently functioning.

In almost all application domains, there is some model of the physical world and a correspondence with devices such as actuators and sensors. We assume that there is such a model, and that the Handle of a DO is linked at, or after, installation to a database for each device (interface). In the early forms of IPv6 stateless address auto-configuration (SLAAC) [6], each network interface that was associated with an IPv6 address would form that address as a concatenation of the location (network prefix) and the EUI-64 address (derived by the MAC address). Such a policy, although not formally deprecated, is less preferred because of the loss of privacy it caused. This loss of privacy is due mainly to the fact that the MAC address is uniquely assigned to the host manufacturer (as a MAC prefix) and subsequently to the interface (as the MAC suffix) and that is readily searched. However, if we use a database for storing devices (interface state descriptions), their attributes and IPv6 addresses, and have access control on the access both to that database and to the Handle Name Resolver, this problem is largely removed.

Both in the way some enterprises assign IP addresses to interfaces/devices and in the GLoWBAL system, this address is formed algorithmically with the above dangers. If one is still worried about exposing the details of a configuration through study of the database, then any IPv6 address can be formed from hashing the appropriate bits of the address. This removes the information that can be derived from the address because these are just stored in a secure database.

For security reasons, each device should store its Handle in the device. If asked to provide data, like a sensor, it should append this Handle securely to the sensor reading to provide authentication. If this mechanism is followed, we also have a mechanism for dealing with auto-configuration. If a device comes on-line with auto-configuration, it can be given an arbitrary IPv6 address as part of the SLAAC-like auto-configuration mechanism – which uses



local multicast. The device should then register this address securely in the database under that Handle identifier. This ensures that it can be accessed subsequently.

8.3.1 Auto-configuration of IoT services and resources using Handle

According to the definition of DO registration provided in the previous paragraph, we now refine the term “auto-configuration of DOs” in the context of IoT using the Handle System.

Auto-configuration of DOs can now be expressed as the function of self-registration of objects into the Resolver (Handle System) in the sense that a given set of DOs can automatically receive Handles and have them registered.

HS supports this operation, since all DOs are assumed to have unique persistent identifiers, and, in most cases, some person or process has created the identifier string that is registered in the HS; the Handle record typically includes the relevant metadata (such as current location(s)), to create the resolvable Handle. This is the normal case in which the HS itself simply accepts any valid string (UTF-8, no length restrictions) from an authenticated and authorised source and creates the Handle. The sources (‘things’, sensors, processes, services) can use any method to create the string, e.g., by prefacing or transforming some existing id scheme such as ISBN or by creating a random string, or a cryptographic string. They are all just opaque strings to the resolution system. Handle protocols clients could use any approach to creating a string based on the object itself, e.g., a hash value. The wisdom of this would vary by case. Creating an identifier based on the hash of an object, for example, would be misleading for objects that are subject to change.

We saw in Section 7.8 that there is a class of DOs, for which a special approach is used – namely the use of template Handles. A template Handle can be created as a base entry that will allow any number of extensions to that base entry to be resolved as if they were actually registered as full Handles, according to a pattern, without each such Handle actually being individually registered. This would allow, for example, the use of Handles to reference an unlimited number of resources or service endpoints in a building (lights, switches, sockets, etc., as exhibited by sensor measurements, actuation and other operations) without each potential resource or service having to be registered with a separate Handle. If the pattern needs to be changed, e.g., a light bulb moves location or a different kind of server is used to deliver the building’s resources, only the single base Handle needs to be changed to allow an unlimited number of previously constructed extensions to continue to resolve properly. In this sense, we have auto-configuration for a set of DOs based on a pattern specific to the set. It is probable that the power of the Handle System will permit the provision of many services that would be important for IoT. For example, in the case of certain failures, it may be possible to recover new configuration information to provide self-healing services.



9 The Operations in Automated Building Management 9.1 Introduction We will now step back a bit, and consider what needs to be done in IoT for Automated Building Management (ABM). We will describe the process in a fairly generic way, with the aim of being specific enough to draw particular models and conclusions, and yet be generic enough to later extend the thinking to other domains. We will first give a fairly generic description of the sort of things one might wish to do, and then give some specific examples. We will tie the processes to the actions of a Buildings Manager (BM), and have all responses returned to him/her (for brevity we will state him). We fully realise that in reality many of the operations will be autonomous, with the information passing only to a specific level of a hierarchy. However, for simplicity it is simpler to assume only one level. For the same reason, we will greatly simplify the number of processes that are involved.

The ABM operator will have some high-level functions that are required. These will be things like:

1. Maintain each room in which there are people at 22oC 2. Open door X to an authorised person, but note where they are 3. Check whether any rooms on the fifth floor have temperature exceeding 30o C 4. Check whether there are any unauthorised people in the building on the 5th floor 5. Do all temperature sensors work

Each of these will probably need to be implemented as a set of more elementary operations. Thus if we consider Sensing and Actuation as a Service (SAaaS), we may have the elementary operations:

• Read (PresenceSensor, Address, Credential) • Read (TemperatureSensor, Address, Credential) • Set (DoorSensor, Address, Credential) • Set (HVAC, Temperature, Credential)

At the level of the ABM operator, these operations are in his type of vocabulary; they do not incorporate any of the technology of the devices.

9.2 SAaaS Operations The next step must be to associate an identifier with the Address. All devices are dealt with in the context of their identifier(s). We refer to these identifiers generically as Handles, given we are employing the HS architecture. It is important to note that there may be multiple Handles associated with a DO. Thus, for example, a specific sensor may have one Handle; all the sensors on the fourth floor may be a second; all sensors in a building may be a third. In this case, the three Handles may differ only in the length of their identifier. The specific sensor may be associated with an IPv6 address, while the groups may be associated with two different multicast (m/c) addresses.

There must be a mechanism for finding the Handle for a device. This may be because enough is known about it to find it in a database; searching for a CO2 sensor in a particular room may reveal the Handle. It may be associated with a picture in a GUI; often the displays of building management systems show each room. It may be an attribute in a measurement database –



e.g. a database may store the temperatures of each sensor (together with their Handle); a search on temperature exceeding X might return all the Handles with that property. There must be a database associated with the Handles themselves. The CNRI release of the HS supports a particular type of database (Berkeley DB Java Edition). However, there is the facility to use any relational database by providing the relevant java class interface (Oracle, MySQL, PostgreSQL, etc.), and one could be the MongoDB used by Digcovery, as adopted in the rest of IoT6. In the simplest form of integration one can assume that Handle records could be stored in the appropriate (homogenised) format to Digcovery. However, this topic needs much more reflection due to the versatility of the HS object format as well as the generic nature of the DOA objects.

The next operation Read (Handle, Credential) is simply resolved. The data associated with the Handle immediately decides whether the access to that Handle for Read() purposes is authorised. If it is so authorised, the information on the technology of the sensor and its address information in the form understood by the SAaaS process for that technology will be passed to a specific process in the ServiceNet with a CoAP GET command and the authorisation credential from the Handle server. This process will then form the exact stream required by this specific sensor controller, and passed again with the Handle Server credential to a CoAP interface on the controller to execute the GET. All these CoAP operations will use DTLS standardised for use with CoAP – if security is required. The reading will be returned from the sensor with the sensor Handle – signed with its private key.

Obviously similar operations can be done with CoAP POST/PUT operations (Write commands) for actuation.

9.3 DO Registration Clearly DO Registration is a key activity, and must be done securely. At the least, it involves two sets of operation. The DO of any device, with all its relevant attributes including credentials, must be set in the Handle Server. This must be done, of course, by a process that is itself authorised to enter data. Secondly, enough attributes of the Device must be stored in the searchable database to allow the operator to identify the Handle. A single DO may be part of several registrations – a sensor in a particular form; one of all the sensors on a floor; one of all the sensors in a building. Each registration may be associated with a different network address.

IPv6 has the property of permitting stateless address auto-configuration (SLAAC [6]). However, such auto-configuration is not adequate by itself for the present purpose. The process will cause the automatic generation of an IPv6 address, but will not provide any of the data or metadata needed to store it in a Handle database or device database.

9.4 Compound Operations There are several types of compound operations; indeed this class is very domain specific. One class makes use of the specific syntax of IPv6.

By registering several addresses, including m/c ones, one can request compound operations. One might request all the sensors on a particular floor; another all the sensors in a building. One reason for carrying out this type of operation is to simplify the request. Another is to determine the health of the equipment. If one has a database of all the sensors that should exist associated with an m/c address, and try to read the relevant readings, one can compare the readings returned with those that should exist and thus determine which are not operational. Of course whether a compound operation like this remains a single operation, or



becomes decomposed into a number of simpler ones is dependent on the technology used in the controller systems. The legacy-specific translation process will take care of this problem without bothering an ABM operator.

Another form of compound operation is “identify all rooms with a temperature above 30o C”. Here there may be a Read generated to many sensors and then an analysis of the results. It may also be that there is monitoring taking place continually, and this only requires sorting of the results of previous measurements.

Yet another form is to have certain requirements in a particular location that are equipped just with identical devices. For example, if someone is going to be coming to a particular room it may be necessary to carry out several operations:

• Check he/she is authorised to enter the room • Put on the lights • Activate a Presence Sensor • Put the heating up to a specific temperature • Etc.

Here it may have been necessary to register a Handle with all the devices in a room.

9.5 Re-Use of past IoT6 work In T2.1 – T2.3, and in D3.1 – T3.3, we have already been discussing various abstractions. On one hand, WP2 work included the GLoWBAL-IPv6 protocol and the IPv6 addressing proxy. On the other hand, WP3 catered for a very thorough provision of a service layer. This service layer was called the Digcovery System, and consists of many components. We examine below how the extended work of T2.4 links into each of these past activities.

9.5.1 The GLoWBAL-IPv6 protocol and object identifiers

We have seen how the GLoWBAL-IPv6 protocol operates in the application layer as a ‘session controller’ to provide IPv6 address bindings for devices unable to run an IP stack natively (‘legacies’ by design). GLoWBAL-IPv6 achieved this by using an alternative 4-byte identifier, the prefix of which would be pre-defined for a variety of legacy technologies. The objective was to enable the flow of information between a source node outside a gateway (in ServiceNet or Internet) and a 6LoWPAN device (in DeviceNet). Since resources in the gateway are limited, the tables formed included a time-to live of each entry (i.e., of each identifier mapped to global IPv6 addresses). An evaluation of the scalability of the system was given with specific examples of X10, BACnet and KNX nodes.

The IPv6 addressing proxy defined the mechanisms for automatic mapping of IPv6 addresses, as used in IoT6, and the three different legacy technologies used in the evaluation. Here one also evaluated the difference between using a different daemon for each technology, and sharing one for all the technologies. In the evaluation, it was shown that with a common daemon, the time taken to do the mapping in a specific Linux gateway varied between 25 milliseconds and 30 milliseconds for the different technologies. By using separate daemons, this could be cut by 50% - 60%.

We re-evaluate here the design approach of the GLoWBAL-IPv6 protocol. While the protocol can serve a wide base of disparate devices with IPv6 addresses, it is rigid by design when stipulating only the mapping of global IPv6 addresses. In the following, we consider whether a complete complementary approach might have advantages. In most of the previous IoT6 work the individual sensors and actuators have been associated with global IPv6 address. It



was realised that a key requirement was to associate the device with its resources in a repository, and that a globally distributed name resolution system was needed. Many have considered that one should differentiate between the name and the location of a node. While this differentiation is difficult with the limited address space of IPv4, it becomes more achievable with IPv6. We postulated further that all entities, whether IP addressable or otherwise, should be associated with a name. By suitable hierarchic structure of the name, one could route to it in the name space just as the DNS can be used to devise routes in the address space. This idea encompasses the design principles of DO system architectures.

For truly universal IoT interoperability, we propose the generalisation of the GLoWBAL-IPv6 protocol to names. Handles of objects residing in the Internet or in ServiceNets map to Handles assigned to legacy systems living in DeviceNets, thus bridging the namespaces associated with each domain. With this approach, what has previously been an addressing problem now becomes a namespace problem. The details of how to link the identifiers of the IPv6 address space to the names of the name space is application specific. It is assumed that new data types will have to be defined for the various namespaces of the DOs. For example, in building automation, it might be desirable to establish data type definitions for the various entities one encounters in the legacy technologies (the attributes and properties of a LonWorks HVAC node, the attributes and properties of an IP-enabled KNX gateway, etc.) We provide below different incarnations of this problem.

9.5.1.1 Examples of a generalised GLoWBAL in IoT

Case 1: A new construction utilises LED light technology. Currently, the market supplies consumers with LED bulbs. A cluster of such LED lights can be specified, named and identified by the building operator, for common operations that apply to the cluster (e.g. set combined intensity). This is an example highlighting the requirement to address a DO structure higher in the object hierarchy.

Case 2: The same construction utilises BACnet connected HVACs. Each HVAC offers fine-tuning of its functional parts, like setting of the heat temperature, fan intensity, grilles positioning, water pressure setting, etc. While the HVAC could possibly receive an IP address in an IoT application, there is a requirement to address parts deeper into the hierarchy of its DO structure.

Case 3: A utility supplier has access to the smart energy meter they installed at premises X. Multiple addresses exist for this energy meter. Access to the meter by the utility company is achieved by use of the 3G/4G wireless infrastructure in the neighbourhood or by the utility’s own PLC network. For this access the egress address of the meter is E. The energy consumer accesses the meter over his LAN. The ingress address of the meter is I. Access of the utility company’s network by the consumer is prohibited (no I => E route exists). Access of the consumer’s home LAN by the utility is also prohibited (no E => I route exists). It may so be configured that E and I belong to completely different name spaces (or technologies) and would thus require a router or gateway between them.

In cases 1-2 above, we note that rigid mappings between identifiers and IPv6 addresses, as stipulated by GLoWBAL-IPv6 may not be adequate to access the functional components of a composite object. Furthermore, the use of names is better suited to describe the sub-components, which may not be addressable (in IP terms) individually. In addition, one might want to assign multiple names to a single composite object, and use each name for different types of access to the object. Furthermore, one may want to group multiple attributes of an object under a different name/Handle and map the group of attributes to a multicast IPv6 address for efficiency. In the example of Case 3, we note that GLoWBAL is disadvantaged by



its rigid mapping of technologies to IPv6 addresses. The energy meter example shows that either we want no addresses at all or we may want multiple addresses for the same interface/host. Furthermore, mappings or other associations may lead to NATs (address translations as in IP network systems). These are better provided by names which resolve to specific addresses of various applications.

The equivalent concept of the “IPv6 addressing proxy” of WP2 can then be further generalised to include this paradigm.

9.5.2 The Digcovery system and operations with object identifiers

The core system consists of a Digcovery Service Discovery set of modules, a Search Engine and a Client Interface. The system is powerful, and has been shown to meet many of the IoT needs. The system realised the need for global registration of resources, and based that part of the system on the DNS and associated technologies like mDNS and DNS-SD. The IoT application domain may require sophisticated security facilities – particularly for authorisation. The Digcovery system has gone to some trouble to allow limited authentication of clients with a secret key (password). The reason for most of the limitations is that it is based on the use of the DNS, and makes very heavy use of IPv6 addresses – which is the logical property to be provided by a DNS – even if extended. Digcovery uses the DNS because of its global reach and managed DNS service.

The two previous examples (Case 1 and Case 2 of Section 9.5.1.1) also show that some of the search activities that can be performed on things of IoT6 stored in a Digcovery structure can be optimised. By defining new types for each legacy technology and considering routing of information based on names rather than IPv6 addresses, the expensive search operation (of a database) goes under major transformation to become efficient addressing.

9.5.3 Comparison of Handle System to the DNS system for IoT purposes

The DNS, originally designed and used for mapping domain names into IP addresses for network routing purposes, is one of a number of existing Internet identifier services or specifications that provide some of the functionalities of the Handle System. It is also the one to which the Handle System is most frequently compared. However, there are similarities and differences in both the design and intended use of the two systems. We list below some of the key areas to highlight the superior architecture of Handle when compared to the DNS, particularly with IoT applications in mind. This comparison also serves as a guide when comparing to other DNS-derived or DNS-like architectures.

9.5.3.1 Naming

The DNS naming hierarchy reflects a control hierarchy. That is, whoever runs the .com top-level domain controls who runs company.com and whoever controls company.com controls who runs site.company.com, etc.

This is not necessarily true of the Handle System. Any prefix can be, and at the moment all are, at the same level. So administration of 11175/UCLEstate/EngBldg1 can be completely separate from 11175/UCLEstate/EngBldg2 which can be completely separate from 11175/UCLEstate and so on. They can all live in root and all be controlled by different sets of administrators and all point to different Handle services (scalability).

The naming hierarchy can be used in Handle permissions to create new prefixes. That is, prefix 11175/UCLEstate can be set up to give the administrators of 11175/UCLEstate permission on the Global Handle Service to create new prefixes that begin 11175/UCLEstate,



e.g., 11175/UCLEstate/EngBld1, 11175/UCLEstate/EngBldg2, but not the ability to create new prefixes that start with 11175.

9.5.3.2 Distributed Administration

Each identifier and prefix can have its own set of administrators independent from the system administrator. Handle administrators can add/delete identifier and identifier values via the Handle system protocol securely over the public Internet. DNS systems may have ad hoc mechanisms for updating records, but there is a difference in perspective on data ownership. In DNS, the system administrator is generally considered the owner of the data, while in the Handle System the prefix administrator is considered the owner. In cases where there are many users creating data, with only a few servers, having prefix-level data ownership is desirable. Having a consistent administration protocol also makes it easier to develop programs for creating and modifying data, independent of any particular server implementation.

The above distinction is very favourable to IoT applications, where data ownership remains to the IoT main actors (machines, or humans). This relationship further eases dynamic re-configuration of the IoT application according to the user’s needs and is not tied down to the naming system infrastructure.

9.5.3.3 Proxies

Making DNS resolution work behind SOCKS proxies may be difficult, depending on the DNS library used. The Handle library supports SOCKS proxies. Making DNS resolution work from behind HTTP proxies is probably impossible. The Handle library supports HTTP proxies.

9.5.3.4 Unicode

The Handle System is 8-bit clean, therefore, full Unicode is supported. There are hacks to make DNS support 8-bit character sets, but they are not widely implemented.

With this in mind, the Handle System is ready to support localisation of IoT applications without additional engineering effort injected into the infrastructure. For example, the semantics of the English language Handle ‘11175/UCLEstate/EngBldg1/Lights’ can be mapped via a Handle alias to the ‘11175/UCLEstate/EngBldg1/Φωτισμός’ to support the Greek version of the same BMS system, if required.

9.5.3.5 Replication

Mirroring in the Handle System has fine granularity. If a single record is updated, the server will copy only that record to the mirror servers. In DNS, if a single record is updated, the entire zone is invalidated, and all records must be copied to mirror servers.

In IoT environments this may lead to unnecessary latencies beyond the control of the IoT application, often experienced as service outages or mishaps.

9.5.3.6 Certification

DNS has to be fast, especially at the root. This makes it tend toward policies that are not very good for alternative uses. For example, certificates are not as robust as in the Handle System, because a design constraint of DNS-SEC was that all signatures had to be pre-generated.



DNS-SEC also depends on X.509, which may or may not be desirable. Finally, DNS-SEC may not be present in all DNS implementations.

The Handle System has more flexible and robust certification support. It caters for better certificate management and can support certification options per Handle, which is a desirable feature for the IoT.

9.5.3.7 Access Control

The Handle System has support for access control and authentication. DNS does not.

Any system relying on DNS for access control and authentication will require custom implementation of such operations. This is evident in Digcovery, for example, where authentication has been provided in custom form.

9.5.3.8 Record Size

The DNS protocol defaults to UDP, but if a record is greater than 512 bytes, the server returns an error requiring the client to resend the request over TCP, making for two round trips. This may be at odds with IoT devices striving to maintain low energy footprint and short duty-cycles (particularly those IP-enabled ones, which are permitted to be accessible end-to-end). If you are storing a great deal of metadata, this accounts for two round-trips for every message. If you are storing extremely large amounts of data, DNS has a 64K limit, while the Handle System has a limit closer to 4G.

The Handle protocol supports UDP chunking, so larger responses are possible over UDP. The Handle library also makes it possible to exclusively use TCP, eliminating the issue altogether. Some DNS libraries may also allow forced TCP, but at the cost of losing the speed of UDP. A lot of DNS servers do not support TCP at all, and if your organisation’s DNS servers don’t, you will end up losing the DNS hierarchy and put a greater burden on the primary servers and the global DNS roots. Some more draconian ISPs do not allow users to bypass their DNS. If these ISPs do not support TCP-DNS, there is no way to resolve DNS records larger than 512 bytes. This limitation can be catastrophic in IoT environments.

9.6 Advantages of using Handle in a IoT integration approach 9.6.1 Global secure service

Using the global Handle infrastructure still gives us all the advantages of a managed global service, with the added advantage of being able to incorporate sophisticated security services, with the granularity that may be required in this application domain.

We believe it will be possible to use the vast majority of the Digcovery system, but with the Handle System in the core. Here we indicate both the architecture and the security provisions that now become straightforward to provide.

Most of the identification and property processing of the current Digcovery parameters is based on use of IPv6 addresses. Even with the Handle System there is an eventual need for Internet IPv6 addresses; however by having a more abstract (albeit advanced) view of identifiers in the form of Handles, a more general position can be taken – though part of the Handle System for IoT use may well turn out to be a set of IP addresses. Here we can use the IPv6 property that a DO could have several IPv6 addresses associated with the DO.

9.6.2 Novel business process description



The business processes put in place by the building service operator is one area where an IoT application can provide improvements on. For example, the business process of identifying the mobility pattern of a particular guest could be described as “Show All Doors Opened by Person X between 10-11am”. The relevant sensors could be read and co-related (for proximity) with the guest’s access card trail. The business process of the fire brigade, if called in the building in an emergency are described differently. A process here could be defined as the action “Close all doors” to contain a fire.

The different views of various business processes can be accommodated by translating the processes into Handles and registering those Handles instead.



10 Programmability The rich features of the Handle Architecture can be exploited programmatically, using a number of programming interfaces and libraries. The system has been evolving in the Java domain with RESTful environments in mind, thus further easing implementation efforts with existing components, standards and architectures of the IoT at large. Below we provide an overview of the most relevant programmatic aspects of Handle that we are using in IoT6 task T2.4.

10.1 Clients and the client library Communicating with the Handle System is accomplished by sending requests to servers which then return a response. For example, to resolve a Handle, a ResolutionRequest is sent to a server. To create a Handle, a CreateHandleRequest is sent. To modify, remove, or add values to (or from) a Handle, a ModifyValueRequest, RemoveValueRequest, or AddValueRequest is sent to a server.

There is an object for each of these requests in the net.Handle.hdllib java package. One way to send these messages to a server is to use a HandleResolver object which is located in the net.Handle.hdllib package. For most messages, the HandleResolver object will locate the server that your messages should go to, send them, and return the response that was sent by the server.

The HANDLE.NET software distribution includes simple command line tools to create, delete, and list Handles. It also includes programs to home a prefix and trace Handle resolution. These programs provide a good starting point and simple guide to developing Java-based custom Handle client software with the API. Each example program includes steps needed to form a Handle request to send to a Handle server. The programs are run from the command line and require certain arguments. The following examples should be run from the directory containing the "bin" directory.

10.2 Batch Processing Instead of using the administration tools, Handle can support operations which can be input as a text file or by hand via the command line. In those cases it is best to use the batch facilities included with the HANDLE.NET software distribution.

All batch files are plain text format. One batch file can have more than one Handle operation. The Handle operations are: Create Handle, Delete Handle, Home/Unhome Prefix, Add Handle Value, Remove Handle Value, Modify Handle Value, Authenticate User, Setup Session.

10.3 HTTP Proxy (REST API) CNRI supports a Handle proxy server system called HDL.NET. This is a collection of servers which speak the Handle protocol and can contact any Handle server with queries.

While this is a desirable feature for some applications, it is noted that the proxies ignore some Handle data that cannot be understood by a standard web browser (like location of enhanced metadata or related objects).



Apart from the proxies, a REST API interface has been deployed experimentally on the server too, and is part of the next major Release (v8). In a way similar to the client issuing an HTTP GET to the proxy, one will now be able to issue the same operation directly to the server, which will in turn yield a direct GET response to the client with the full features of Handle. The format of such a response from the server (and proxy) is JSON.

10.4 IPv6, REST and Secure access There have been two recent improvements arising directly from our discussions with CNRI.

First, the whole system can now be accessed over IPv6 networks. The full reasoning and implementation details of IPv6 in the Handle System, and in the DOA systems in general, is not the main focus of this deliverable. It is worth stressing here though that dual-stack operation was not previously possible on such systems, whereas now a comprehensive implementation has been provided.

Second, the next release of the server (v8, expected around 2014 Q2) will also incorporate a REST interface, making it simpler to use the Handle resolver system in an IoT infrastructure with applications using CoAP-based web services. In fact, since CoAP can use DTLS, and Handle has the strong security infrastructure, we can ensure a process is indeed both the correct process, and will permit only authorised requestors to transform the request. (A TLS/DTLS feature set has been scheduled in the Handle System for the subsequent release, beyond v8).

These developments are a significant advancement for the use of DO architectures in the IoT. As we previously indicated in Sections 8.2 and 9.2 and later shown in Figure 13, building TLS/DTLS capabilities within a Resolver system brings it inline with the IoT6 vision of secure end-to-end Man2M and M2M communication based on IPv6.

Figure 14: Direct linkage of DOA systems with the IoT

We further postulate that the integration would be further facilitated by CoAP-HTTP proxies which can be co-located with Handle resolution modules. In fact, the IoT6 implementation of T2.4 is exactly that; a back-to-back CoAP-HTTP module and a Handle client. This aspect of the systems architecture is also shown in the above figure.



10.5 Links with the Digcovery System In fact when one analyses in detail how to implement the features required, one quickly realises that almost all the features of Digcovery are still valid. Again the choice of repository may have almost identical considerations as in the Digcovery system. The main difference is that the core system must be based on the Handle System, with its more sophisticated from of Handle Resolution that that of the Name Resolution of the DNS. The Handle attributes stored in the Databases may be different, but similar search and registration operations must be performed.

We have analysed the differences between how Digcovery works and how one based on Ha-ndle work. Exactly how much of the Digcovery System would need modification, if this is of any interest, has not been analysed fully yet. Note that the current HANDLE.NET s/w v7.3.1 includes a DNS interface to translate DNS resolution requests to Handle resolution requests. This includes support for translating DNS names to Handles, including decoding Internationalised Domain Names. Given the comprehensive and secure operations offered by a DO structure based on a HS infrastructure raises the question of what extent this is a useful IoT6 activity to pursue.

10.6 Interfacing legacy ABM Systems In the work to date, there have been processes in the gateway systems which process the data streams into the forms required by various legacy systems. We believe that these procedures can be largely taken out of the gateways, and used in the Servers. This aspect is not yet demonstrated, and will require further study.



11 Conclusions The sort of conclusions that can be drawn from the first part of this Deliverable are radically different from those of the second. In evaluating 6LoWPAN, we stated that the Contiki implementation had most of the desired features in a sensor system. The GLoWBAL implementation mentioned also that this provided an identifier - a wording significant for the second part of this Deliverable. The performance of a particular implementation for linking a sensor operation to ID mapping was measured, and found to be of the order 20ms. For each technology tried in the addressing proxy, it was shown that one can express in an IPv6 address portion of header the relevant parameters for the characteristics needed by a sensor in that technology in the IoT6 Use Case context. The translation time was of the order of 20ms. It was very desirable to run multiple daemons in an application gateway – one per technology; the resulting translation process then varied between 15-23 milliseconds.

Although the activity of GLoWBAL mentioned identifiers, it expressed all its features as part of an IPv6 address – which always has a connection to location. Moreover the functions that could be carried out were limited by the heavy use of the DNS in the storage and processing of this identifier. In the second half of the Deliverable, we showed how this notion of identifier could be considerably extended by divorcing it from an address, and considering it as referring to a Digital Object (DO) with a range of parameters. These parameters could still include various measures of location, but could have a much more general syntax and semantics. Moreover, a physical object like a sensor could be associated with multiple DOs, depending on the context, group operation and detail needed. Because the DO was no longer constrained by the DNS, more sophisticated security operations could be applied to the Name Resolution. Even if a physical device was associated with only an IPv6 address, the IPv6 structure could assign it several addresses without violating the IPv6 routing principles. However, the automatic processing of the attributes made the associating different IPv6 addresses with the same device difficult.

We found that a particular implementation of a DO processing system, the Handle System had many components ideally suited to IoT. We described the system and its properties in considerable detail, and showed why some properties were so suitable. When we first examined the system at the start of T2.4, it had two principal disadvantages for IoT6: it was not properly IPv6-enabled, and had no REST interfaces. After some discussions with CNRI, who had developed it, even these two aspects were remedied. We then showed how, at least in principle, it could meet the needs of IoT that we had identified, and certainly those of the IoT6 Use Cases.

Another activity in the second half of this Deliverable was to consider the decomposition of a gateway from a monolithic one to a distributed one. We postulated and justified, but did not implement, the reasons for this. Such a design would require distributed processing; here the features of the HS which allowed the address of modules providing computing processing (with relevant parameters) and the provision of CoAP/REST interface to the Name Resolver, would allow these processes to be migrated at will. The availability of Security Parameters associated with the Handles, allowed also fine-grained access control and authorization to be exercised. For the IoT6 Use Cases, the actual processes required should, in principle, be derivable directly from those of the other WPs.

The concepts outlined in the above still require validation. This is, however, a fitting subject for WP7 and will be pursued there.



12 References

[1] J. Hui, and P. Thubert. “Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Network”. IETF 6LoWPAN Working Group, RFC6282, 2011.

[2] Contiki: The Open Source OS for the Internet of Things, http://www.contiki-os.org/ [3] RFC4944, Transmission of IPv6 Packets over IEEE 802.15.4 Networks,

http://tools.ietf.org/html/rfc4944 [4] Interoperability Test for 6LoWPAN, http://tools.ietf.org/html/draft-hui-6lowpan-interop-

00 [5] Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks, RFC6282,

http://tools.ietf.org/html/rfc6282 [6] T. Narten, and T. Jinmei, “IPv6 Stateless Address Auto-configuration”, IETF Network

Working Group, RFC4862, 2007. [7] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP

version 6 (IPv6)", RFC4861, September 2007. [8] Data Sheet: JN5139 IEEE802.15.4/ZigBee Module Family,

http://www.jennic.com/files/support_files/JN-DS-JN5139MO-1v6.pdf [9] Jara, Antonio J., Miguel A. Zamora, and Antonio Skarmeta. "GLoWBAL IP: An adaptive

and transparent IPv6 integration in the Internet of Things." Mobile Information Systems 8, no. 3 (2012): 177-197.

[10] A.J. Jara, P. Martinez-Julia, A. Skarmeta. Light-weight multicast DNS and DNS-SD (lmDNS-SD): IPv6-based resource and service discovery for the Web of Things. In Innovative Mobile and Internet Services in Ubiquitous Computing (IMIS), pp. 731-738, July 2012.

[11] Kirstein, P., A. J. Jara, P. Moreno, S. Varakliotis, and A. Skarmeta. "IPv6 addressing proxy: Mapping native addressing from legacy technologies and devices to IPv6 and the Internet of Things." Sensor Journal.

[12] S. Sun, L. Lannom, and B. Boesch. “Handle system overview”. RFC3650, November 2003.

[13] S. Sun, S. Reilly, L. Lannom. “Handle System Namespace and Service Definition”. RFC3651, November 2003.

[14] S. Sun, S. Reilly, L. Lannom, and J. Petrone. “Handle System Protocol (ver 2.1) Specification”. RFC3652, November, (2003).

[15] Corporation for National Research Initiatives. http://www.cnri.reston.va.us/about_cnri.html

[16] “X.1255: Framework for discovery of identity management information”. Approved in 2013-09. http://www.itu.int/rec/T-REC-X.1255-201309-I

Documents

Universal Integration of the Internet of Things through an IPv6 ... - D2.4.pdfImplementation and testing report on IPv6-based IoT6 features for the Service Layer Contract Due Date