Networking Solutions for Connecting Bluetooth Low ...

Note: this is the accepted version of the paper published in IEEE Network Magazine (Nov./Dec. 2014). The published version in its final form is available via IEEE access.

Networking Solutions for Connecting Bluetooth Low Energy Enabled Machines to the Internet of Things J. Nieminen1, C. Gomez2, M. Isomaki3, T. Savolainen3, B. Patil4, Z. Shelby5, M. Xi3, J. Oller2 1

TeliaSonera, 2Universitat Politècnica de Catalunya/Fundació i2CAT, 3Nokia, 4AT&T Mobility, 5 ARM 1 [email protected], 2{carlesgo, joaquim.oller}@entel.upc.edu, 3 {markus.isomaki, teemu.savolainen, minjun.xi}@nokia.com, 4 [email protected], 5 [email protected]

Abstract The next wave driving the expansion of the Internet will come from the Internet of Things (IoT). Bluetooth Low Energy (BT-LE) is a rapidly emerging ultra-low-power radio technology expected to be incorporated in billions of IoT devices in the next few years. Consequently, it is particularly important to specify Internet connectivity solutions for BT-LE. In this article we present such solutions based on the ongoing standardization work in the IETF and Bluetooth Special Interest Group (Bluetooth SIG). We prove the feasibility of a complete IP-based protocol stack on constrained devices and illustrate its performance, highlighting key trade-offs. In addition, we discuss gateway operation covering global IPv6 connectivity and proxy-cache functionality.

1. Introduction The Internet has grown exponentially over the last three decades and has expanded into almost every aspect of daily life. The next wave of Internet expansion is expected to be the networking of sensors, actuators and appliances, which rather than interacting with humans, measure and react to physical properties such as temperature, power consumption or heart rate. This type of networking is referred to as the Internet of Things (IoT). In the IoT vision, “Things” use the Internet Protocol (IP) and are counted in tens of billions. IPv6 is opportune for the IoT given its vast address space and autoconfiguration capabilities [1]. A plethora of low-power radio technologies suitable for IoT already exist including Bluetooth Low Energy (BT-LE), IEEE 802.15.4, Z-Wave, ANT, Dash7, Wave2M and low power variants of IEEE 802.11 [2]. Some of them already support IP, including 6LoWPAN, which defines how to run IPv6 over 802.15.4, and 802.11. The low-power radio technology with perhaps the highest potential for IoT use that is still missing IP capability is BT-LE, which is projected to be incorporated in billions of consumer electronics devices (e.g. smartphones, tablets, 1


Google glass, etc.). Accordingly, the capability to run IPv6 over BT-LE opens new doors to the IoT and leverages BT-LE towards new application areas. Among these, an outstanding use case is exploiting the smartphone as a gateway for providing Internet connectivity to surrounding BT-LE-enabled sensors. For instance, this approach allows to remotely and ubiquitously monitor medical parameters from body sensors. In another example application, vehicle health messages can be sent by vehicular sensors through the smartphone of the driver to remote Intelligent Transportation System (ITS) control centers in order to prevent accidents. Similar applications can be found in other domains including home, urban and industrial automation. Furthermore, enabling IPv6 over BTLE contributes to interoperability between IoT devices that utilize different low-power radio technologies. This is particularly important since IETF standardization work is currently progressing towards extending the family of low-power technologies with IPv6 support [3]. This paradigm is the key to a dramatic increase of IoT capilarity and to allowing generic IoT application development (i.e., avoiding the need to take into account specific features of different link and physical layer technologies). Using BT-LE for Internet connectivity and applications poses challenges beyond IPv6 packet transport, including gateway operation, application protocol efficiency, and security. In this article we present a holistic solution for integrating BT-LE devices with the IoT. A central piece of this solution is the IPv6 over BT-LE specification that is currently being produced by the IETF [4] and is expected to become a standard in the near future. However, the specification is

targeted to implementers, and therefore neither motivates the related design choices nor is written in a style comprehensible to readers outside the specialty. On the other hand, this article focuses on the whole protocol stack, highlighting aspects from all layers that are crucial to understand the capabilities and performance trade-offs of the solution. The rest of this article is structured as follows: Section 2 reviews BT-LE. Section 3 describes 6LoWPAN and our proposal for enabling IPv6 over BT-LE. Section 4 presents transport and application layer protocols. Section 5 provides performance analysis of the solution. Section 6 focuses on security aspects. Section 7 discusses gateway operation. Finally, Section 8 concludes the article.

2. Bluetooth Low Energy overview BT-LE is the hallmark feature of the Bluetooth 4.0 specification [5]. BT-LE has been designed for ultra-low-power applications, yet keeping similarities with classic Bluetooth [6]. Remarkably, a BT-LE implementation can reuse classic Bluetooth circuitry components. Therefore, the upside potential for BT-LE is enormous given that future mobile phones that have a Bluetooth chipset are expected to include BT-LE as well. Nevertheless, in order to achieve the goal of ultra-low-power consumption, major changes have been made to the BT-LE protocol stack (Figure 1, leftmost). 2

Note: this is the aaccepted verrsion of the ppaper publish hed in IEEE N Network Maggazine (Nov./Dec. access. 2014). The publisshed version in its final foorm is available via IEEE a

Figure 1. BT-LE B nativve protocol stack (leftm most) and IP Pv6-based B BT-LE stackk (rightmost)) At thhe Physical Layer, BT--LE still us es adaptivee Frequency y Hopping SSpread Specctrum (FHS SS). The nuumber of ch hannels is rreduced from m 79 (in classic Bluetoooth) to 40 0. The raw ddata rate off BT-LE is 1 Mbps. In tterms of coverage, BT-LE typicallly has a ran nge of up too a few tens of meters. The Link Layyer speciffies, amongg others, the functtionality fo for bidirecttional comm munication between tw wo devices , which req quires them m to establissh a connection. Two roles are defined for fo connectted devicess, called master m and slave. Prior to connnection estaablishment, the devicees that willl be in the slave rolee announce their preseence and coonnectability y, while thee device thaat will be in n the masteer role listen ns for thosee announceements and d initiates tthe connecction establishment byy transmittiing a messsage called Connection n Request too each deviice it attempts to connnect to. A master m can m manage multiple simulltaneous connnections with w several slaves, wheereas a slav ve can only be connectted with a single s masteer. Thereforre, BT-LE defines d a staar topology y. The connnection estabblishment tiime betweeen a master and a slavee takes less than 3 ms. Once two ddevices aree connected, a Time D ivision Multiple Accesss (TDMA)) scheme iss used by thhe master for f scheduliing the starrt of connecction eventss, in whichh communiccation betw ween masterr and slave takes placee. The Con nnection Reequest messsage servess as a referrence for synchroniza s ation betweeen masterr and slav ve. The m message con ntains connnection mannagement in nformation,, including the start tiime of the first conneection evennt and the tim me between n connectionn events, allso called co onnection innterval (wh hich is definned by the connInterval parameteer). At the beginning of a conneection even nt, the 3


master transmits a packet, which may include data and may request a transmission from the slave. Master and slave may exchange data within a connection event until all pending messages have been sent. The communication follows an acknowledged stopand-wait protocol that provides reliability and flow control. Each slave can be in sleep mode by default and wake up periodically only at the beginning of its corresponding connection event. Hence, BT-LE is duty-cycled by nature. On top of a Link Layer connection, the Logical Link Control and Adaptation Protocol (L2CAP) multiplexes upper layer data and may perform segmentation, retransmission and detection of duplicate packets, depending on the L2CAP mode in use. BT-LE uses the Basic L2CAP Mode, which does not provide segmentation or reliability services. Above L2CAP, the Generic Access Profile (GAP), Generic Attribute Profile (GATT) and the Attribute Protocol (ATT) allow applications to communicate and/or request data stored in structures called attributes.

3. IPv6 over BT-LE Connecting BT-LE nodes to the IoT requires the nodes to use IPv6. However, BT-LE does not natively support IP. We have designed a solution for enabling and optimizing IPv6 over BT-LE. A subset of our solution benefits from prior 6LoWPAN efforts to efficiently extend IPv6 to low-power wireless networks. Nevertheless, 6LoWPAN focused mainly on 802.15.4 networks, and is not suitable for BT-LE without proper adaptation. Our solution is the basis of an IETF specification that is being standardized and is expected to become a new component of the 6LoWPAN protocol suite [4]. This section is divided in two parts. The first one revisits 6LoWPAN, focusing on the functionality originally developed for 802.15.4 that is relevant to our solution. The second part describes our solution.

3.1. 6LoWPAN 6LoWPAN was designed as an adaptation layer between IPv6 and 802.15.4 that provides a panoply of mechanisms including fragmentation, header compression and optimized IPv6 Neighbor Discovery (ND) [7-9]. The 6LoWPAN architecture and the aforementioned mechanisms are overviewed next. 3.1.1. Architecture for 802.15.4-based 6LoWPANs Host and router are well-known terms used in the Internet that refer to the elements that act as end devices and IP packet forwarders, respectively. Since 802.15.4 networks are often multihop, 6LoWPAN further defines the 6LoWPAN Router (6LR) and the 6LoWPAN Border Router (6LBR). A 6LR is an intermediate router in a 6LoWPAN

4


multihop network, whereas a 6LBR is a router located between a 6LoWPAN network and another IP network.

3.1.2. Fragmentation over 802.15.4 networks IPv6 requires support for a packet size of at least 1280 bytes. However, the maximum 802.15.4 frame size is only 127 bytes. In order to solve this problem, 6LoWPAN defines IPv6 datagram fragmentation and reassembly over 802.15.4 [7]. 3.1.3. Header compression over 802.15.4 networks 802.15.4 networks are constrained in several resources, including bandwidth (with maximum effective link throughput values around 150 kbit/s) and energy (since nodes may not be mains-powered). Furthermore, the typical size of an IPv6 header is 40 bytes, which would consume a large fraction of the 802.15.4 frame payload. The 6LoWPAN header compression mechanism was designed to optimize performance of IPv6 over 802.15.4 networks. This mechanism supports stateless and stateful header compression [8]. The former exploits intrapacket redundancies (i.e., IPv6 header fields, such as linklocal addresses and datagram length, can be inferred from the encapsulating header) and the fact that many IPv6 header fields are commonly set to known values or change infrequently. On the other hand, stateful header compression requires 6LoWPAN nodes to share a common context, based on a priori knowledge of source or destination prefixes or even full addresses. In addition to IPv6 header compression, 6LoWPAN enables the reduction of the UDP header size by suppressing certain fields, and by exploiting the use of predefined port ranges. 3.1.4. 6LoWPAN Neighbor Discovery The ND protocol provides router and subnet prefix discovery, address resolution and duplicate address detection. However, ND relies on the traditional IPv6 link concept, assumes that nodes are always reachable and uses multicast heavily. Therefore, ND is not well suited to 802.15.4 networks, whereby links are commonly non-transitive, nodes may frequently be in sleep mode to save energy, and link-layer multicast does not exist. The latter implies that IP multicast is mapped to link-layer broadcast, which may unnecessarily waste the often limited network resources. The optimized ND for 6LoWPAN (6LoWPAN ND) was designed to offer several improvements, including host-initiated interaction with routers to support sleeping hosts, and multicast signaling minimization [9]. Furthermore, 6LoWPAN ND supports a mechanism for disseminating header compression context in a 6LoWPAN. 5


3.2. Enabling and optimizing IPv6 over BT-LE BT-LE and 802.15.4 are both low-power wireless technologies for energy-constrained devices, characterized by limited bandwidth and small frame size. For this reason, our solution to allow IPv6 over BT-LE includes the reuse of a subset of 6LoWPAN mechanisms. However, there exist fundamental differences between BT-LE and 802.15.4. Therefore, some 6LoWPAN mechanisms require adaptation for BT-LE, whereas others are not needed in BT-LE, thus simplifying the solution. This subsection describes and motivates the technical decisions in our solution for using IPv6 over BT-LE [4], which comprises device roles, network scenarios, protocol stack, IPv6 address autoconfiguration, neighbor discovery, header compression and fragmentation. 3.2.1. Device roles and network scenarios In BT-LE, a slave and a master play the roles of a host (hereinafter, IoT device) and a 6LBR, respectively. The 6LR role does not exist in a BT-LE-based 6LoWPAN since currently BT-LE only supports the star topology. Two network scenarios are possible when using BT-LE. In the most typical one, the BT-LE network is connected to the Internet (Figure 2.a). In this scenario the IoT devices and the 6LBR exchange IP packets over BT-LE, while the 6LBR can be connected to the Internet via any link layer technology, e.g. Wi-Fi, 3G/4G or Ethernet. In the second scenario, the BT-LE network may transiently or permanently be an isolated network (Figure 2.b).

a)

IoT device

b) Internet

IoT device

IoT device

6LoWPAN Border Router (6LBR)

BT-LE link Internet connection

IoT device

IoT device

IoT device


Figure 2. a) Internet connected and b) isolated BT-LE networks 3.2.2. Protocol stack Figure 1 (rightmost) illustrates the IPv6 over BT-LE stack, including the application and transport protocols that are most optimized for IoT devices (Section 4). Our IPv6 over BT-LE specification inserts a 6LoWPAN layer, which is adapted to BT-LE, between 6


IPv6 and BT-LE L2CAP. This decision facilitates coexistence of the native and the IPv6-based BT-LE protocol stacks in the same device, whereas only two technical changes are required below 6LoWPAN: a new L2CAP channel for IPv6, which has to be allocated by the BT-SIG, and automated discovery of IPv6-based BT-LE devices, which has been identified by the BT-SIG as a work item. Another advantage is that the L2CAP fragmentation mechanisms are still available to IPv6 (subsection 3.2.6.). 3.2.3. IPv6 address autoconfiguration IPv6 addresses are composed of a prefix and an Interface Identifier (IID). In our solution, the IID for a BT-LE interface may be formed from the Bluetooth device address, analogously to how an IID is generated from the MAC address in Ethernet [10]. The solution also supports that the IID may be created randomly to support privacy. The IPv6 link-local address is formed by appending the IID to the link-local unicast prefix fe80::/64. Global IPv6 addresses are formed by prepending a valid prefix to the IID. Such prefixes are obtained by the 6LBR (Section 7.1) and provided to the BT-LE link by using 6LoWPAN ND. 3.2.4. Neighbor Discovery in BT-LE Our solution to enable IPv6 over BT-LE includes the use of a simplified version of 6LoWPAN ND. The multihop functionality in 6LoWPAN ND (which comprises multihop duplicate address detection, as well as multihop prefix and context dissemination) is not necessary in BT-LE networks because these follow the star topology. In addition, the absence of the 6LR in BT-LE further simplifies the 6LBR, which in the BT-LE network will only interface with hosts. 3.2.5. Header compression over BT-LE IPv6 header compression for BT-LE follows the key principles in 6LoWPAN for 802.15.4 networks [8], except for how IPv6 addresses are compressed. In 802.15.4 6LoWPANs, the IID is formed from the link layer address. This allows to omit an IID from the IPv6 header when the corresponding link layer address is also present in the link layer header. The same procedure cannot be applied in BT-LE, since Bluetooth device addresses are not present in BT-LE packets (only the Access Address, which identifies a Link Layer connection, is included). However, we exploit the BT-LE star topology for IPv6 address compression as described next. In link-local communication over BT-LE, both the IPv6 source and destination addresses are suppressed because each node knows the link-local prefix and the IID of the other endpoint of a link. A 40-byte IPv6 header used in link-local communication can be reduced down to 2 bytes.

7


When an IoT device communicates with a remote node using global IPv6 addresses, the IoT device IPv6 address is omitted over the BT-LE link. This is possible since both the IoT device and the 6LBR know the prefix used in the BT-LE network and the 6LBR knows the IID of the IoT device. Therefore, both the IoT device and the 6LBR can reconstruct the IoT device IPv6 address upon packet reception over the BT-LE link. Assuming that a context is defined for the remote node, the prefix or even the full address of that node can be omitted. In this case, a 40-byte IPv6 header can be reduced to an 11-byte or a 3-byte header, respectively. 3.2.6. Fragmentation in BT-LE Similarly to 802.15.4, BT-LE poses the problem of not supporting the transmission of 1280-byte packets. In fact, the BT-LE packet payload size is only 27 bytes, from which L2CAP headers may consume additional bytes. Conveniently, the L2CAP layer provides two mechanisms that can be used for transmitting large packets: Segmentation and Reassembly (SAR), and Fragmentation and Recombination (FAR). Thus, it is not necessary to use fragmentation mechanisms at the 6LoWPAN layer [4]. SAR breaks a large IPv6 datagram into different parts called segments and prepends an L2CAP header to each segment (Figure 3.a)). On the other hand, FAR divides a large L2CAP PDU (i.e., a large IPv6 datagram preceded by an L2CAP header) into multiple pieces called fragments, each of which is then encapsulated in a BT-LE packet (Figure 3.b)). In terms of overhead, the most lightweight option is FAR jointly with the Basic L2CAP Mode. Among the L2CAP modes that support SAR, the L2CAP Streaming Mode incurs the lowest overhead. This L2CAP mode does not provide L2CAP-layer reliability and avoids duplicating functionality across layers, since the BT-LE Link Layer accounts with mechanisms for error detection and recovery. On the other hand, FAR may pose a serialization problem in devices that support both the native and the IPv6-based BT-LE stacks. The problem happens when native ATT packets are placed in the send queue while the radio is busy transmitting a large IPv6 packet. Since with FAR the large IPv6 packet would be transmitted as a single L2CAP PDU, which would need the delivery of many consecutive Link Layer packets (e.g. 56 Link Layer packets for a 1500-byte IPv6 packet), the transmission of L2CAP PDUs containing ATT data would be unfairly delayed. Nevertheless, the transmission of large IPv6 packets over BT-LE is a rare event in current use cases.

8


Figgure 3. Encaapsulation of o large IP ddatagrams in multiple BT-LE packkets: a) L2C CAP m modes that support s SAR R, b) Basic L L2CAP Mo ode + FAR. Data D unit fifield sizes arre exppressed in byytes

4. T Transport and appllication laayers Enabbling efficieent IPv6 ov ver BT-LE E is not suffficient witthout optim mizing the entire protoocol stack. CoAP is an a efficient binary web b service protocol p stanndardized at a the IETF F [11, 12], enabling e thee integrationn of BT-LE E with IoT web w servicees on the Intternet direcctly or via an a HTTP proxy (Sectiion 7.2). Co oAP enables web servi vices for thee IoT, and iis optimizedd for short interactions i s for small amounts a of data. The pprotocol sup pports the R RESTful intteraction model of the Web, inclu uding GET, POST, PU UT and DEL LETE methhods, URIs and respon nse codes. This is reaalized using g a small ffour-byte binary b headder and an asynchrono ous transacction modell over UDP P. CoAP suupports opttional reliabbility by using a stop p-and-wait rretransmisssion schemee. CoAP prrovides effficient appliication layer interoperaability for IP Pv6 enabled d BT-LE devices. 5. Pe erforman nce This section evaaluates the performance p e of the pro oposed soluttion for IPvv6 over BT-L LE in onsumption , throughpu ut, and lateency. Seveeral IPv6 header h terms of energyy/power co comppression sccenarios an nd the twoo lowest-ov verhead L2 2CAP moddes that su upport fragm mentation (ii.e. the Streeaming Mo de, and thee Basic L2C CAP Mode plus FAR) have 9


been considered. Both theoretical and experimental results are provided. For the experimental evaluation, a prototype implementation of the IPv6 over BT-LE protocol stack was developed by Nokia Research Center on a CC2540 chipset based keyfob as the BT-LE slave and on a modified Nokia N9 smartphone as the BT-LE master. The BT-LE Physical Layer, the Link Layer and the L2CAP were already implemented in the aforementioned devices. SAR was implemented to support fragmentation, since FAR was not available on the used chipsets. The memory footprint of the implementation on the slave is 1.3 kB of RAM and 18.7 kB of ROM, which demonstrates the feasibility of implementing the solution in constrained devices. The transmit power of the keyfob was set to 0 dBm, and the distance between the keyfob and the smartphone was 1 m. Each empirical average result has been obtained from 20 individual experiments.

5.1. Energy and power consumption Figure 4 plots the amount of energy consumed by a slave in order to communicate an IPv6 datagram in different scenarios. The theoretical results have been obtained by means of analysis, assuming that bit errors do not occur. The calculation has used power measurements of a CC2540 radio chip in slave mode (with the transmit power set to 0 dBm) as an input [13]. Specifically, the study includes the energy needed to wake up the device, turn the radio on to receive a BT-LE poll packet, receive the packet, prepare the radio for transmit mode, transmit the BT-LE packet that contains a part of the IPv6 datagram (or the whole datagram if it is small enough), turn the radio into receive mode, receive the corresponding BT-LE link layer ACK, repeat the data/ACK sequence as many times as needed, and carry out a final post-processing operation before the device returns to sleep mode. Results show that header compression provides significant benefits, especially for small packets. An IPv6 datagram that contains an uncompressed IPv6 header and an 8-byte payload (i.e., the size of the smallest possible CoAP/UDP packet), has to be carried in three and two BT-LE packets in the Streaming Mode and in the Basic L2CAP Mode, respectively. However, when the IPv6 header is compressed, a single BT-LE packet suffices to carry that IPv6 datagram for the modes and scenarios considered. Note that the additional header overhead due to SAR in the Streaming Mode penalizes the communication, especially for large datagram payloads. Experimental results exhibit an additional stepwise energy consumption increase every, roughly, 80 bytes. This is a consequence of a radio buffer space limitation in the CC2540 chipset, by which only four maximum-sized BT-LE data packets can be transmitted within the same connection event. When the PDU to be transported requires exceeding this limit, the rest of the PDU (i.e. the IPv6 packet in this case) is sent in the next connection event(s). For each subsequent connection event, an additional set of warm-up, poll reception and post-processing intervals are needed. The radio buffer space limitation is a common feature of current BT-LE platforms, since BT-LE has 10


actually been designed for short exchanges of short data units. However, future BT-LE platforms are expected to provide enhanced support for transmitting large IPv6 packets.

Energy consumption (J)

1200 1000 800 600 400 200 0 0

20

40

60

80 100 120 140 160 180 200 220 240 260 280 300 320 340

IPv6 datagram payload size (bytes) Streaming Mode, Uncompressed Basic L2CAP Mode + FAR, Uncompr. Experimental, Uncompressed

Streaming Mode, Link‐local Basic L2CAP Mode + FAR, Link‐local Experimental, Link‐local

Figure 4. Energy cost of communicating an IPv6 datagram over a BT-LE link versus its payload size, for the L2CAP options considered and for different IPv6 header compression scenarios We also conducted a set of experiments in order to assess the influence of connInterval on power consumption of the prototype implementation. The experiments consisted of message exchanges which comprised a CoAP GET request sent by the smartphone and the corresponding response from the keyfob. Every connection event contained either a request or a reply. As shown in Figure 5, the average power consumed by the slave decreases as the connInterval parameter increases. This is an expected result since the duration of the inactive part of the connection interval increases with the connection interval size. However, we have observed that the duration of the active part (i.e. the connection event), which in theory should be independent of connInterval, increases with this parameter (Figure 5, rightmost axis). This occurs because the slave implementation is required to be prepared for receiving the initial packet from the master in a connection event for a greater amount of time as connInterval increases, in order to avoid synchronization deviation between the two link endpoints. This BT-LE implementation issue limits the power consumption decrease with connInterval. Nevertheless, a device lifetime of circa two years can be achieved under the intensive communication pattern 11


used in the experiments and using a typical button cell battery (e.g. with a capacity of 650 mWh).

Power consumption (W)

8

1500

6 1000 4 500

2 0

0 0.1

0.5

1

1.5

2

2.5

3

3.5

Connection event duration (ms)

10

2000

4

connInterval (s) Power consumption ‐ without payload Conn. event duration ‐ without payload

Power consumption ‐ with payload Conn. event duration ‐ with payload

Figure 5. Average power consumption during a connection interval and connection event duration versus the connInterval parameter for a CC2540-based keyfob. The connection event duration includes the time required for processing by the slave after communication

5.2. Throughput We evaluated the IPv6 throughput of a BT-LE link between a master and a single slave, versus IPv6 payload size (Figure 6). The theoretical results have been obtained by means of analysis, assuming an ideal link. Whereas the physical layer data rate is 1 Mbps, the asymptotically achievable IPv6 throughput is 319.5 kbit/s and 248.5 kbit/s for the Basic L2CAP Mode plus FAR, and for the Streaming Mode, respectively. These values are limited by the L2CAP overhead for each option (which is greater in Streaming Mode), and by the Link Layer overhead (which is the same for both). As the IPv6 datagram payload increases, each additional BT-LE packet needed initially leads to abrupt throughput decrease due to the overhead of the additional BT-LE packet, creating a sawtooth form for the throughput. Another similar effect is the stepwise form in the energy consumed (Figure 4). On the other hand, the maximum IPv6 throughput that can be achieved experimentally may be significantly lower than the theoretical one. In fact, the CC2540 platform exhibits the aforementioned constrained radio buffer size, which limits the amount of data that can be sent per connection event. In our measurements, shown in Figure 6, connInterval was set to the smallest possible value (i.e. 7.5 ms) in order to obtain the highest throughput, which was found to be 63.3 kbit/s. Because very low connInterval values are highly demanding for the 12


CC2540 platform, the achievable throughput is lower than the theoretical one even considering the radio buffer space limitation (Figure 6). We observed that a fraction of connection events included a number of transmitted BT-LE packets below the expected one. This fraction increases with the total number of bytes to be sent per connection event. We also experimented with a larger connInterval setting and, as expected, the measured throughput was inversely proportional to connInterval. 300

IPv6 throughput (kbit/s)

250 200 150 100 50 0

0

20

40

60

80

100

120

IPv6 datagram payload size (bytes) Basic L2CAP Mode + FAR, Link‐local Streaming mode, Link Local Exp., Link‐local, connInterval=7.5 ms Exp., Link Local, connInterval=30 ms Str. Mode, Link‐local, radio buffer limit.

Basic L2CAP Mode + FAR, Uncompr. Streaming mode, Uncompressed Exp., Uncompr, connInterval=7.5 ms Exp., Uncompr, connInterval=30 ms

Figure 6. IPv6 throughput over an ideal BT-LE link versus IPv6 datagram payload size, for different L2CAP and IPv6 header compression scenarios

5.3. Latency Figure 7 depicts the latency measured experimentally of a CoAP request-reply exchange over the BT-LE link. Each exchange involves a connection event for the request and another one for the reply. Results shown in Figures 7 and 5 illustrate the trade-off between latency and power consumption, which depends on the connInterval setting. For applications that pose moderate real-time requirements, significant power consumption savings are achieved by setting connInterval to 0.5 s. Delay-insensitive applications would benefit in terms of energy saving from connInterval values around or greater than 2 s. 13


10000 9000 8000 Latency (ms)

7000 6000 5000 4000 3000 2000 1000 0 0

500

1000

1500

2000

2500

3000

3500

4000

connInterval (ms)

Figure 7. Latency of a CoAP request-reply exchange over a BT-LE link. Average and standard deviation results are plotted

6. Security BT-LE networks are susceptible to various types of threats and attacks on confidentiality, integrity and service availability. The IPv6 over BT-LE specification exploits BT-LE security mechanisms [4]. The transmission of IPv6 datagrams is protected by BT-LE Link Layer security, which simultaneously supports encryption and authentication by using the Cipher Block Chaining-Message Authentication Code (CCM) algorithm and a 128-bit AES block cipher. When encryption and authentication are used, a 4-byte Message Integrity Check (MIC) is included in the BT-LE packets that contain a non-zero length payload. Then, encryption is applied to the PDU payload and MIC fields. The encryption algorithm provides also replay protection. The use of BT-LE security requires the devices to perform a procedure called pairing, by which the devices establish cryptographic materials. The Bluetooth Security Manager Protocol (SMP) is used for carrying out the pairing and key distribution procedures.

7. Router and gateway operation BT-LE-enabled IoT devices communicate to the Internet via a gateway, which can be implemented e.g. into a mobile phone or a home router. In its simplest form, the gateway is a plain IP router which implements 6LBR mechanisms. On top of the basic router mode, the gateway can perform certain application layer functions, acting as a 14


proxyy, a translaator or a cacche. All theese modes are discussed in this ssection. Fig gure 8 show ws how the different d mo odes relate tto protocol stacks and layers. l

Figgure 8. A gaateway conn necting IoT devices to the t Internet can operate te as a 6LBR R/IP router or have addiitional appliication funcctions. L2 sttands for Liink Layer

7.1. IP router functions In orrder to be abble to numb ber IoT devvices with global g IPv6 addresses, a gateway has h to obtaiin global IP Pv6 prefixess. A set of tools are av vailable for that purpoose, use of which w depends on the type of Inteernet connecctivity that the gateway y has at anyy given mom ment. DHC CPv6 Prefixx Delegatio on (DHCPvv6 PD) is the most suitable toool for obtaaining prefixes for netw work numbering. DHC CPv6 PD is commonly used in fixxed line netw works for eexplicit andd automated d prefix dellivery for requesting r edge e routerrs, and has been recenntly adopteed by the 3GPP for the same purpose. When W DHC CPv6 PD is not availlable, the gaateway may y fall back tto utilize so ome of the IPv6 transitiion tools deefined by thhe IETF [144], in order to t be able too provide IP Pv6 connecttivity.

7.2. Applicatioon layer fu unctions BT-L LE applications that usse CoAP m may benefit from f a CoA AP proxy inn a gateway y. The proxyy can work in two direections. In th the forward mode, it caan pass CoA AP requests from an IooT device to t servers on o the Intern rnet. In the reverse mo ode, the prooxy would allow CoA AP clients onn the Intern net to reach a BT-LE CoAP C serverr through ittself. In add dition, the pproxy mayy support protocol p traanslation between Co oAP and H HTTP, as CoAP C messsages can be b easily maapped to HT TTP messaages [10]. Furthermore F e, the proxy y may also include a caache, which h can reply ddirectly to some s of the requests deestined to an a IoT devicce running a CoAP seerver, thus rreducing th he power co onsumptionn of the latter. In orderr to enable this t model, CoAP offeers an option n called Maax-Age, by which the server s 15


indiccates the perriod of timee for which a resource representati r ion (e.g. a ssensor readin ng) is consiidered to be b valid. Fiigure 9 illuustrates thee theoreticaal power coonsumption of a CC2540-based IoT I device running a C CoAP serveer, whereby a cache fullfills requessts on behaalf of it. Ressults are com mpared witth those obttained in ab bsence of a cache. Max x-Age is set to 1000 s, s and the time betweeen connection events is i set to 100 s. As show wn in Figurre 9, the power savin ngs of usingg a cache increase i as the time bbetween req quests decreeases, and become b sign nificant whhen this timee is in the order o of onee minute orr less. Rem markably, thhe improvem ment is posssible even n though BT-LE is inntrinsically dutycycleed.

Figgure 9. Influuence of a cache c on thee average power p consu umption of a CoAP server overr BT-LE. When W CoAP responses r aare separatee, the CoAP ACK and th the responsee are sent by the seerver as diffe ferent messaages. A pigg gybacked reesponse ackn knowledges the reqquest while providing p th the responsee within the same messaage

8. C Conclusion ns and futture work k In thhis article wee presented a holistic nnetworking solution forr connectingg BT-LE deevices W evaluateed several hheader com mpression sccenarios annd fragmenttation with the IoT. We mechhanism opttions. Furth hermore, w we proved the feasibility of im mplementing g the soluttion on IoT T devices and illustrrated perfo ormance traade-offs deepending on n the confi figuration off a key BT-LE parameeter. We con nclude that it is possiblle to enablee endto-ennd IP connectivity forr BT-LE deevices in an a efficient manner, eespecially in the aspeccts that are most criticaal for IoT deevices: enerrgy consum mption and m memory foo otprint of the implemenntation.

16


Open issues include evaluating additional header compression mechanisms (e.g. a proposal called Generic Header Compression), IoT device management and optimizing mobile gateways by adapting their Internet connectivity link to support IoT traffic.

Acknowledgment This work was supported by TEKES as part of the Future Internet programme of TIVIT (Finnish Strategic Centre for Science, Technology and Innovation in the field of ICT). The authors appreciate the great work done by Radio Prototyping team in Nokia Research Center. The authors would also like to thank the IETF 6LoWPAN WG, which contributed to shape the solution for using IPv6 over BT-LE. Carles Gomez and Joaquim Oller were supported in part by the Spanish Government’s Ministerio de Economía y Competitividad through projects TEC2009-11453, TEC2012-32531, and by FEDER. Joaquim Oller was also supported by an FPI grant.

References [1]

J. Hui, D. Culler, “Extending IP to Low-Power, Wireless Personal Area Networks”, IEEE Internet Computing, Jul. 2008, pp. 37-45.

[2]

C. Gomez, J. Paradells, “Wireless Home Automation Networks: A Survey of Architectures and Technologies”, IEEE Communications Magazine, Vol. 48, Issue 6, Jun. 2010, pp. 92-101.

[3]

IPv6 over Networks of Resource-Constrained Nodes (6lo). Proposed Working Group charter, 2013 (http://datatracker.ietf.org/wg/6lo/charter/).

[4]

J. Nieminen, T. Savolainen, M. Isomäki, B. Patil, Z. Shelby, C. Gomez, “Transmission of IPv6 Packets over Bluetooth Low Energy”, draft-ietf-6lobtle-00, work-in-progress, Nov. 2013.

[5]

“Specification of the Bluetooth System”, Covered Core Package Version: 4.0, Jun. 2010.

[6]

C. Bisdikian, “An Overview of the Bluetooth Wireless Technology”, IEEE Communications Magazine, Vol. 39, Issue 12, Dec. 2001, pp. 86-94.

[7]

G. Montenegro, N. Kushalnagar, J. Hui, D. Culler, “Transmission of IPv6 Packets over IEEE 802.15.4 Networks”, RFC 4944, Sep. 2007.

[8]

J. Hui, Ed., P. Thubert, “Compression Format for IPv6 Datagrams over IEEE 802.15.4-based Networks”, RFC 6282, Sep. 2011.

17


[9]

Z. Shelby, S. Chakrabarti, E. Nordmark, C. Bormann, “Neighbor Discovery Optimization for Low Power and Lossy Networks (6LoWPAN)”, RFC 6775, Nov. 2012.

[10]

M. Crawford, “Transmission of IPv6 packets over Ethernet networks”, RFC 2464, Dec. 1998.

[11]

Z. Shelby, K. Hartke, C. Bormann, B. Frank, “Constrained Application Protocol”, draft-ietf-core-coap-18, work in progress, June 2013.

[12]

Z. Shelby, “Embedded web services”, IEEE Wireless Communications Magazine, Vol. 17, Issue 6, Dec. 2010, pp. 52-57.

[13]

S. Kamath, “Measuring Bluetooth Low Energy Power Consumption”, Application Note AN092 (Texas Instruments), Oct. 2010.

[14]

C. Byrne et al, “Extending an IPv6 /64 Prefix from a 3GPP Mobile Interface to a LAN”, draft- ietf-v6ops-64share-09, work in progress, Oct. 2013.

Biographies Dr. Johanna Nieminen is currently affiliated in TeliaSonera as a senior network architect. She is responsible for the development of architecture and strategy and management of technical projects in the fixed broadband technology area, with the focus on networks. She has previously led wireless networking research in Nokia Research Center, first as a solid line manager and later as a Principal researcher and leader of a virtual team. Before her industry career she worked as an individual researcher in Aalto University. Carles Gomez received his M.Sc. and Ph.D. degrees from Universitat Politècnica de Catalunya in 2002 and 2007, respectively. He is associate professor at the same university. He is co-author of numerous technical contributions including papers published in journals and conferences, IETF RFCs, and the book “Sensors Everywhere – Wireless Network Technologies and Solutions”. His research interests include wireless multihop networks, wireless sensor networks, the Internet of Things, and application domains such as smart cities and home automation. Markus Isomäki is a Senior Manager at Nokia working on Internet and Web technology standardization. His interest areas include Internet of Things, Web based real-time communications and new transport protocols. He is a long time contributor in the IETF, 18


and has also worked on W3C, 3GPP and GSMA standards. He holds an MSc degree from Helsinki University of Technology. Teemu Savolainen received his M.Sc of Information Technology in 2001 from Tampere University of Technology, Finland. He is a Principal Researcher and inventor at Nokia and has worked on wireless networking with emphasis on IPv6 enabled mobile handsets since 1999. Teemu has been actively contributing to the IPv6 related standards at IETF, 3GPP, and lately at Bluetooth SIG for standardization of IPv6 over Bluetooth LowEnergy. Basavaraj Patil is currently a Principal Technical Architect in AT&T Mobility. He is a 20+ year veteran of the telecom industry and his previous affiliations include Cisco Systems, Nokia and Nortel Networks. Basavaraj has been actively involved with the IETF since 1999 and has chaired several IP mobility working groups. He has coauthored a number of IETF RFCs and also been an active contributor to WiMAX and 3GPP standards. He is also an author of the book "IP in Wireless Networks", published in 2003. Zach Shelby is Director of Technology for Internet of Things at ARM and a thought leader for the whole industry. Zach was co-founder of Sensinode where he has acted as CEO and CTO for the ground-breaking company before recent acquisition by ARM. Before starting Sensinode, he led wireless networking research at the Centre for Wireless Communications and at the Technical Research Center of Finland. Zach is a key contributor at the IETF for IoT standards with contributions in 6LoWPAN, routing, web services and security related standards, ETSI and OMA standardisation on M2M, and in several top international research programs. Zach is known is a pioneer in the use of IP and Web technology in low-power networks with 6LoWPAN and CoAP standards development, and is co-author of the book "6LoWPAN: The Wireless Embedded Internet". His results include a large portfolio of courses, publications, public talks, broad research cooperation, and key patents. Zach has served on the Technical Advisory Board and currently on the Board of Directors at the IPSO Alliance. Minjun Xi received the B. degree in Computer Science from Beijing Institute of Technology (BIT) and the M. degree in Computer Science & Engineering from Beihang (BUAA) University, Bejing China, in 2005 and 2008, respectively. Since May 2011, he has been with Nokia Research Center in Beijing, where he is currently the Senior Engineer of Radio Prototyping team. His main research interests include Internet of Things (IoT), Mobile Computing and Social Networks. Joaquim Oller Bosch is member of the Wireless Networks Group at Universitat Politècnica de Catalunya. He holds a degree in Computer Science and is currently pursuing his PhD in Telematics Engineering in the field of ultra-low power wake-up receivers and low-power duty-cycled MAC protocols. He has worked in different 19


research projects involving wireless technologies such as Wake-up Radio systems, RFID / NFC, IEEE 802.15.4, IEEE 802.11, Bluetooth and Bluetooth Low Energy, as well as ultra-low power microcontrollers.

20


Figure 1. BT-LE B nativve protocol stack (leftm most) and IP Pv6-based B BT-LE stackk (rightmost))

21


a)

IoT device

b) Internet

IoT device

IoT device


BT-LE link Internet connection

IoT device

IoT device

IoT device


Figure 2. a) Internet connected and b) isolated BT-LE networks

22


Figgure 3. Encaapsulation of o large IP ddatagrams in multiple BT-LE packkets: a) L2C CAP m modes that support s SAR R, b) Basic L L2CAP Mo ode + FAR. Data D unit fifield sizes arre exppressed in byytes

23


Energy consumption (J)

1200 1000 800 600 400 200 0 0

20

40

60

80 100 120 140 160 180 200 220 240 260 280 300 320 340

IPv6 datagram payload size (bytes) Streaming Mode, Uncompressed Basic L2CAP Mode + FAR, Uncompr. Experimental, Uncompressed

Streaming Mode, Link‐local Basic L2CAP Mode + FAR, Link‐local Experimental, Link‐local

Figure 4. Energy cost of communicating an IPv6 datagram over a BT-LE link versus its payload size, for the L2CAP options considered and for different IPv6 header compression scenarios

24


Power consumption (W)

8

1500

6 1000 4 500

2 0

0 0.1

0.5

1

1.5

2

2.5

3

3.5

Connection event duration (ms)

10

2000

4

connInterval (s) Power consumption ‐ without payload Conn. event duration ‐ without payload

Power consumption ‐ with payload Conn. event duration ‐ with payload

Figure 5. Average power consumption during a connection interval and connection event duration versus the connInterval parameter for a CC2540-based keyfob. The connection event duration includes the time required for processing by the slave after communication

25

Note: this is the accepted version of the paper published in IEEE Network Magazine (Nov./Dec. 2014). The published version in its final form is available via IEEE access. 300

IPv6 throughput (kbit/s)

250 200 150 100 50 0

0

20

40

60

80

100

120

IPv6 datagram payload size (bytes) Basic L2CAP Mode + FAR, Link‐local Streaming mode, Link Local Exp., Link‐local, connInterval=7.5 ms Exp., Link Local, connInterval=30 ms Str. Mode, Link‐local, radio buffer limit.

Basic L2CAP Mode + FAR, Uncompr. Streaming mode, Uncompressed Exp., Uncompr, connInterval=7.5 ms Exp., Uncompr, connInterval=30 ms

Figure 6. IPv6 throughput over an ideal BT-LE link versus IPv6 datagram payload size, for different L2CAP and IPv6 header compression scenarios

26

Note: this is the accepted version of the paper published in IEEE Network Magazine (Nov./Dec. 2014). The published version in its final form is available via IEEE access. 10000 9000

Latency (ms)

8000 7000 6000 5000 4000 3000 2000 1000 0 0

500

1000

1500

2000

2500

3000

3500

4000

connInterval (ms)

Figure 7. Latency of a CoAP request-reply exchange over a BT-LE link. Average and standard deviation results are plotted

27


Figgure 8. A gaateway conn necting IoT devices to the t Internet can operate te as a 6LBR R/IP router or have addiitional appliication funcctions. L2 sttands for Liink Layer

28


Figgure 9. Influuence of a cache c on thee average power p consu umption of a CoAP server overr BT-LE. When W CoAP responses r aare separatee, the CoAP ACK and th the responsee are sent by the seerver as diffe ferent messaages. A pigg gybacked reesponse ackn knowledges the reqquest while providing p th the responsee within the same messaage

29