Linköpings universitet SE–581 83 Linköping
Linköping University | Department of Computer and Information Science
Master’s thesis, 30 ECTS | Datateknik
2019 | LIU-IDA/LITH-EX-A--19/029--SE
A Data Collection Framework for
Bluetooth Mesh Networks
Ett datainsamlingsramverk för Bluetooth Mesh nätverk
Simon Karlsson
Examiner : Petru Eles
Upphovsrätt
Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publicer-ingsdatum under förutsättning att inga extraordinära omständigheter uppstår.
Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka ko-pior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervis-ning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säker-heten och tillgängligsäker-heten finns lösningar av teknisk och administrativ art.
Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsman-nens litterära eller konstnärliga anseende eller egenart.
För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.
Copyright
The publishers will keep this document online on the Internet - or its possible replacement - for a period of 25 years starting from the date of publication barring exceptional circumstances.
The online availability of the document implies permanent permission for anyone to read, to down-load, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility.
According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.
For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.
Abstract
This thesis presents a framework for collecting network traffic data usable in perfor-mance evaluations of Bluetooth Mesh networks. The framework is designed to be adap-tive, effecadap-tive, and efficient. These design goals are intended to minimize resource usage and thereby take constraints in Bluetooth Mesh into account. An implementation of the framework, based on the Bluetooth Mesh model concept, is also presented. The implemen-tation is then validated and evaluated to analyse to what degree it fulfills the requirements of adaptive, effective, and efficient data collection. The evaluation demonstrates the im-portance of minimizing the size of the reports sent in the framework since larger messages sent with short intervals have a noticeable effect on both the packet delivery ratio of user traffic and the reporting latency. It is also shown that the adaptive reporting feature, that aims to reduce the effect of the framework on user traffic by postponing reporting during high traffic loads, has a positive effect on neighboring nodes overall packet delivery ratio.
Acknowledgments
I would like to thank my supervisors at Ericsson, Wei Shen and Thomas Rimhagen, and my examiner Petru Eles.
Linköping, June 2019 Simon Karlsson
Contents
Abstract iii
Acknowledgments iv
Contents v
List of Figures vii
List of Tables viii
1 Introduction 1 1.1 Motivation . . . 2 1.2 Aim . . . 2 1.3 Research questions . . . 2 1.4 Delimitations . . . 2 2 Theory 3 2.1 Wireless mesh networks . . . 3
2.2 Bluetooth Mesh . . . 5
2.3 Network monitoring . . . 8
2.4 Data collection in sensor networks . . . 11
2.5 Summary . . . 13 3 Design 14 3.1 Overview . . . 14 3.2 Constraints . . . 14 3.3 Requirements . . . 16 3.4 Traffic measurements . . . 17
3.5 Data exporting and collection . . . 18
4 Implementation 20 4.1 Overview . . . 20
4.2 Traffic measurements . . . 20
4.3 Data exporting and collection . . . 22
5 Evaluation 27 5.1 Evaluation methods . . . 27 5.2 Evaluation result . . . 31 6 Discussion 37 6.1 Implementation . . . 37 6.2 Evaluation results . . . 38 6.3 Design . . . 40 6.4 Evaluation method . . . 42
6.5 The work in a wider context . . . 42
7 Conclusion 43
7.1 Future work . . . 43
List of Figures
2.1 Hybrid mesh network . . . 4
2.2 Bluetooth Mesh stack . . . 6
2.3 Bluetooth Mesh network . . . 7
3.1 System overview . . . 15
3.2 Coverage metric . . . 17
3.3 Communication overview . . . 19
4.1 Collector and observer communication . . . 21
4.2 Interaction with the Bluetooth Mesh stack . . . 21
4.3 Flowchart of adaptive reporting . . . 24
4.4 Relationship between incoming packet rate and PDR . . . 25
4.5 The resulting function used to predict PDR based on incoming packet rate . . . 26
5.1 Background noise overheard on advertising bearer . . . 28
5.2 Stack utilization of a collector node . . . 32
5.3 Stack utilization of an observer node . . . 32
5.4 Reporting interval’s effect on PDR . . . 33
5.5 Report size’s effect on PDR . . . 33
5.6 Report size’s effect on delay, 1-hop transmission . . . 34
5.7 Report size’s effect on delay, 2-hop transmission . . . 34
5.8 Reporting in passive mode . . . 35
5.9 Reporting in adaptive mode . . . 36
List of Tables
3.1 System on Chip constraints . . . 15
3.2 Advertisement data packet . . . 15
4.1 Flow table entry . . . 22
4.2 Measurement report . . . 23
4.3 RMSE of the PDR models . . . 24
4.4 Configuration message . . . 26
5.1 Configurations in report interval experiment . . . 29
5.2 Configurations in report size experiment . . . 29
5.3 Configurations in report latency experiments . . . 29
5.4 Configurations in passive reporting experiment . . . 30
5.5 Configurations in adaptive reporting experiment . . . 30
5.6 Static memory usage on a collector node . . . 31
5.7 Static memory usage on an observer node . . . 31
1
Introduction
Internet of Things, IoT, the network created when previously unconnected devices are con-nected, is already widely used but also expanding[1]. IoT offers promising ways to improve both daily life and industry with automation and augmentation[2].
An example of an IoT application that can improve our daily life is a smart home. The smart home includes, for example, lights with the capability to communicate and be con-trolled remotely. This allows them to be turned on and off, without the need for a physical switch, or according to a schedule decided by the homeowner. The lights could also be used to relay data to other devices that are a part of the network in the home.
IoT solutions also exist for healthcare and industrial applications. For example, allowing doctors to track patients health while the patient is at home. This health data can be sent to the patient’s doctor using sensors on or around the patient that communicate with a patient journal system via a gateway, across the Internet. Another application can be environment monitoring in, for example, a mine or a similar place with hazardous working conditions. Sensors can be deployed throughout the working area to detect potential threats to the work-ers’ safety and alert the workers so that disasters can be avoided.[3]
Due to the large number of devices that make up the IoT, a proportional amount of net-work traffic will be generated. The data describing this traffic is interesting in and of itself and, therefore, part of the future of IoT will involve collecting and analyzing this data[1][4]. This data can be used for different types of network monitoring use cases. For example, se-curity analysis to detect potential intruders with malicious intent in the network. The data is also of interest when determining network performance. The performance evaluation can then be used to motivate modifications of the network to, for example, increase the reliability or reduce transmissions delays.
The devices that are part of the IoT, such as the previously mentioned smart lights or sen-sors, are often embedded devices with limited resources. Due to their size and placement restrictions the devices often have constraints on both their local attributes such as the avail-able memory, processing capabilities, and power consumption. This in turn also affects the communication between them. Some examples of communication protocols that are suited for IoT are Thread, Zigbee, and Bluetooth Mesh. These protocols employ techniques to re-duce energy consumption and also utilize the mesh networking functionality to allow devices to act as relays and therefore extending the communication range.
1.1. Motivation
1.1
Motivation
There is currently no established approach to collecting network traffic data in a Bluetooth Mesh network. This kind of collection framework would enable network performance eval-uations. These evaluations can then be used as a basis for either re-configuring the network parameters or redeployment of the nodes in the network. It can also allow for network opti-mization and, depending on the goal, minimize latency, power consumption, etc. This kind of functionality is of interest in most networks, and especially in networks where there are limiting constraints that must be taken into account when configuring them so that the net-works can work as intended.
1.2
Aim
The goal of this thesis is to present a framework for collecting network traffic data in a Blue-tooth Mesh network. The framework should be designed in such a way that the identified constraints that appear in Bluetooth Mesh networks and on embedded devices in these net-works are taken into account. These constraints are identified through studying relevant liter-ature discussing mesh networks, data collection in networks consisting of embedded devices, and investigating technologies used in Bluetooth Mesh networks. The framework should also be designed based on state-of-the-art network monitoring tools and what is considered im-portant factors in these kinds of tools. The framework is to be implemented following the design and later evaluated where the evaluation is based on the constraints and the relevant literature identified previously.
1.3
Research questions
1. What constraints are present in a Bluetooth Mesh network? 2. What are the important attributes of data collection frameworks?
3. How can network traffic data be collected in a Bluetooth Mesh network in such a way that the recognized constraints and attributes are taken into account?
1.4
Delimitations
This thesis was done at Ericsson Research in Linköping. The implementation is built on top of an extended version of the Bluetooth Mesh 1.0 stack from Nordic Semiconductor. The implementation was tested using System on Chips called nRF52840, also from Nordic Semi-conductor, in an office environment at the Ericsson site in Linköping.
2
Theory
This chapter first presents the wireless mesh network concept in section 2.1. Section 2.1 tries to describe how wireless mesh networks function and what makes them different from other network topologies. Section 2.2 describes the Bluetooth Mesh architecture and protocol. Sec-tion 2.3 presents different approaches, protocols, and mechanisms that enable the observing and collection of data in networks. It also covers potential uses for the gathered data. Section 2.3 also presents desirable attributes of data collection frameworks that can be used as a ba-sis for design and evaluation. The subsequent section, section 2.4, describes different ways of collecting data in a sensor network that take constraints on energy consumption, process-ing capabilities, and memory usage into account. Finally section 2.5 presents a summary of the chapter and some of the most important information that is necessary to understand the thesis.
2.1
Wireless mesh networks
A Wireless Mesh Network, WMN, is a network using wireless communication technologies and where the network is structured according to the mesh topology. The mesh topology implies that each node in the network is connected to as many other nodes as possible. In the case where all nodes are connected the network is referred to as a fully meshed network. Using wireless communication to realize a mesh network is more feasible compared to wired connections which would result in a large number of wires. In a mesh network nodes can function as relays for messages not directed towards them. Two nodes not in range of each other utilize this by sending their messages to nodes within range that then forward the messages per the routing algorithm used. This way of communicating is referred to as multi-hop communication.
One example of a routing algorithm that can be used in a WMN is flooding. Flooding is a relatively simple approach with low overhead. In a network utilizing flooding, messages are forwarded to all nodes in range until a criterion is met, for example, the number of hops has reached the maximum allowed value. Flooding is however not always as efficient as other routing protocol, due to the number of extra messages sent.[5]
Although a mesh network is generally without hierarchy, literature often divides the mesh nodes into groups based on their capabilities[6][7]. The groups can be represented by mesh clients and mesh routers. Mesh routers are mesh nodes that make up the core of the
net-2.1. Wireless mesh networks Mesh Router Mesh Client Mesh Router Mesh Router Mesh Router Mesh Router Internet Mesh Client Mesh Client Mesh Client
Figure 2.1: Hybrid mesh network
work. They can be nodes that are more or less static in their placement and connected to an external power source and therefore not have the same energy restrictions as other nodes. Mesh routers can also work as gateways between different networks. For example, connect-ing a mesh network usconnect-ing Bluetooth Mesh technology to the Internet. Compared to the mesh routers a mesh client often has power consumption constraints. Although the nodes have the functionality to relay network traffic this may be sub-optimal due to the extra strain placed on the nodes. Therefore, routing algorithms may use the node type as a factor when calculating the optimal path through the network.
Akyldiz et al.[6] also presents three different types of WMN architectures. The first one is infrastructure WMNs. In this architecture, the mesh routers make up the actual mesh network. It allows mesh clients to connect using the same technology as the routers as usual, or there can also be clients connected to the mesh network via, for example, Ethernet.
The second presented architecture is client WMNs. In client WMNs the clients themselves make up a peer-to-peer mesh network. In addition to providing end-user applications, the clients also handle all the routing through the network. Due to there not being any gateway functionality this architecture only utilizes one communication technology. The client WMNs also have higher demands on the client devices due to their extra functionality.
The last architecture presented is hybrid WMNs. The hybrid WMN is a combination of the two previous architecture and perhaps the most common. It utilizes aspects of both architectures by having a network backbone made up of mesh routers that can connect the mesh network with other networks with potentially different communication technologies. The traffic in the network is then preferably routed through the network backbone. However, hybrid WMNs can also route traffic through client nodes to achieve better network coverage. Figure 2.1 shows an example of a hybrid mesh network.
Some characteristic properties of WMNs are self-configuration and self-healing. Self-configuration refers to the fact that mesh networks are realized with protocols that make the network need little or no installation which in turn makes them easy to deploy. Self-healing means that loss of a node in a mesh network will not lead to the failure of the entire network. Instead, paths that used said node will simply be replaced by alternatives or recalculated by
2.2. Bluetooth Mesh
the routing algorithms used. Both these properties reflect the high degree of autonomy that is one critical design factor for mesh network[6]. These properties also make a wireless mesh network robust and reliable.
2.2
Bluetooth Mesh
Bluetooth Mesh[8] is a low-power communication protocol that enables mesh networking us-ing Bluetooth technology. Bluetooth Mesh is designed to enable one-to-many transmissions of messages. Messages can also be relayed by nodes to greatly increase the communication range. It is, much like other mesh networking technologies, not dependant on a single node and can, therefore, continue to function after one or more nodes are removed from the net-work.
The current version of Bluetooth Mesh uses a fairly simple approach to message routing called managed flooding. A node broadcasts a message and other nodes can relay this mes-sage until it reaches the destination or the mesmes-sage has been relayed too many times and is therefore dropped. The network determines the number of times a message has been relayed by checking the time-to-live, TTL, value. It is a number that is reduced by every node that relays the message, and when this value reaches zero the message is dropped by the decre-menting node. Nodes can also cache a message to ensure that the same message is not relayed multiple times.
The functionality of a node in a Bluetooth Mesh network is defined by different models. There are foundation models that are needed at every node to enable the configuration of that node. There are also models that represent specific use cases, for example, turning a light on and off. The models are logical blocks that exist within an element. A node in the network can contain several elements, each with its own network address. This allows a single physical node to contain several separate instances of the same kind of model. For example, a node can contain several models used to turn on and off lights, one for each light to control.
The configuration of the network is handled by a specific node called a provisioner. When a node is unconfigured and wants to join a mesh network it continuously sends out messages notifying listeners that it is currently unprovisioned. When a provisioner overhears one of these messages it starts the provisioning procedure with this node. The provisioner provides the node with the necessary keys, for example, a network key, that enables the provisioned node to communicate with the rest of the network. The provisioner also assigns the nodes primary element an address. Each subsequent element in this node is then assigned the subsequent address.
Bluetooth Low Energy
Bluetooth Mesh is built on top of Bluetooth Low Energy[9], BLE. As its name implies BLE’s goal is to reduce energy consumption while not sacrificing throughput. BLE allows two kinds of communication between Bluetooth devices, advertisements, and connections. All commu-nication uses the 2.4 GHz Industrial, Scientific, and Medical, ISM, band. BLE commucommu-nication uses 40 different 2 MHz channels on this band. Three of these channels are used for adver-tisements to broadcast messages. The rest are used for connections between devices which introduces some setup time but achieves a much faster data transfer rate.
Bluetooth Mesh uses the three advertisement channels to communicate. This causes higher power consumption but lower end-to-end delay compared to options that use other approaches according to Murill et al.[10]. The downside of the higher power consumption is a result of mesh nodes being required to scan for broadcasted messages with a duty cycle of almost 100%. This requirement exists to guarantee the reliability of message transfers. The use of the advertisement channels also results in a simpler implementation since it doesn’t require each node to continuously keep track of and update entries in a table consisting of connections for each of its neighboring nodes.
2.2. Bluetooth Mesh
Model Layer
Foundation Model Layer
Access Layer
Upper Transport Layer
Lower Transport Layer
Network Layer
Bearer Layer
BLE Link & Physical Layer
Figure 2.2: Bluetooth Mesh stack
Architecture and networking
The Bluetooth Mesh stack consists of 7 layers in total. The lowest layer that is placed above the BLE Core stack is the bearer layer. It is followed by the network layer, lower transport layer, upper transport layer, access layer, foundation model layer, and then at the highest level of abstraction, the model layer. The stack layout is shown in figure 2.2 and the functionality of each layer is described below.
• The model layer contains different models that represent different use cases. For exam-ple, there is one model that implements the basic functionality needed to turn lighting on and off.
• The foundation model layer is similar to the model layer and also contains different mod-els. The difference is that this layer contains models that are necessary for the network to be configured and managed. For example, the configuration and health models. • The access layer handles the communication between the model layers and the upper
transport layer. It controls the format of the application data and verifies that messages from lower layers are received by the correct model at the correct node. This is done by checking whether the model ID is correct and if the destination address of the message is the address of the element the model is a part of, or if the address is one subscribed to by the model.
• The upper transport layer handles encryption, decryption, and authentication of appli-cation data. It also handles transport layer control messages, such as the ones used to establish a friend connection.
• The lower transport layer segments and reassembles upper transport layer messages. Any upper transport Protocol Data Unit, PDU, larger than 15 octets is segmented into several lower transport layer PDU’s. This procedure is performed in the same way independent of the message being a control or access message.
• The network layer handles the addressing of transport messages and also the network level encryption and decryption of these messages. It is also the network layer that decides whether a received message is relayed, sent up through the stack or rejected. This layer also keeps a message cache to avoid relaying or processing messages that the node has already seen.
2.2. Bluetooth Mesh Relay Node Relay Relay Relay Friendship Friend node Node Proxy Node Node Low power node Proxy connection GATT node
Figure 2.3: Bluetooth Mesh network
• The bearer layer defines how the underlying BLE Core implementation is used to transfer messages. It currently defines two types of bearers, the advertising bearer, and the GATT bearer. The advertising bearer is the standard bearer used to communicate in the mesh network. It sends mesh packets wrapped in a BLE advertising PDU. A special advertising data type is used in the header of this PDU to identify it as a mesh packet. To reduce the risk of missing a mesh packet a Bluetooth Mesh device passively scans the advertisement channels as much as possible. The second bearer, the GATT bearer is used to communicate with devices that don’t implement Bluetooth Mesh.
Bluetooth Mesh introduces different roles that describe the functionality of the node. The roles are relay, proxy, low power, and friend. A node can take on one or more of these roles. A node with the relay role is capable of relaying messages to extend the network range. A relay node consumes more power than one that does not relay messages and is, therefore, preferably a node with an external power supply. A proxy node is a node that can commu-nicate with a Bluetooth device not supporting the advertising bearer and instead uses the GATT bearer as described above. The proxy nodes can connect this device to the mesh net-work even though the device lacks mesh capabilities. A low power node is a node that might lack an external power source or for some other reason can’t be active at all times. The low power node, therefore, bypasses the requirement of having to scan for messages all the time. However, the low power node needs a friend node that will collect messages directed to the low power node to guarantee that it will still receive all messages sent to it. The low power node polls this friend node to be notified of any intercepted messages. The interception and storage of these extra messages, of course, puts a greater strain on the friend node and it should, therefore, preferably be a node that has access to an external power supply.[8]
Figure 2.3 shows a Bluetooth Mesh network made up of nodes with the described roles and their relationships.
2.3. Network monitoring
Models
A model determines the functionality of a node. A node is not restricted to a single model but can implement several models at once. For example, a node can implement both a model that allows it to function like a light switch but also a model that allows it to measure a sensor value. If several instances of the same model are needed at a node the model instances need to be assigned to separate elements of that node so that they can be addressed separately. Models are either servers, that record states and respond to requests, clients, that are stateless and send requests to servers, or control models that contain parts from both the server and client models with additional control logic.
Models generally communicate in a publish-subscribe paradigm. Each model has a single publish address which it sends all its messages to. A model can subscribe to several group or virtual addresses and will then receive messages directed to these addresses. This enables a model to broadcast messages to several receivers by setting its publish address to a group address.
The Bluetooth Mesh specification defines some general models such as a sensor model. To implement specific behaviour these models can either be extended or new custom mod-els can be created. There are however some modmod-els, so-called foundation modmod-els, that are needed to configure and manage the network. These models are, for example, the Config-uration Client and Server models that are used to configure nodes in the network. Another pair of foundation models is the Health Client and Server models that are used for network diagnostics.[8][11]
2.3
Network monitoring
This section covers different aspects of collecting traffic data in a network. Network monitor-ing is divided into three parts. Packet observation and data generation, data exportmonitor-ing and collection, and data analysis. This section also identifies some important attributes of data collection frameworks.
Packet observation and data generation
Packets are observed at an observation point in the network. The observation point can, for example, be a switch or a router in the network, it can also be a dedicated device that only performs this task. Data is then generated from the observed packets. There are three main approaches to this observation process. Packet based, flow based or log based observa-tions.[12]
Packet based data
The packet based approach captures unique packets. This results in very detailed data but might also include unnecessary data for some use cases if the data generation from these packets is not done properly. For instance, recording encrypted application payloads is not needed to perform an analysis of the network’s performance. The volume of data generated is also proportionally high compared to the traffic which may influence the performance of the observation device and also the network traffic conditions during the exporting proce-dure. In networks with a high traffic load, the capturing process may also be unable to keep up with the traffic load, resulting in data that reflects the actual traffic poorly. This problem can be mitigated by using packet sampling methods that reduce the amount of data gener-ated. There are however also risks with packet sampling if the sampling method is poorly designed, since it might favour periodic traffic and therefore not reflect the true traffic condi-tions[12].
PSAMP[13] is one instance of a protocol that uses packet sampling. It allows for mod-ifiable sampling methods. It can, for example, be configured to use systematic time-based
2.3. Network monitoring
sampling where packets are sampled periodically. There are also approaches that randomly choose a specified number of packets out of a larger set, or an approach that is based on a uniform probability so that each packet has the same probability of being sampled.
A traffic data collection technology that uses packet sampling is sFlow[14]. The logical entity within the sFlow technology that performs the data generation by sampling packets is called an sFlow Agent. This agent is installed as a part of the router or switch where you want to make traffic measurements. To generate data, sFlow uses two types of sampling methods, Packet Flow sampling, and Counter sampling. When using Packet Flow sampling packets are sampled based on a counter that is decremented each time a packet is observed. When this counter reaches zero that packet is sampled and the counter is reset to a random value such that the specified sampling rate is achieved. Another approach to the same Packet Flow sampling method is that a random number is generated for each packet and then compared to a threshold that determines whether the packet is sampled or not. The second method, Counter sampling, samples the counters of device interfaces to acquire data about the number of received and transmitted packets. This sampling is done within a specified sampling time-interval.
Packet based data observations can be further categorized into two different approaches. An observation entity can either passively observe the traffic in the network or it can actively make measurements by introducing probing packets into the traffic.
An example of the passive packet capturing approach can be found in applications often referred to as packet sniffers. A prominent example of this is Wireshark. To give a better view of the whole network without having to install these packet sniffers at each device, one can configure the network in such a way that network traffic is re-routed through the device running one of these packet sniffers[15]. Compared to passive observation, active measurements can be used to generate data that would not necessarily be available otherwise. An example of this is the round-trip-time, RTT, of messages between specified devices. Flow based data
Instead of capturing unique packets the flow based approach captures flows. A flow is made up of packets that share a set of common properties, for example, destination and source address, destination and source ports, and the protocol used[16][17]. This information is usually extracted from packet headers and the payload doesn’t need to be examined which leads to faster processing of the packets. Flow based data is less detailed compared to packet based data but this approach is much better equipped to handle high network traffic loads since less data is generated and it is generated faster[18]. The recorded flows are stored in a flow table at the observing device. The observer can use different flow expiration mechanisms to limit the size of the table. For example, if a packet for a specific flow has not been received in 5 seconds that flow is evicted from the table to make room for another flow.
One example of a flow capturing protocol is YAF[19]. It identifies a flow with flow keys. The flow keys consist of the source and destination addresses and ports, the protocol used, and the IP version number. The flows are stored in a flow table that is implemented as a hash table paired with a queue. A flow table entry can, therefore, easily be accessed using the hash of the flow key. The queue is used to determine what flows are idle since when a packet is received and a flow updated that entry is moved to the head of the queue and, therefore, the last entries of the queue are those who have been idle the longest. This information can then be used to evict entries if they have been idle for longer then the allowed idle expiration time. Each flow also has an active expiration time that is checked each time a flow is updated and if the time has expired the entry is evicted. When an entry is evicted it is also exported to a collecting entity.
2.3. Network monitoring
Log based data
Log based data recording uses the log files that many devices are configured to generate during run-time. The logs can be, for example, event or message logs recorded at a router in the network, or logs from network edge devices. The difference between this approach and the two previously mentioned is that there is no dedicated observation device. The logs also contain very detailed data and of a greater volume than the two previous approaches generate. This makes them troublesome to manually analyse and one has to employ methods such as machine learning or parse the logs with methods based on expert knowledge. One example of a log based network monitoring application is described in a paper by Qui et al.[20]. They use system logs from routers in a network and apply data mining techniques to these logs to make conclusions about the network behaviour.
Data exporting and collection
After the data generated from the observed packets have been stored at an observation point this data then needs to be transferred to a collector entity that other observation points also send their data to. There are different approaches to both how to transfer the generated data to a collector and also when to do this. More frequent transmissions will provide more timely updates which may allow for real-time analysis in the data analysis part. Less frequent transmissions instead lead to a reduced load on both the exporting and collecting entity.
The sFlow technology collects data by first having the sFlow Collector write an entry into the sFlow Agents receiver table. This entry needs to be continually updated by the collector to ensure that it will receive data from the agent. The collector can also, once it has a corre-sponding entry, configure the agent and specify the size limit of messages sent from the agent. It can also configure what these messages’ destination address and port should be. Once the agent then samples the traffic it transmits this to the collector with limited buffering of several samples into one message to provide timely reporting. The messages are transmitted using an unreliable transport protocol which may lead to missing samples.[14]
There exist several protocols that specify how network traffic data recorded as flows should be exported and collected. One of them is NetFlow version 9. The NetFlow specifica-tion[16] describes how and when the transfer of data from an observer should be performed. The observer can export data about a flow if it can determine that the flow has ended by detecting a packet indicating this. Flow data can also be exported if the observer determines that it is running out of free memory in the flow table. The transmission is also initiated by the expiration of timeouts. If a flow has either been inactive or active for too long that flow data will also be exported. These timeouts are configurable at the observer sending data. Similar to sFlow, NetFlow uses an unreliable transport protocol for the transmissions. One interesting feature of NetFlow is that it specifies templates for the exported message which allows the exporting entity to modify what data is sent which makes the whole protocol more usable since introducing new fields in the message doesn’t require a specification update.
Another similar protocol, compared to NetFlow, is IPFIX[17]. It is based on NetFlow version 9 and therefore shares some of its features. For instance, it also provides the same kind of template messages. One key difference is that IPFIX, although it supports unreliable transport, can use reliable transmission of the exported data.
Although it isn’t primarily used for network monitoring, another protocol of interest is OpenFlow[21]. OpenFlow is used to create Software Defined Networks, SDNs. In an SDN a central controller can decide how traffic is routed in the network using OpenFlow to config-ure the network switches. Since traffic data is of interest when configuring an SDN, Open-Flow provides access to the same type of flow data collected at switches as the previously mentioned protocols.
One example of a monitoring framework using OpenFlow is presented by Chowdhury et al.[22]. Their monitoring framework adapts its collection rate to the use case. The collector
2.4. Data collection in sensor networks
in the framework uses OpenFlow to communicate with switches in the network. For new flows, the switch will send a packet for this flow in a message to the collector which will then record this new flow and also set an initial timeout for this flow. If the flow ends before the timeout the collector will simply use the message automatically transmitted from the switch with data of the flow to update its local entry. If no data is received before the timeout the framework instead sends out a flow statistics request to the switch. The entry for the flow at the collector is then updated with the statistics reply from the switch. The collector can then calculate how many bytes have been transmitted in this flow since the last update and modify the local timeout accordingly so that, for example, higher traffic flows are polled more frequently.
Data analysis
When the data from all relevant observation points have been gathered at the collector it is possible to process this data and analyse it. Application areas for this data can be in, for example, security and threat detection. In these cases, the data can be analysed to identify anomalies that might indicate a malicious entity in the network. Another application area is performance monitoring of the network. Here the gathered data can be used to, for exam-ple, determine if parts of the network suffer from load balancing issues or poor coverage by comparing data from different observers.
Yang et al.[23] describe in their paper a monitoring application that collects flow data us-ing NetFlow version 9. They then store this data in a database at the collector. They aggregate some flows to reduce the amount of data. The data in the database is then made accessible to a server that performs flow analysis and generates statistics from the data which can be accessed by the user.
Evaluation of a network monitoring framework
Zhou et al.[12] present a way to evaluate different data collection frameworks in their sur-vey. They present certain criteria that are required by a high-quality data collection frame-work. For example, the data generation process should be as fast as possible at observing nodes so that it doesn’t risk impacting the performance of the observing entity. This process should also be efficient and at the same time provide accurate data and reduce the amount of redundant data. The collection mechanism should scale well and not suffer performance degradation if employed in larger networks. The amount of invasive traffic like traffic probes should be minimized and a passive observer is ideal. The observation and collection should also not excessively use the network and node resources. It is also preferable if the observa-tion and collecobserva-tion are in some way adaptable. Depending on different network condiobserva-tions the observation and collection will adapt to ensure the expected performance of the network. In addition to these performance criteria, the survey also mentions criteria in the informa-tion security area. The collected data should for instance not be modifiable, or accessible, by unwanted actors.
The survey concludes that many approaches expect unencrypted data, do not employ proper access control and do not explain how the authenticity of data can be verified. They also state that there is work to be done when it comes to distributed collection mechanisms and adaptive data collection.
2.4
Data collection in sensor networks
This section describes some different approaches to data collection in sensor networks. This is of interest since, although the topology may be different, sensor networks share some features with data collection in a Bluetooth Mesh network. For instance, the data is propagated to a few or a single node that collects and processes the data from several other nodes. The
2.4. Data collection in sensor networks
networks and their devices are also estimated to have similar constraints on memory and processing capabilities as well as bandwidth.
Sensor networks are often made up of several nodes i.e. the sensors, and one or more sink nodes or base stations, where the data is collected. This intrinsic feature of sensor networks causes bottlenecks close to the receiving nodes. The effects of this problem can be mitigated in many different ways.
One approach, presented by Handy et al.[24] is to divide the network into clusters. The clusters consist of sensor nodes and each of them is assigned a role. Either they are assigned to be cluster members or cluster heads. The cluster heads act as intermediate sink nodes and collect the data from all cluster members in their specific cluster. When this task is completed it is then only the cluster head that forwards the data to the sink node. This method also enables the cluster heads to perform some preprocessing of the received data. Data can, therefore, be aggregated at the cluster heads so that no redundant data is transferred to the sink node.
The protocol, EDAL, an Energy-efficient Delay Aware Lifetime-balancing data collection protocol proposed by Yao et al.[25] utilizes the fact that the problem of collecting data from all nodes in a sensor network share many similarities with the well studied Open Vehicle Rout-ing Problem, OVRP. EDAL uses modified heuristics designed for OVRP to establish routes in the network. It also uses a technique called compressive sensing to further improve the data collection procedure. Compressive sensing exploits the fact that not all nodes in the network need to send data at the same time. This is used to further improve both the routing and the aggregation of data by modifying when and where to forward the data.
FAEM[26], a Fast Adaptive and Energy-efficient Multi-channel-multi-path data collection protocol, introduces more channels to handle the problem with bottlenecks. This protocol uses several channels to transfer the data. The channels are also assigned so that neighboring nodes do not share a receiving channel. This has the effect that interference is greatly reduced and it also enables parallel transmissions which may improve the end-to-end latency.
In addition to causing network congestion, and therefore reducing packet delivery ratio and increasing time it takes to send data in the network, the bottlenecks can also cause parts of the network to be underutilized due to the uneven load balance. Liu et al.[27] present an Adaptive Persistent M Data transmission protocol, APMD to handle this problem. In their paper, they state that an uneven load balance greatly reduces the network lifetime. Some nodes in the network may have as much as 90% of their original energy remaining when the network fails. To avoid this the protocol modifies the number of packets sent before waiting for an acknowledgment message. In network areas where there is a lot of traffic nodes send very few packets before waiting for an acknowledgment and in areas with little to no traffic, the nodes are allowed to send many more packets before being forced to wait for an acknowledgment message.
Another approach to dealing with this bottleneck problem and also use less transmission power is to use mobile nodes to transfer data from sensor nodes to sink nodes. This approach is applicable in networks that have no strict requirements on latency since the time to transfer data is increased and also becomes more unpredictable. One benefit of this approach is that it can increase the network lifetime as argued by Jain et al.[28]. Zhan et al.[29] states that by optimizing the sensor nodes sleep schedule and the trajectory of the mobile collectors this approach to data collection may in some cases be a good way to save energy. Di Francesco et al.[30] also proposes that the fewer number of hops a packet makes will decrease the chance that a packet is lost and, therefore, make this approach more reliable. They also classify these types of networks depending on what the role of the moving node is. In some cases, the mobile node may the destination of the data or in other cases mobile nodes are used as relays in areas with sparse deployment to increase reliability. They also discuss how the movement of the node will affect the network, for example, is the mobile node moving in a deterministic way or is the movement in accordance with a probabilistic model.
2.5. Summary
These types of protocols can be said to use opportunistic data collection since the nodes must detect a condition, i.e. a mobile node being within range, and then transfer data be-fore too much time has elapsed and the condition is no longer met. Other protocols with this approach are presented in Aguilar et al.[31] where they examine Opportunistic Sensor Data Collection, OSDC, using Bluetooth Low Energy, and Yang et al.[32] that presents a data collection scheme called Opportunistic Backpressure Collection, OBC.
2.5
Summary
This chapter has presented information about Bluetooth Mesh that helps in understanding the later motivation of design choices and also the implementation of the framework pre-sented in this thesis. The section covering Bluetooth Mesh introduces the architecture of the protocol and its software stack. This illuminates potential limitations from using Bluetooth Mesh, and also how and where traffic data might be observed and later processed in the soft-ware stack. The Bluetooth Mesh section also covers the model concept which is how new application layer functionality can be introduced in Bluetooth Mesh.
The network monitoring section covers different ways to record network traffic data where the most promising method is the flow based approach due too the fact that this method requires much less data to be stored to describe the traffic. This section also presents attributes that a data collection framework should possess according to Zhou et al.[12] with some examples being effectiveness, efficiency, adaptability, and scalability.
Finally, in the section discussing data collection in sensor networks, some approaches are presented. One promising approach that aims to minimize network congestion by adapting transmission rates is presented by Liu et al. [27].
3
Design
This chapter first presents an overview of the frameworks functionality, the constraints iden-tified by investigating typical hardware used in Bluetooth Mesh networks, and the Bluetooth Mesh protocol. The functional overview, the constraints, and the literature presented in the previous chapter are then used to motivate and formulate the framework’s requirements. The identified functionality needed to collect data for performance analysis of a network is divided into the areas traffic measurements, and data exporting and collecting. These areas of the framework are then described in their corresponding section.
3.1
Overview
The framework’s purpose is to gather network traffic data from nodes in a Bluetooth Mesh network so that this data later can be analysed and used to evaluate the network’s perfor-mance. The discrete entities in this procedure are the observers, collectors, and analysers. The observers perform the packet observation in the network and from this generate network traf-fic data. These processes are referred to as traftraf-fic measurements. The collector gathers data exported from several observers and then forwards this to the analyser where the data can be stored and analysed. The way the entities are connected is illustrated in figure 3.1.
The data that the framework generates and forwards to an analyser can then be used to, for example, establish a representation of the network and the relevant metrics used to evaluate its performance.
3.2
Constraints
The technologies the framework is intended to be used with have inherent constraints. The devices used to create a Bluetooth Mesh network are often embedded devices with limita-tions on both available memory and processing capabilities. To ensure that the framework can still perform as expected on these kinds of devices the constraints need to be identified and accounted for during the design process. In table 3.1 some common System on Chips, SoC’s, usable for Bluetooth Mesh are presented together with the performance of the micro-controllers used as well as the available memory. The performance of the micromicro-controllers is measured using a benchmark called CoreMark/MHz. To get a frame of reference for these
3.2. Constraints Collector Observer Observer Observer Observer Analyser
Figure 3.1: System overview
microcontrollers’ performance we can compare their benchmark scores with a processor that might be found in a PC. For example, the Intel Core i7-2760QM, released in 2011, has a Core-Mark/MHz score of 35.48.
SoC MCU MCUs CoreMark/MHz Flash memory RAM
nRF52832 ARM Cortex-M0 2.33 512/256 kB 64/32 kB
nRF52840 ARM Cortex-M4 3.40 1 MB 256 kB
QN902x ARM Cortex-M0 2.33 128 kB 64 kB
QN908x ARM Cortex-M4 3.40 512 kB 128 kB
EFR32 ARM Cortex-M4 3.40 1 MB 256 kB
Table 3.1: System on Chip constraints
There are also constraints that arise from the communication technology. BLE has a the-oretical maximum bit rate of 2 Mbit/s but this is without any form of channel coding, with the maximal amount of channel coding the bit rate is 125 kbit/s. However, these theoretical limits are for connection based communication and since Bluetooth Mesh uses the advertise-ment channels the transfer rate in Bluetooth Mesh is lower. Advertiseadvertise-ment packets in Blue-tooth Mesh are sent during a non-connectable non-scannable undirected advertising event as described in the Bluetooth Mesh specification[8]. These advertisement events cannot occur more frequently than every 20 ms. The packets sent during these events contain advertising data in the format shown in table 3.2. Since these packets can’t contain more than 31 octets of data the theoretical upper limit on the transmission rate of Bluetooth Mesh is 12.4 kbit/s. The network PDU in the advertisement data packet also contains overhead such as the packet’s source and destination, the time-to-live of the package, and a sequence number to identify the packet, etc. Therefore the actual transfer rate of application data must be even lower than 12.4 kbit/s.
Field Size (octets) Notes
Length 1 Specifies the packet length
AD type 1 The advertisement data type of the packet Network PDU 0 to 31 A network protocol data unit
3.3. Requirements
3.3
Requirements
The framework’s requirements are defined so that the framework meets the criteria for a high-quality data collection framework found in the literature described in chapter 2 that are also applicable in the Bluetooth Mesh networking context. The requirements are also formulated so that the previously recognized constraints of a Bluetooth Mesh network are taken into account ensuring that the framework provides expected functionality while having a minimal effect on regular operations of the node and the network.
The first requirement on the framework is that it needs to be effective when it comes to packet observation and data generation so that the data generated is accurate and properly describes the traffic. This is important to guarantee that the correct data is gathered and that the data is useful in later analysis. The framework also needs to gather and store data efficiently so there is no redundancy in the data and the minimal amount of resources are used. If data can be aggregated this is preferable. These two requirements, of effectiveness and efficiency, combined are meant to ensure that the framework will collect the relevant data and only this data, without redundancy. This will result in a minimal size of the messages containing the recorded traffic data and the memory needed to store it.
Additional requirements of adaptability are also imposed on the framework so that it can efficiently use the resources of both the observing and collecting devices but also the network as a whole. The purpose of this requirement is to ensure that the framework has a limited effect on the performance of the network it is deployed in.
The chosen requirements are listed below:
• Adaptability - adapt to both the device and network resource context • Effectivity - gather the relevant data
• Efficiency - gather only the relevant data
To ensure that the framework can provide the expected functionality for the primary use case of network performance evaluation, this use case is investigated further. The evaluation of the network performance is done by determining and comparing different metrics. These metrics preferably fulfill the criteria of usefulness and repeatability as described in the RFC’s discussing performance metrics[33][34]. The metrics determined to be relevant and that fit the previously mentioned criteria are the following.
• Coverage • Load balance • Packet delivery ratio • Throughput
Coverage represents the overall link quality conditions of a node or in an area of the network. An evaluation indicating poor coverage can be used to motivate installing extra nodes to increase communication reliability in that area of the network. The coverage of a node can be determined by comparing the signal strength of all of that node’s connections. For example in figure 3.2 the coverage around node A is considered to be poor due to all links to node A having a low signal strength.
Load balance is used to determine if a certain node or collection of nodes in the network performs an unproportional amount of traffic forwarding. This metric can be used to moti-vate installing extra nodes in the network or rerouting traffic through other nodes. It can also indicate that certain relay nodes relay almost no traffic and can, therefore, be removed. The load of a node is determined by the number of packets the node receives and transmits. The
3.4. Traffic measurements -75 dBm Node B Node A Node D -80 dBm Node C -90 dBm
Figure 3.2: Coverage metric
load balance can then be determined from the relationship between the individual node’s load and, for example, the median load in the network.
Packet delivery ratio is similar to coverage but applies to individual links between nodes and indicates the reliability of the communication over this link. This metric can similarly be used to motivate the redeployment of nodes. It can also motivate the reconfiguration of a node’s network parameters, for example, the number of times this node retransmits a message. Packet delivery ratio between two nodes A, and B, is defined as the quotient of the number of packets received at B divided by the number of packets sent from A.
Throughput is chosen for similar reasons as load balance but indicates traffic conditions on an individual node. It can be used to estimate the workload of a relay node and determine if it is close to a theoretical limit which would indicate that a second relay node is needed to offload work from the first node. The throughput of a node is defined as the number of packages a node forwards during a specified time interval.
The definition of these metrics can then be used to identify what data needs to be recorded by the observers in the network to fulfill the requirements of effectivity and efficiency. The identified data is presented in the list below.
• Coverage
– Signal strength to neighboring nodes • Load balance
– Number of received packets for all relevant nodes – Number of sent packets for all relevant nodes • Packet delivery ratio
– Number of received packets
– Number of packets sent from neighboring nodes • Throughput
– Number of received packets – Number of sent packets
3.4
Traffic measurements
The traffic measurements are made by an observer entity in the network. This observer is physically located on each mesh node that data is to be collected from. Using the description
3.5. Data exporting and collection
of the previously mentioned performance metrics it is concluded that an observer needs to record both the number of packets a node sends and receives. The observer also needs to record the source node of each packet received. In addition to these three items the observer also needs to record the signal strength between itself and nearby nodes that have commu-nicated with the observer node. These measurements can then be combined with similar observations made by neighboring observers to create the metrics mentioned previously.
To minimize the amount of data that needs to be stored at the observer, the recorded data is aggregated into flows, as described in chapter 2. These flows are uniquely identified by the address of the sender. The flows are stored together in flow tables. This flow-based approach aims to greatly reduce the amount of data stored on the observing device compared to a packet-based approach. Therefore this approach should suit the memory constrained devices that the observer is assumed to be deployed on.
The recording of data is inactive by default and must be initiated by a collector. An ob-server will, therefore, avoid performing unnecessary operations on data that is not used. This is assumed to reduce the power consumption of the observer device.
3.5
Data exporting and collection
The collection procedure is initiated by a configuration message. This message is sent from the collector to one or more observers. The configuration message contains information about when the observer shall start and stop measuring network traffic. It also specifies the peri-odicity of the transmission of the reports back to the collector. To verify that a configuration message was received and processed at the observer, the observer can respond with a config-uration acknowledgment message.
The reporting of measurements is timing based to reduce the amount of extra traffic intro-duced in the network by the framework. This approach can be compared to a polling based approach where each report is initiated by a collector that tells the concerned observers to report their results. In a mesh network where the number of observers can vary depending on the scenario, the polling approach will introduce what can be regarded as unnecessary traffic in the network and therefore increase the amount of interference with the regular user traffic. Another approach is to use event based reporting, for instance, the observer could be configured to report when there are a certain number of flows recorded or a flow has not received an update for a set amount of time. This approach has similar benefits compared to the timing based approach because it doesn’t introduce extra network traffic. However, it doesn’t allow a user to configure the granularity of measurements. For instance, with timing based collection a user can specify the duration of measurement periods and using this de-duce the rate at which packets are sent or received at the observing node. Therefore, metrics such as throughput will not be as easy to construct using event driven collecting. This rea-soning motivates the use of timing based data collection in the framework described in this report.
To avoid interfering with regular traffic on the network the observer can also be config-ured such that the reporting rate will adapt to nearby traffic conditions. A measurement du-ration is not affected by this, instead the observer will take a snapshot of the flows recorded when it is time to report. It will then evaluate the traffic conditions and decide if they are favorable and the report can be transmitted without interfering with other traffic. If the con-ditions instead are unfavorable the transmission will be postponed. This can be repeated a set number of times before the observer gives up on sending this report. This feature aims to make the framework non-invasive and adaptable.
The measurement reports contain a snapshot of the reporting observers flow table and also information about the measurements duration and a sequence number of the report that can be used to order received reports chronologically.
3.5. Data exporting and collection Observer Collector Analyser Observer Configuration message Configuration message Measurement report Measurement report Measurement report Measurement report Measurement report Measurement report Measurement report Measurement report
Figure 3.3: Communication overview
Once the collector receives the measurement report it immediately forwards the content to the analyser entity where the data can be stored and later analysed. The reason for the instant relaying is motivated by the effects it has on the memory requirements of the collector node. The idea is to have the collector not store any data and instead offload this effort onto the analyser which is assumed to not have the same memory constraints as the nodes in the Bluetooth Mesh network.
The communication procedure for a measurement session is shown in figure 3.3. In this figure, a single collector configures several observers to report twice during a set amount of time. The received reports are then immediately forwarded to the analyser.
4
Implementation
This chapter describes in detail how the framework is implemented to fulfill the identified requirements from chapter 3. The chapter presents how the different areas of traffic measure-ment and data exporting and collection are divided onto separate devices in the network. The chapter also describes the format of the data captured and how it is communicated between devices.
4.1
Overview
The framework implementation is divided into three different modules. The first module is called the Traffic Data List, TDL, which performs the packet observation and from this generates flows that are then stored by the module. The second module is called the Traffic Data Server, TDS, which accesses the TDL via an interface that allows the TDS to start or stop packet observation and also retrieve the resulting flows. The TDS can then transmit these results in measurement reports, using Bluetooth Mesh, which is collected by the third module, the Traffic Data Client, TDC. The TDC can also interact with the TDS to configure the start and stop time of measurements. When the TDC receives measurement reports directed towards it, it forwards them across a serial interface so that they can be read by an analyser.
The Traffic Data List and the Traffic Data Server exist on the same physical device and the Traffic Data Client is placed on a separate device. This setup and how they can interact is shown in figure 4.1.
4.2
Traffic measurements
Traffic Data List
The Traffic Data List’s purpose is to record the arrival or departure of packets at the node. It also provides an interface that allows models such as the Traffic Data Server in the topmost layer of Bluetooth Mesh to access the recorded data. The data is recorded by packet observa-tions in the bearer layer of the Bluetooth Mesh stack. The TDL interacts with the two opposite ends of the Bluetooth Mesh stack and is placed outside it as seen in figure 4.2.
When a packet arrives at the bearer layer the TDL is notified and supplied with the packet’s source advertisement address, the Advertising Data type, AD type, and the Received
4.2. Traffic measurements
Observer
Traffic Data List Traffic Data Server
Collector
Traffic Data Client
Figure 4.1: Collector and observer communication
Model Layer
Foundation Model Layer
Access Layer
Upper Transport Layer
Lower Transport Layer
Network Layer
Bearer Layer
BLE Link & Physical Layer
T
raffic Data List
Figure 4.2: Interaction with the Bluetooth Mesh stack
Signal Strength Indicator, RSSI. These values are then used to update the TDL’s flow table. The flow table consists of flow entries. The flow entry itself is made up of a set of fields that describe the communication between the node at which the TDL is located and the node identified by the advertisement address of that entry. This advertisement address is therefore used as the key for the entry, meaning that no two entries can share the same advertisement address. The fields of a flow entry are described in table 4.1.
4.3. Data exporting and collection
Field Size (octets) Notes
Advertisement address 6 The advertisement address of the packets source Mesh packets 2 The number of packets received with AD type
Mesh Message
Beacon packets 1 The number of packets received with AD type Mesh Beacon
Report packets 2 The number of packets received with AD type in-dicating the packet is a part of a measurement re-port. This AD type is introduced by the frame-work described in this report and is therefore not a part of the Bluetooth Mesh specification. Average RSSI 1 The average RSSI of the link between recording
node and packet source Table 4.1: Flow table entry
In addition to storing entries in the flow table, the TDL also tracks the time when it started recording packets, the total number of packets received of any AD type, and the number of packets with the Mesh Message, Mesh Beacon or report AD types that the local node has sent. The TDL does not record packets by default, it must first be activated by calling a start function provided by the TDL interface. When the TDL has been activated through this method it will record every sent and received packet as described above until the stop func-tion is called. The TDL interface also provides a funcfunc-tion that allows for accessing the flow table, as well as the duration of the current recording session, the total number of packages received, and the number of packets sent with the AD types mentioned above.
4.3
Data exporting and collection
Traffic Data Server
The Traffic Data Server is implemented as a Bluetooth Mesh model. The TDS’ purpose is to retrieve the measurements from the TDL and then transmit this data in a measurement report. The TDS contains timers that are used to trigger the start and stop of a measurement session. It also has a timer that triggers periodically and initiates the transmission of the measurement report during a measurement session. The time between reports is referred to as a measurement period.
When the reporting event is triggered the TDS takes a snapshot of the current state of the TDL. This snapshot is then used to construct a measurement report message. The measure-ment report’s content is described in table 4.2. The Bluetooth Mesh specification limits access layer messages to 384 octets including message overhead. This limit is therefore imposed on the measurement reports that the TDS transmits. To fit inside a single access layer message the number of flow entries in a measurement report is limited to 30 with the current flow entry definition.
4.3. Data exporting and collection
Field Size (octets) Notes
Sequence number 1 Sequence number used to order
re-ports received from same observer
Duration 2 The duration of the measurement
period
Total packets received 4 Total number of packets received
at the bearer layer of any AD type during this measurement period
Mesh packets sent 2 Total number of bearer layer
pack-ets sent with the AD type Mesh Message during this measurement period
Beacon packets sent 1 Total number of bearer layer
pack-ets sent with the AD type Mesh Beacon during this measurement period
Report packets sent 1 Total number of bearer layer
pack-ets sent with AD type Traffic Data Report during this measurement period
Flow list size 1 The number of entries in the flow
list in this report
Flow list Variable between 0 and 360 A list containing all entries recorded in the flow table during this measurement period
Table 4.2: Measurement report
The constructed message is then broadcasted onto the Bluetooth Mesh network if the TDS is in passive reporting mode. If the TDS is configured to instead be in adaptive reporting mode the TDS will estimate the traffic conditions of the reporting nodes neighborhood. If the traffic condition is poor i.e. below a preconfigured value then the TDS will postpone transmission for a set amount of time and then retry transmission when this time has elapsed. This process repeats at most two times excluding the initial attempt. If the transmission fails on the last attempt that measurement report is dropped.
The traffic condition estimation is done by calculating the estimated Packet Delivery Ra-tio, PDR, based on how many packets the node is currently receiving per second. A high PDR is interpreted as good traffic conditions in the nodes neighborhood and a low PDR is interpreted as poor traffic conditions. The threshold PDR that decides whether to report or not is a configurable parameter on the TDS performing the measurements. During a mea-surement session, the PDR is estimated periodically and then compared when the TDS tries to transmit a report. Should the estimated PDR be below the configured threshold at the start of the transmission it is postponed. To ensure that the estimation of the PDR is updated be-tween separate transmissions attempt the retry interval must be strictly larger than the traffic condition update interval. Figure 4.3 illustrates the reporting procedure for a TDS configured for adaptive reporting.
To not introduce extra traffic and query neighboring nodes of their transmission count the PDR is estimated using node local data. The PDR is also assumed to apply for all nodes in the estimating node’s neighborhood. One identified variable that affects PDR and is available at the node is the number of packets that are received per second. The relationship between the incoming packet rate and the PDR is shown in figure 4.4. The data in this figure was collected by having a control node continuously transmit at a known periodicity and with fixed packet size. The number of packets this node sent was recorded locally and then compared to the
4.3. Data exporting and collection Report timer event Y N Retry count < Max retries N Y estimated PDR > threshold
Send report Drop report
Postpone Retry timer
event
Figure 4.3: Flowchart of adaptive reporting
number of packets received at a dedicated receiver node. The PDR was then calculated as the ratio between the number of received packets and the number of transmitted packets. During this communication one or two extra nodes sent out packets where both the number of packets and the interval varied between several sets of measurements. The total number of packets received at the dedicated receiver node was then recorded and used to calculate the incoming packet rate.
Using simple linear regression, the data shown in figure 4.4 is then used to fit the models:
Mi: y=ei+ i
ÿ
k=0
wikxk, i=1, 2, 3, 4
where y is the PDR, x the incoming packet rate, and the error ei is assumed to be normally
distributed with a mean of zero and uncorrelated between measurements. The models are fitted to half of the data available using the least square method and then tested on the re-maining data. The Root Mean Square Error, RMSE, for the test results are shown in table 4.3. Model i RMSE 1 0.01783239 2 0.01804793 3 0.01784181 4 0.01766194
Table 4.3: RMSE of the PDR models
Increasing the complexity, i.e. the degree of the polynomial only improves the RMSE for i = 4 and then not by much. Therefore, the first model M1was chosen to predict the PDR.
The resulting predictive function
ˆy=
1
ÿ
k=0
