IPv6 Mesh over BLUETOOTH(R) Low Energy Using the Internet Protocol Support Profile (IPSP)Universitat Politecnica de CatalunyaC/Esteve Terradas, 708860CastelldefelsSpaincarlesgo@entel.upc.eduUniversitat Politecnica de CatalunyaC/Esteve Terradas, 708860CastelldefelsSpainsm.darroudi@entel.upc.eduUnaffiliatedtsavo.stds@gmail.comGraz University of TechnologyInffeldgasse 16/IGraz8010Austriamichael.spoerk@tugraz.at
Internet
6Lo Working GroupBluetooth Low Energymesh networks6lowpanIPv6Low powerIoTInternet of Things
RFC 7668 describes the adaptation of IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) techniques to enable IPv6 over Bluetooth Low Energy (Bluetooth LE) networks that follow the star topology.
However, recent Bluetooth specifications allow the formation of extended topologies as well. This document specifies mechanisms that are needed
to enable IPv6 mesh over Bluetooth LE links established by using the Bluetooth Internet Protocol Support Profile (IPSP).
This document does not specify the routing protocol to be used in an IPv6 mesh over Bluetooth LE links.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
Table of Contents
. Introduction
. Terminology and Requirements Language
. Bluetooth LE Networks and the IPSP
. Specification of IPv6 Mesh over Bluetooth LE Links
. Protocol Stack
. Subnet Model
. Link Model
. Stateless Address Autoconfiguration
. Neighbor Discovery
. Header Compression
. Unicast and Multicast Mapping
. IANA Considerations
. Security Considerations
. References
. Normative References
. Informative References
. Bluetooth LE Connection Establishment Example
. Node-Joining Procedure
Acknowledgements
Contributors
Authors' Addresses
Introduction
Bluetooth Low Energy (hereinafter, Bluetooth LE) was first introduced
in the Bluetooth 4.0 specification. Bluetooth LE (which has been
marketed as Bluetooth Smart) is a low-power wireless technology
designed for short-range control and monitoring applications.
Bluetooth LE is currently implemented in a wide range of consumer
electronics devices, such as smartphones and wearable devices. Given
the high potential of this technology for the Internet of Things, the
Bluetooth Special Interest Group (Bluetooth SIG) and the IETF have
produced specifications in order to enable IPv6 over Bluetooth LE,
such as the Internet Protocol Support Profile (IPSP) and RFC 7668, respectively.
Bluetooth 4.0 only supports Bluetooth LE
networks that follow the star topology. As a consequence, RFC 7668 was
specifically developed and optimized for that type of network
topology. However, the functionality described in RFC 7668 is not
sufficient and would fail to enable an IPv6 mesh over Bluetooth LE links. This
document specifies mechanisms that are needed to enable IPv6 mesh over Bluetooth LE links.
This document does not specify the routing protocol to be used in an
IPv6 mesh over Bluetooth LE links.
Terminology and Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14
when, and only when, they appear in all capitals, as shown here.
The terms "6LoWPAN Node" (6LN), "6LoWPAN Router" (6LR), and "6LoWPAN Border Router" (6LBR) are defined as in , with an addition that Bluetooth LE central and Bluetooth LE peripheral (see ) can both be adopted by a 6LN, a 6LR, or a 6LBR.
Bluetooth LE Networks and the IPSP
Bluetooth LE defines two Generic Access Profile (GAP) roles of relevance herein: the Bluetooth LE central role and the Bluetooth LE peripheral role.
In Bluetooth 4.0, a device in the central role, which is called "central" from now on, was able to manage multiple simultaneous connections with a number of devices in the peripheral role,
called "peripherals" hereinafter. Bluetooth 4.1 (now deprecated) introduced the possibility for a peripheral to be connected to more than one central
simultaneously, therefore allowing extended topologies beyond the star topology for a Bluetooth LE network . In addition, a device may simultaneously
be a central in a set of link-layer connections, as well as a peripheral in others.
On the other hand, the IPSP enables discovery of IP-enabled devices
and the establishment of a link-layer connection for transporting IPv6 packets. The IPSP defines the Node and Router roles for devices that
consume/originate IPv6 packets and for devices that can route IPv6 packets, respectively.
Consistent with Bluetooth 4.1, Bluetooth 4.2 , and subsequent Bluetooth versions, a device may implement both roles simultaneously.
This document assumes a mesh network composed of Bluetooth LE links, where link-layer
connections are established between neighboring IPv6-enabled
devices (see Section 3.3.2, item 3.b, and an example in ). The IPv6 forwarding devices of the mesh have to implement both IPSP Node and Router roles, while simpler leaf-only nodes can implement only the Node role. In an IPv6 mesh over Bluetooth LE links, a node is a
neighbor of another node, and vice versa, if a link-layer connection
has been established between both by using the IPSP functionality for
discovery and link-layer connection establishment for IPv6 packet
transport.
Specification of IPv6 Mesh over Bluetooth LE LinksProtocol Stack illustrates the protocol stack for IPv6 mesh over Bluetooth LE
links. The core Bluetooth LE protocol stack comprises two main sections: the Controller and the Host. The former includes the Physical Layer
and the Link Layer, whereas the latter is composed of the Logical Link Control and Adaptation Protocol (L2CAP), the Attribute Protocol (ATT),
and the Generic Attribute Profile (GATT). The Host and the Controller sections are connected by means of the Host-Controller Interface (HCI).
A device that supports the IPSP Node role instantiates one Internet Protocol Support Service (IPSS), which runs atop GATT.
The protocol stack shown in shows two main differences with the IPv6 over
Bluetooth LE stack in :
the adaptation layer below IPv6
(labeled as "6Lo for IPv6 mesh over Bluetooth LE") is now adapted for
IPv6 mesh over Bluetooth LE links, and
the protocol stack for IPv6
mesh over Bluetooth LE links includes IPv6 routing functionality.
Bluetooth 4.2 defines a default MTU for Bluetooth LE of 251 bytes. Excluding the L2CAP header of 4 bytes, a protocol data unit (PDU)
size of 247 bytes is available for the layer above L2CAP. (Note: Earlier Bluetooth LE versions offered a maximum amount of 23 bytes for the layer atop L2CAP.)
The L2CAP provides a fragmentation and reassembly solution for transmitting or receiving larger PDUs. At each link, the IPSP defines means for
negotiating a link-layer connection that provides an MTU of 1280 octets or higher for the IPv6 layer .
As per the present specification, the MTU size for IPv6 mesh over BLE links is 1280 octets.
Similarly to , fragmentation functionality from 6LoWPAN standards is
not used for IPv6 mesh over Bluetooth LE links. Bluetooth LE's fragmentation support provided
by L2CAP is used.
Subnet Model
For IPv6 mesh over Bluetooth LE links, a multilink model has been
chosen, as further illustrated in . As IPv6 over Bluetooth
LE is intended for constrained nodes and for Internet of Things use
cases and environments, the complexity of implementing a separate
subnet on each peripheral-central link and routing between the
subnets appears to be excessive. In this specification, the benefits
of treating the collection of point-to-point links between a central
and its connected peripherals as a single multilink subnet rather
than a multiplicity of separate subnets are considered to outweigh
the multilink model's drawbacks as described in .
With the multilink subnet model, the routers have to take on the responsibility of tracking the multicast state and forwarding
multicast in a loop-free manner.
Note that the route-over functionality defined in
is essential to enabling the multilink subnet model for IPv6 mesh over Bluetooth LE links.
One or more 6LBRs are connected to the Internet. 6LNs are connected to the network through a 6LR or a 6LBR.
Note that in some scenarios and/or for some time intervals, a 6LR may remain at the edge of the network
(e.g., the top left node in ). This may happen when a 6LR has no neighboring 6LNs.
A single global unicast prefix is used on the whole subnet.
IPv6 mesh over Bluetooth LE links MUST follow a route-over
approach. This document does not specify the routing protocol to be
used in an IPv6 mesh over Bluetooth LE links.
Link ModelStateless Address Autoconfiguration
6LN, 6LR, and 6LBR IPv6 addresses in an IPv6 mesh over Bluetooth LE links are
configured as per .
Multihop Duplicate Address Detection (DAD) functionality as defined in and updated by , or some substitute mechanism (see ), MAY be supported.
Neighbor Discovery
"" , subsequently updated
by "" ,
describes the neighbor discovery functionality adapted for use in several 6LoWPAN topologies, including the mesh topology.
The route-over functionality of and MUST be supported.
The following aspects of the Neighbor Discovery optimizations for 6LoWPAN are applicable to Bluetooth LE 6LNs:
A Bluetooth LE 6LN MUST register its non-link-local addresses with
its routers by sending a Neighbor Solicitation (NS) message with the Extended Address Registration Option (EARO) and process the
Neighbor Advertisement (NA) accordingly.
The EARO option includes a Registration Ownership Verifier (ROVR) field . In the case of Bluetooth LE, by default, the ROVR field
is filled with the 48-bit device address used by the Bluetooth LE node converted into 64-bit Modified EUI-64 format .
Optionally, a cryptographic ID (see RFC 8928) MAY be placed in the ROVR field. If a cryptographic ID is used,
address registration and multihop DAD formats and procedures defined in MUST be used unless
an alternative mechanism offering equivalent protection is used.
As per , a 6LN link-local address does not need to be unique in the multilink subnet. A link-local address only needs to be unique
from the perspective of the two nodes that use it to communicate (e.g., the 6LN and the 6LR in an NS/NA exchange). Therefore, the exchange
of Extended Duplicate Address Request (EDAR) and Extended Duplicate Address Confirmation (EDAC) messages between the 6LR and a 6LBR, which ensures that an address is unique across the domain covered by the 6LBR, does not
need to take place for link-local addresses.
If the 6LN registers multiple addresses that are not based on the
Bluetooth device address using the same compression context, the
header compression efficiency may decrease, since only the last registered address can be fully elided (see ).
For sending Router Solicitations and processing Router Advertisements, the hosts that participate in an IPv6 mesh over BLE MUST, respectively, follow Sections and
of , and .
The router behavior for 6LRs and 6LBRs is described in and updated by . However, as per this specification:
Routers SHALL NOT use multicast NSs to discover other routers' link-layer addresses.
As per , in a dynamic configuration scenario, a 6LR comes up as a non-router and waits to receive a Router Advertisement
for configuring its own interface address first before setting its interfaces to advertising interfaces and turning into a router.
In order to support such an operation in an IPv6 mesh over Bluetooth LE links, a 6LR first uses the IPSP Node role only. Once the 6LR has established
a connection with another node currently running as a router and receives a Router Advertisement from that router, the 6LR configures its own
interface address, turns into a router, and runs as an IPSP Router. In contrast with a 6LR, a 6LBR uses the IPSP Router role since the 6LBR
is initialized; that is, the 6LBR uses both the IPSP Node and IPSP Router roles at all times. See an example in .
Border router behavior is described in and updated by .
defines substitutable mechanisms for distributing prefixes and context information (), as well as for
duplicate address detection across a route-over 6LoWPAN (). updates those mechanisms and the related message formats.
Implementations of this specification MUST either support the features described in Sections and of , as updated by
or some alternative ("substitute") mechanism.
Header Compression
Header compression as defined in RFC 6282 , which specifies the compression format for IPv6 datagrams on top of IEEE 802.15.4, is REQUIRED as the basis for IPv6 header compression on top of Bluetooth LE. All headers MUST be compressed according to RFC 6282 encoding formats.
To enable efficient header compression, when the 6LBR sends a Router Advertisement, it MAY include a 6LoWPAN Context Option (6CO)
matching each address prefix advertised via a Prefix Information Option (PIO) for use in stateless address autoconfiguration.
Note that 6CO is not needed for context-based compression when the context is pre-provisioned or provided by out-of-band means
as, in these cases, the in-band indication (6CO) becomes superfluous.
The specific optimizations of for header compression, which
exploited the star topology and Address Registration Option (ARO) (note that the latter has been updated by EARO as per ), cannot be generalized in an IPv6
mesh over Bluetooth LE links. Still, a subset of those optimizations
can be applied in some cases in such a network. These cases comprise link-local interactions, non-link-local packet
transmissions originated by a 6LN (i.e., the first hop from a 6LN), and non-link-local
packets intended for a 6LN that are originated or forwarded by a neighbor
of that 6LN (i.e., the last hop toward a 6LN). For all other packet transmissions, context-based compression MAY be used.
When a device transmits a packet to a neighbor, the sender MUST fully elide the source Interface Identifier (IID) if the source IPv6 address is the link-local address based on the sender's Bluetooth device address (SAC=0, SAM=11). The sender also MUST fully elide the destination IPv6 address if it is the link-local address based on the neighbor's Bluetooth device address (DAC=0, DAM=11).
When a 6LN transmits a packet with a non-link-local source address
that the 6LN has registered with EARO in the next-hop router for the
indicated prefix, the source address MUST be fully elided if it is
the latest address that the 6LN has registered for the indicated
prefix (SAC=1, SAM=11).
If the source non-link-local address is not
the latest registered by the 6LN and the first 48 bits of the IID match
the latest address are registered by the 6LN, then the last 16 bits of the IID
SHALL be carried inline (SAC=1, SAM=10). Otherwise, if the first 48 bits of the IID do not match,
then the 64 bits of the IID SHALL be fully carried inline (SAC=1, SAM=01).
When a router transmits a packet to a neighboring 6LN with a non-link-local destination address, the router MUST fully elide the
destination IPv6 address if the destination address is the latest
registered by the 6LN with EARO for the indicated context (DAC=1,
DAM=11). If the destination address is a non-link-local address and
not the latest registered and if the first 48 bits of the IID match those of the latest registered address,
then the last 16 bits of the IID SHALL be carried inline (DAC=1, DAM=10). Otherwise, if the first 48 bits of the IID do not match,
then the 64 bits of the IID SHALL be fully carried in-line (DAC=1, DAM=01).
Unicast and Multicast Mapping
The Bluetooth LE Link Layer does not support multicast. Hence,
traffic is always unicast between two Bluetooth LE neighboring nodes.
If a node needs to send a multicast packet to several neighbors, it has
to replicate the packet and unicast it on each link. However, this may
not be energy efficient, and particular care must be taken if the node
is battery powered. A router (i.e., a 6LR or a 6LBR) MUST keep track
of neighboring multicast listeners, and it MUST NOT forward multicast
packets to neighbors that have not registered as listeners for multicast groups to which the packets are destined.
IANA Considerations
This document has no IANA actions.
Security Considerations
The security considerations in apply.
IPv6 mesh over BLE requires a routing protocol to
find end-to-end paths. Unfortunately, the routing protocol may
generate additional opportunities for threats and attacks to the
network.
RFC 7416 provides a systematic overview of threats and
attacks on the IPv6 Routing Protocol for Low-Power and Lossy Networks
(RPL), as well as countermeasures. In that document, described threats and attacks comprise threats due to failures to authenticate, threats due to failure to keep routing information, threats and attacks on integrity, and threats and attacks on availability. Reported countermeasures comprise
confidentiality attack, integrity attack, and availability attack countermeasures.
While this specification does not
state the routing protocol to be used in IPv6 mesh over Bluetooth LE
links, the guidance of is useful when RPL is used in
such scenarios. Furthermore, such guidance may partly apply for
other routing protocols as well.
The ROVR can be derived from the Bluetooth device address. However, such a ROVR can be
spoofed; therefore, any node connected to the subnet and aware of
a registered-address-to-ROVR mapping could perform address theft and
impersonation attacks. Use of Address Protected Neighbor Discovery provides protection
against such attacks.
ReferencesNormative ReferencesCore Specification 4.2BluetoothInternet Protocol Support Profile 1.0BluetoothKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.IP Version 6 Addressing ArchitectureThis specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses.This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK]Neighbor Discovery for IP version 6 (IPv6)This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK]Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based NetworksThis document updates RFC 4944, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks". This document specifies an IPv6 header compression format for IPv6 packet delivery in Low Power Wireless Personal Area Networks (6LoWPANs). The compression format relies on shared context to allow compression of arbitrary prefixes. How the information is maintained in that shared context is out of scope. This document specifies compression of multicast addresses and a framework for compressing next headers. UDP header compression is specified within this framework. [STANDARDS-TRACK]Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)The IETF work in IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) defines 6LoWPANs such as IEEE 802.15.4. This and other similar link technologies have limited or no usage of multicast signaling due to energy conservation. In addition, the wireless network may not strictly follow the traditional concept of IP subnets and IP links. IPv6 Neighbor Discovery was not designed for non- transitive wireless links, as its reliance on the traditional IPv6 link concept and its heavy use of multicast make it inefficient and sometimes impractical in a low-power and lossy network. This document describes simple optimizations to IPv6 Neighbor Discovery, its addressing mechanisms, and duplicate address detection for Low- power Wireless Personal Area Networks and similar networks. The document thus updates RFC 4944 to specify the use of the optimizations defined here. [STANDARDS-TRACK]IPv6 over BLUETOOTH(R) Low EnergyBluetooth Smart is the brand name for the Bluetooth low energy feature in the Bluetooth specification defined by the Bluetooth Special Interest Group. The standard Bluetooth radio has been widely implemented and available in mobile phones, notebook computers, audio headsets, and many other devices. The low-power version of Bluetooth is a specification that enables the use of this air interface with devices such as sensors, smart meters, appliances, etc. The low-power variant of Bluetooth has been standardized since revision 4.0 of the Bluetooth specifications, although version 4.1 or newer is required for IPv6. This document describes how IPv6 is transported over Bluetooth low energy using IPv6 over Low-power Wireless Personal Area Network (6LoWPAN) techniques.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor DiscoveryThis specification updates RFC 6775 -- the Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery specification -- to clarify the role of the protocol as a registration technique and simplify the registration operation in 6LoWPAN routers, as well as to provide enhancements to the registration capabilities and mobility detection for different network topologies, including the Routing Registrars performing routing for host routes and/or proxy Neighbor Discovery in a low-power network.Address-Protected Neighbor Discovery for Low-Power and Lossy NetworksThis document updates the IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery (ND) protocol defined in RFCs 6775 and 8505. The new extension is called Address-Protected Neighbor Discovery (AP-ND), and it protects the owner of an address against address theft and impersonation attacks in a Low-Power and Lossy Network (LLN). Nodes supporting this extension compute a cryptographic identifier (Crypto-ID), and use it with one or more of their Registered Addresses. The Crypto-ID identifies the owner of the Registered Address and can be used to provide proof of ownership of the Registered Addresses. Once an address is registered with the Crypto-ID and a proof of ownership is provided, only the owner of that address can modify the registration information, thereby enforcing Source Address Validation.Informative ReferencesCore Specification 4.1BluetoothMulti-Link Subnet IssuesThere have been several proposals around the notion that a subnet may span multiple links connected by routers. This memo documents the issues and potential problems that have been raised with such an approach. This memo provides information for the Internet community.A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs)This document presents a security threat analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs). The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low-power and lossy networks. A systematic approach is used in defining and evaluating the security threats. Applicable countermeasures are application specific and are addressed in relevant applicability statements.Bluetooth LE Connection Establishment Example
This appendix provides an example of Bluetooth LE connection establishment and use of IPSP roles in an IPv6 mesh over BLE that uses dynamic configuration. The example follows text in Section 3.3.2, item 3.b.
The example assumes a network with one 6LBR, two 6LRs, and three 6LNs, as shown in . Connectivity between the 6LNs and the 6LBR is only possible via the 6LRs.
The following text describes the different steps in the example as time evolves. Note that other sequences of events that may lead to the same final scenario are also possible.
At the beginning, the 6LBR starts running as an IPSP router, whereas the rest of devices are not yet initialized (Step 1). Next, the 6LRs start running as IPSP nodes, i.e., they use Bluetooth LE advertisement packets to announce their presence and support of IPv6 capabilities (Step 2).
The 6LBR (already running as an IPSP router) discovers the presence of the 6LRs and establishes one Bluetooth LE connection with each 6LR (Step 3). After establishment of those link-layer connections (and after reception of Router Advertisements from the 6LBR),
the 6LRs start operating as routers and also initiate the IPSP Router role (Step 4). (Note: whether the IPSP Node role is kept running simultaneously is an implementation decision). Then, 6LNs start running the IPSP Node role (Step 5).
Finally, the 6LRs discover the presence of the 6LNs and establish connections with the latter (Step 6).
Node-Joining Procedure
This appendix provides a diagram that illustrates the node-joining procedure. First of all, the joining node advertises its presence in order to allow establishment of Bluetooth LE connections with neighbors that already belong to a network. The neighbors typically run as a 6LR or as a 6LBR. After Bluetooth LE connection establishment, the joining node starts acting as a 6LN.
shows the sequence of messages that are exchanged by the 6LN and a neighboring 6LR that already belongs to the network after the establishment of a Bluetooth LE connection between both devices. Initially, the 6LN sends a Router Solicitation (RS) message (1). Then, the 6LR replies
with an RA, which includes the PIO (2). After discovering the non-link-local prefix in use in the network, the 6LN creates its non-link-local address and registers that address with EARO (3) in the 6LR, and then multihop DAD is performed (4).
The next step is the transmission of the NA message sent by the 6LR in response to the NS previously sent by the 6LN (5).
If the non-link-local address of the 6LN has been successfully validated, the 6LN can operate as a member of the network it has joined.
Acknowledgements
The Bluetooth, Bluetooth Smart, and Bluetooth Smart Ready marks are registered trademarks owned by Bluetooth SIG, Inc.
The authors of this document are grateful to all authors of , since this document borrows many concepts (albeit with necessary extensions) from .
The authors also thank , , , , , , , ,
and for their reviews and comments, which helped improve the document.
has been supported in part by the Spanish Government Ministerio de Economia y Competitividad through projects TEC2012-32531,
TEC2016-79988-P, PID2019-106808RA-I00, and FEDER and Secretaria d'Universitats i Recerca del Departament d'Empresa i Coneixement de la Generalitat
de Catalunya 2017 through grant SGR 376.
Contributors (Graz University of Technology) contributed to the design and validation of this document.
Authors' AddressesUniversitat Politecnica de CatalunyaC/Esteve Terradas, 708860CastelldefelsSpaincarlesgo@entel.upc.eduUniversitat Politecnica de CatalunyaC/Esteve Terradas, 708860CastelldefelsSpainsm.darroudi@entel.upc.eduUnaffiliatedtsavo.stds@gmail.comGraz University of TechnologyInffeldgasse 16/IGraz8010Austriamichael.spoerk@tugraz.at