Mesh Networking Topologies for Reliable and Scalable IoT Deployment

In the sidebar, you have the option to download the entire whitepaper and read it later

Authors: Jagadish B Kanade & Srivatsan S

Internet of Things (IoT) is one of the hottest topics currently, promising to connect millions of people and machines to interact with each other. This is also termed as “Network of Networks”, with a multi-layered architecture connecting end nodes to the central server over Cloud. With a huge influx of devices on the network, IoT relies on Wireless Technologies for device management and maintenance. This also poses a serious challenge to the scalability and reliability of Wireless Technology in question. This paper looks at all relevant Wireless Technologies and how Mesh Networks can provide a scalable, reliable and extensible solution to the ever evolving and demanding IoT applications.

1. Introduction

The name “Internet of Things” was coined by Kevin Ashton in 1999 in reference to different electro-mechanical systems which sense and control and physical environment automatically without any human intervention. According to some estimates, Total Addressable Market (TAM) for IoT globally will be around $1.2 trillion by 2022. IoT covers a wide range of application domains pning Industrial IoT, Smart Agriculture, Smart Home, Smart Cities, Intelligent retail, Health care, etc. resulting in a huge influx of devices onto the network. 

2. IoT Architecture

The concept behind IoT Architecture is complex as well as powerful as it caters to a wide gamut of applications from Industrial Use to Agriculture, Smart Cities and Home Appliances.

An IoT network consists of 4 building blocks as listed below: 

• Sensors and Actuators
• Gateways and Data Acquisition
• Edge Analytics
• Data Centre and Cloud Platform

IoT Architecture is diametrically represented below

Figure 1: 4 Stage IoT Architecture

2.1 – Sensors and Actuators

This is the first stage where sensors collect real-time data from the environment and convert them to useful information. At the same time, Actuators also fit in this stage as they intervene at an appropriate time to change the physical conditions that generate data. For Eg: Actuator can shut-off power supply or adjust the air-flow valve in the system, it can increase/decrease the AC temperature depending on the room temperature, etc. Sensor/Actuator stage is the initial building block in an IoT system which covers wide range of devices such as industrial devices, robotic cameras, water-level detectors, heartrate monitors, blood-pressure monitors, air-quality sensors, etc.

Data generated by sensor in this stage has limited use as processing power available in the IoT device is very minimal. Hence, data is sent up the stack towards the Data Centre or Cloud servers for deeper insights and extensive data analytics.

2.2 – Gateways and Data Acquisition

This stage of IoT works closely with the previous stage (sensors/actuators) in collecting and aggregating the data and pass them on to the next stage over Internet. Data Acquisition Systems connect to the sensors to collect and aggregate the data, whereas Internet Gateways are connected through Wi-Fi/Wired Connections to push the data up the IoT stack for further processing.

2.3 – Edge Analytics

Data once aggregated and presented from the previous 2 stages, require additional processing (often called pre-processing) before it is passed to the data centre in the cloud. 

IoT data can consume lot of bandwidth and based on the need, the Edge Analytics can be deployed at the Edge of the network, closer to the first 2 stages just before entering the core IT infrastructure.

2.4 – Data Centre and Cloud Platform

Data Mining happens in the Data centre over the cloud which happens to be the pivot of the IoT system. Powerful processing-oriented systems are deployed in this stage as they enable in-depth data processing and analysis over extended periods, management and storage of data 

2.5 – Focus of this paper

In this paper, we shall concentrate on various Wireless technologies that can fit in Stage 2 of the IoT Architecture and different factors which play role in their selection.

3. Wireless Technologies

With more and more devices getting added onto the network, there is an increasing need to be able to dynamically adapt to changing needs. The need of the hour is to provide the Gateway and Data Acquisition infrastructure for seamless device connection and management to address the following requirements: 

• Ease of Deployment
• Reduced Installation and Maintenance overhead and hence reduced overall cost 
• Dynamic Workload distribution
• Easy addition and deletion of nodes
• Better reaction to nodal failures
• Easy network topology adjustments and modification

At the outset, on a generic scan of different available technologies, Mesh Networks fit into the bill which can address most of the requirements reasonably well. Let us look into some of the generic aspects of Mesh Networks in different Wireless Topologies.

4. Mesh Networks

Nodes in a Mesh Topology work in a cooperative manner for data distribution, thus, allowing many-to-many communication to efficiently route data from source to destination. Mesh topology is the most attractive alternative to traditional centralized model, which doesn’t scale well when number of nodes increase. 

Diagrammatic representation of a Mesh Topology is shown below: 

Figure 2: Nodes in a Mesh Topology

Some of the salient features of Mesh Networks are given below: 

• Each node is connected to every other node, enabling many-to-many communication
• Multiple paths to reach between a source and destination, thus making the network resilient
  • Each path can be assigned cost/metric and the best path between 2 nodes can be chosen based on the same

A mesh network is made of different components.

• Nodes: Each mesh network has nodes which are the devices that communicate with each other for sending/receiving information

• Gateways: There are nodes which act as Gateway to Internet, thus providing connectivity to external world

• Repeaters: These are nodes which take up the functionality of increasing signal strength to extend coverage

• End-point: End-point devices are the devices which don’t forward any information. These nodes only disseminate information further up the stack and hence act as just source of data. 

Let us look at some of the wireless technologies available at this juncture which can address some of the requirements facing Stage 2 of IoT architecture.

4.1 – Zigbee

Zigbee is a standard based Wireless technology developed to enable low-cost, low-power wireless mesh connectivity solution covering a distance of 10-100 meters. This is based on IEEE 802.15.4 following multi-band (across 2.4GHz and sub-GHz bands like 868MHz and 915MHz bands) spectrum as prescribed by the standard.  

4.1.1 – Zigbee Topologies

Zigbee supports several topologies like star, mesh and cluster tree topologies. Irrespective of the topology, nodes are categorized into 3 types namely — Coordinator, Router and Device.

• Coordinator – Responsible for network formation. Selects frequency channel, manages operations related to join and leaving of nodes in the network
• Router – Has routing capabilities. Sends and receives data, allow other child nodes to join the mesh network. Based on the topology, there can be many routers in the network to enable routing among different nodes, with maintenance of redundant paths
• Device – End-point device sends or receives data from its parent node. These are battery powered devices. Since these nodes can sleep to preserve power, messages addressed to the sleeping device will be buffered in the parent node and relayed later when the device wakes up

Figure 3: Zigbee Topologies

Mesh and tree topologies consist of multiple router nodes to enable routing between different nodes with redundant paths. 

In a Zigbee network, each end device can communicate with one another placed in its vicinity. Such devices are called “Full Functional Devices (FFD)”. There could be “Reduced Functional Devices (RFD)” as well, which can communicate to only one neighboring device. Devices can establish direct communication through “Beacon” or “Non-Beacon” modes.

4.1.2 – Zigbee Protocol Architecture

Zigbee Protocol Architecture consists of different layers as defined by IEEE 802.15.4 represented in Figure 4. Some of the main features of Zigbee Protocol are: 

Figure 4: Zigbee Protocol Architecture

• Zigbee operates in multi-bands (ISM band of 2.4GHz and sub-GHz bands like 868MHz and 915MHz bands) spectrum as prescribed by the standard
• PHY Packet takes care of synchronization with the receiver by incorporating Synchronization Header in the PHY Packet
• Operates with CSMA/CA at MAC Layer
• Network layer defines operations such as routing, device management and connectivity
• Application Support Sub-Layer – provides set of services to Application Layer and Network Layer through Application Support Data Entity and Management Entity Service Access Points
• Application Layer supports overall device binding, enabling of data services like key value pair and generic data service. This layer also defines messaging mechanism to extract key attributes from the device objects

4.2 – Thread

Thread protocol is a device level communication protocol designed for IoT networks, started primarily by Nest, powered by Google.

Figure 5 gives an overview of the thread stack. Some of the features of this protocol are:

• Open-sourced, IEEE802.15.4 based wireless mesh protocol
• Operates in 2.4GHz band at 250kbps
• Uses CSMA protocol for listening to clear channel at MAC Layer
• Is IP-Enabled (Support for IPv6) for easy integration into the network

• Security enabled – Device do not join thread network unless authorized and all communications are encrypted and safe
• Enables device-device and device-cloud communication
• Compatible to 6LoWPAN specifications
• Simple installation procedure as the protocol supports self-configuration and healing
• Has different device-types
  • Border Routers – Provides routing connectivity to external networks on other layers – say Ethernet, Wi-Fi, etc.. 
  • Routers – Provide joining and security services within the Thread Network. Routers are not eligible to sleep, but can downgrade themselves to Router Eligible End Devices (REEDs)
  • Router Eligible End Devices (REEDs) – Have capability to become routers, but these devices are not active as routers currently due to topology or conditions. Routers are in passive mode, but can elevate themselves to become Routers if network conditions demand
  • Sleep End Devices – Host devices, communicating only to the parent router. Cannot forward messages to other devices

Figure 5: Overview of Thread Stack

A basic mesh network with Thread protocol stack is shown in Figure 6. All router nodes maintain information about routes and connectivity in a pro-active way and rebuild the same whenever a change is necessitated due to the network activity. The routing protocol followed in Thread based Mesh Network is a Distance Vector Based routing protocol called RIP (Routing Information Protocol). Algorithms mentioned in RFC1050, RFC2080 are used. There is a limitation of 32 Active Routers – imposed by Thread Protocol.

Figure 6: Mesh Connectivity using Thread Protocol

4.3 – Wi-Fi Mesh Networks

Mesh networks being different from traditional networks, it took a while for the Wi-Fi Alliance to come up to terms with the practical demands of Mesh Networks in Wireless domain. 

The standard 802.11s standard has been amended to include the functionality of “Mesh Station”. A Mesh Station is simply a station that supports Mesh Functionality and is capable of participating in a Mesh Cloud which is also termed as “Mesh Basic Service Set” (MBSS). 

MBSS is an 802.11 LAN consisting of autonomous stations, which establish peer-to-peer links and transfer messages mutually. An important different with IBSS is that in IBSS, client stations are not in direct communication with each other. Mesh Functionality capability is indicated through separate IEs (Information Elements) in the Beacons being transmitted.

MBSS mesh network includes the following different types of device classes based on the functionalities executed. 

• Mesh Point – Establishes Peer links with Mesh point neighbours, fully participate in Mesh Services
• Mesh Access Point – Functionality of MP co-located with Access Point (AP), which provide BSS services to the Stations
• Mesh Portal – This is the Gateway point where frames enter/exit the External and Mesh Networks
• Station –Outside of WLAN Mesh, connected via Mesh AP

Functionality of all the 4 devices is depicted pictorially in Figure 7 given below.

Figure 7: Wireless Mesh Network

4.3.1 – Best Path Selection

Wi-Fi Mesh Networks deploy Hybrid Wireless Mesh Protocol (HWMP) as the default routing protocol for inter-operability, calculation of optimized routing paths between 2 Mesh nodes. Some of the salient features of HWMP are: 

• Combines flexibility of on-demand route discovery with efficient pro-active routing to a mesh portal
  • On-demand discovery – flexibility in changing environments
  • Pro-active tree-based routing usually works well in a fixed network
  • Combination of both is most optimal
• On demand Routing is based on Radio Metric – AODV (RM-AODV)
  • Based on RFC3561
  • Allows nodes to form routes quickly for nodes involved in active communication
  • Uses Expanding Ring Search to limit flood of routing packets
  • Forward and Reverse Paths are set up Route Request and Reply (RREQ, RREP) packets
  • Link status between active nodes are monitored. Any change in status is acted upon immediately
  • All nodes maintain Destination Sequence Number to guarantee Loop Freedom
• Proactive Routing is based on Tree Based Routing
  • Is based on Distance-Vector Routing
  • Tree formed with Root of the Mesh Point being the pivot
  • MPs monitor the upstream links and switch back to backup links when there is a link status change, proactively monitors the link state
  • Routing Protocols based on RFC – 3626 (Optional Path Selection Protocol)

A full-fledged Wi-Fi Mesh based IoT network is given below: 

Figure 8: Wi-Fi Mesh Topology based IoT Network

4.3.2 – Power Management Concerns in Wi-Fi

An important aspect factored into 802.11s specification is “Power Save”. Some Mesh Stations could be operating on battery and may be located in areas where power might not be available all day long. Hence, the ability to use power-save for battery conservation is a key element for the longevity of MBSS. Hence, a mechanism has been defined to avoid frame loss or MBSS disruption when a mesh station is dozing off. The standard defines 3 states for Power-Management in Mesh Stations: 

• Active Mode: Mesh station is available at any time – participate in data forwarding, route/path discovery and MBSS Management functions
• Light Sleep Mode: Station tries to conserve battery while still performing some MBSS functions. The station alternates between Active and Light Sleep states. It can be awakened to receive a beacon frame from peer mesh station
• Deep Sleep Mode: Station doesn’t monitor its peer mesh stations. The station has to awaken at a regular interval, send beacon frame and wait for around “Awake Window” time frame to receive response to its beacons from neighbouring mesh stations

A Mesh Station can put itself in “Deep Sleep Mode” for all its neighbours in extreme condition and decide to remain active only for its own traffic. This way, the behaviour is more flexible and can be customized as demanded by the situation.

4.4 – LoRa Networks

One of the most promising, emerging Mesh Networking technology for IoT networks is LoRa. This technology allows for long-range, low-power, low data range applications, with distance covering upto tens of kilometer in distance. 

Some of the salient features of this technology are:

• LoRaWAN networks is based on star-based topology
• Gateways relay messages between end-devices and centralized server in the cloud
• Adaptive Data Rate is used for managing data rate and effective RF output of end-devices in LoRaWAN. This in turn increases the network capacity and power management of the device
• Different Classes of devices:
  • Class A devices: Devices transmit to gateways when needed
  • Class B devices: Devices transmit to gateways with scheduled receive slots. Nodes behave similar to Class A, but with additional receive windows for time synchronization with beacons 
  • Class C devices: Devices with maximum/continuous receive slots, making them not suitable for battery powered operations

The diagram given below gives the layering of LoRaWAN architecture.

Figure 9: LoRaWAN Architecture

4.4.1 – LoRaBlink

Since multi-hop communication is a basic necessity in mesh network, authors in [Ref 6] propose and discuss an alternative, reliable, energy-efficient MAC Layer for multi-hop communication called LoRaBlink. Some of the assumptions made while discussing this option was that the network is low-density, low traffic volume and contains limited number of nodes, with only one sink.

This protocol aims at integrating MAC and routing into a single, simple protocol. Time synchronization among nodes is used to define slotted channel access. Nodes transmit concurrently within the slots and properties of LoRa PHY layer ensures that only one of the concurrent transmissions is received. Messages are transmitted to sink nodes using flooding. Beacons are used for synchronization and division of time into epochs. The diagram below depicts the difference between a typical star and mesh based LoRa networks. 

Figure 10: (a) Star Topology based IoT Network (b) Wi-Fi Mesh Topology based IoT Network

4.4.2 – Other Options

Other options being considered for LoRaWAN Mesh include routing protocols like AODV or HWMP being used on IEEE802.11 networks. Some of the assumptions made while considering this protocol include the presence of lesser number of hops (as it is long-range distance), along with assumption of low data rate towards uplink. Existing LoRaWAN 

MAC layer has been suitably modified to accommodate Route Request, Reply and Error packets as required by the routing protocols. With the above assumptions, it has been observed that the time taken to construct the best path increases linearly with the number of hops. 

4.5 – Mesh in Bluetooth/BLE Networks

Bluetooth provides an interesting option for interconnecting a large number of nodes to build a low-cost, full-duplex, wireless network. Bluetooth is gaining traction as it is a natively implemented feature on a majority of devices like laptop, smart-phone, mobile tablets, smart devices. 

Due to the increasing demand for Low Power devices in the IoT space, Bluetooth technology, currently referred to as Bluetooth Classic was fine-tuned for Low Energy requirements as BLE which was released as part of Bluetooth Specifications 4.0 released in 2010. This was a later enhanced in Bluetooth Specifications 5.0 released later in 2016. 

Comparison between Bluetooth Classic and BLE is tabulated below: 

Some of the important components and operations of a BLE network and their roles are given below: 

• Master (Central) – Scans for other devices in the vicinity
• Slave (Peripheral) – Advertise and wait for connections 
• Client – Devices which access remote resources over BLE link using GATT protocol. Master can also be client
• Server – Devices have a local database and access control methods, provide resources to remote client. Usually, slaves perform the server functionality
• Read and Write operations are requested by Client, while Server responds (acknowledges)
• Notify and Indicate – operations enabled by client, but initiated by the server, providing a way to push data to the client 
• Notifications are unacknowledged, while Indications are acknowledged. Hence, notifications are faster, but less reliable 

BLE as a technology and standard, lacked the capability of support many-to-many topology. This changed when Bluetooth SIG released the Specification for Bluetooth mesh Standard. This standard builds on top of BLE and utilizes many concepts of BLE. 

Important terminology of a Bluetooth mesh network is listed below: 

• Nodes – Devices part of Bluetooth mesh
• Elements – Different functional parts in a node 
• States – Elements can be in different conditions is represented as State
• Properties – Context/Attribute to a state is called Property
• Messages – Communication in a Bluetooth mesh is through messages, which is of 3 types – GET, SET, STATUS
• Addresses – Bluetooth mesh advocates 3 types of addresses
  • Unicast address – An address uniquely identifying the single node
  • Group address – Address usually addressing a set of nodes (eg: all nodes in a room, etc). There could be a standard group address or dynamic group address created on demand
  • Virtual address – Address assigned to one or more elements, pning one or more nodes. This could be pre-configured at the time of manufacturing
• Publish/Subscribe – Model in which messages are exchanged in a Bluetooth Mesh
  • Publish – Act of sending a message
  • Subscribe – Registering for a message sent to a group address or virtual address
• Managed Flooding – Bluetooth mesh uses this technique to broadcast messages to all nodes within the range of the sender, with a few optimizations mentioned below: <
  • Messages with TTL – Messages have Time-To-Live, which indicates the number of hops that the messages can be relayed
  • Caching of Messages – This is implemented by all nodes. Messages received, if already existing in the cache are immediately discarded
  • Periodic Heart-Beat Messages – to indicate the responsiveness of the node
  • Friendship – Refers to relationship between 2 nodes. There can be 2 types of nodes – Low Powered Node (LPN) and Friend Node (Live Powered Node) which can act as a Proxy for a LPN

The operating plane of a BLE mesh network provides 2 ways of communication: 

• Advertising mode – BLE mesh uses broadcasting packets to advertise itself and allows its neighbours to relay data through advertising packets. Conventional method is not followed in data exchange
• Connection oriented mode – Packet transmission between 2 nodes happen after establishing a direct connection through handshake 

Figure 11 captures a typical BLE mesh network with various node types.

Figure 11: BLE Mesh Network

5. Comparison between different Mesh Networks

We shall consider popular use-cases like Smart Agriculture and Smart City to have a global and comprehensive vision of IoT requirements and compare different parameters in the above applications for appropriate usage of Mesh Wireless technologies.

Discussion on different use-cases will centre around the pictorially represented typical IoT network shown in Figure 11

5.1 – Smart Agriculture

Smart Agriculture use-case for IoT network consists of a rural setting, where one can consider a farm composed of large fields cultivated with fruits and vegetables with livestock. 

The scenario consists of end-devices (sensors/actuators) sitting in remote areas in farm fields sourcing data to be sent out to cloud servers over Internet. Nodes represented in the figure below either have sensors directly or could source data from end-devices directly connected through other Wireless Interfaces like UWB.

5.2 – Smart City

Smart City can be modelled as a union of subnetworks in which each subnetwork can be tasked to handle a particular aspect – like air quality, waste accumulation, traffic management, etc. Data sourced from end-devices rely on Wireless Meshed Network to be relayed to cloud servers. Deep analysis of data collected can be used to develop smart parking systems, waste management, smart lighting, etc.

5.2.1 – Smart Parking

Smart Parking use-case can comprise of the following requirements:

• Several Parking slots, with sensors placed in each slot to detect parking presence/absence
• Nodes in a Mesh to collect, collate and initial data munch before transforming 

5.2.2 – Waste Management

• Trash bins located on street corners to be equipped with weight sensors
• Weight sensors check trash accumulation in real-time to determine when emptying is required
• Nodes collate the information from sensors and push the data to centralised location through Gateways

5.2.3 – Smart Transport

Smart Transport is one such application which can be used to enhance the public transport system

• Sensors can be installed on buses to view their position co-ordinates
• Based on the co-ordinates and the traffic in the vicinity, time to reach the destination can be calculated
• Data collected through such mechanism can be used to:
  • Routes can be recalculated based on traffic density to the destination
  • Determine when to schedule new trips

Let us consider different scenarios for nodes in the Mesh to be having different radio interfaces:

• IEEE802.11 radio interface for Wi-Fi Mesh 
• Bluetooth 5.0 for Bluetooth Mesh Network
• IEEE802.15.4 radio interface for Zigbee/Thread implementation

5.3 – Performance Metrics

Initial comparison of different wireless technologies against data rate and range is diagrammatically shown in Figure 12. 

Note that BLE is designed for short-range (around 100m) with low data rates, whereas, Wi-Fi shows good throughput at around the same range. Protocols based on 802.15.4 like Zigbee and Thread have long range (> 500m), but not designed for high throughput. 

Figure 12: Comparison of protocols based on Data Rate and Range

In the subsequent table, different Wireless Technologies will be compared against the following parameters:

• Coverage – Intended as the area which can be covered using the Mesh Network
• Range – Intended as the transmission range of a single node in the Mesh Network
• Scalability – Capability of Wireless Mesh Network to scale
• Data Rate (bps – bits per sec) – Measured in bits per sec per node
• Network Topology – Degree of complexity required to build different network topologies
• Battery Life – Measured on nodes in the Mesh Network
• Power Consumption – Measured on nodes in the Mesh Network
• Latency – Time it takes for data exchange among nodes in the network
• Deployment – Complexity to deploy the Mesh Network depending on the Wireless Technology

The plot shown in Figure 13 have been obtained after analysing relevant works in literature [13-15] analysis of different protocols against different parameters in different research papers and articles and normalizing data for effective comparison. 

Figure 13: Comparative Performance Analysis with relevant metrics against different Wireless Technologies

Please find the table of arithmetic average of various performance metrics collected after analysing different research papers with final results normalized between 0 and 1.

For protocols analysed in previous sections, Thread and Zigbee can be seen as adequate Mesh Technologies especially in terms of scalability and power consumption. These technologies fare pretty well where data involved is reasonably less.

In cases where short range communication is required, another technology which performs reasonably well is BLE, with reasonable data rates and provides good performs in terms of network topology, power consumption, scalability and network coverage. However, one major issue with this technology is that it is not IP-aware. It requires a Gateway which needs to translate data between a Bluetooth mesh and IP-network. For extended coverage over a large area, either the mesh has to be reasonably big or presence of intermediate gateways to connect to IP Network. 

LoRa performs better in most of the cases, but falls short when data rate is too high. Also, due to the lack of a well-defined standardized mesh network protocol, deployment becomes a challenge with LoRa based mesh networks.

802.11 standard based Wi-Fi mesh guarantees an acceptable transmission range, with the highest data rate among all the protocols considered. The fact that this technology is compatible with IP Network, with a routing protocol in operation, is an added advantage. However, the power consumption is the only limitation as reasonably high energy is required for the devices with this technology to operate. 

It is also often seen that complex requirements require heterogeneous technologies. Area could be divided into clusters and different technologies can be deployed in each cluster depending on the need. However, the data can ultimately culminate in a centralized database for postprocessing and data mining. 

6. Conclusion

In this paper, we have discussed that Wireless Mesh Technology is becoming an indispensable proposition in IoT Networks today. In addition to this, we also have considered different wireless technologies and mesh protocols available to address the rapidly growing requirements in this field starting from IEEE802.15.4 radio based Zigbee and Thread to IEEE802.11 based Wi-Fi Mesh and Bluetooth Mesh Network which were notified through Bluetooth 5.0 specifications. An interesting conclusion after study and research is that, all the technologies might find a place given the complex and varied requirements in different fields. An IoT network can be summed up as a “Cluster of Networks” where each cluster can be realised with a different technology which addresses the end-user need as was observed in the use-cases considered.

7. References

1. https://getinternet.com/mesh-network/
2. https://www.link-labs.com/blog/mesh-network-topology-advantages-disadvantages
3. https://medium.com/datadriveninvestor/4-stages-of-iot-architecture-explained-in-simple-words-b2ea8b4f777f
4. https://dzone.com/articles/what-is-iot-networking-architecture
5. https://www.threadgroup.org/Portals/0/documents/support/
   ThreadOverview_633_2.pdf
6. Bor, M.; Vidler, J.; Roedig, U. LoRa for the Internet of Things. In Proceedings of the 2016 International Conference on Embedded Wireless Systems
7. and Networks, EWSN ’16, Graz, Austria, 15–17 February 2016;pp. 361–366
8. https://www.cwnp.com/
9. https://connectivity-staging.s3.us-east-2.amazonaws.com/s3fs-public/2018-10/BLE%20Mesh%20Introduction.pdf
10.  https://www.novelbits.io/bluetooth-mesh-tutorial
11. https://www.rfwireless-world.com/Terminology/Bluetooth-vs-BLE.html

12. https://www.researchgate.net/publication/332485316_Wireless_Mesh_
    Networking_An_IoT-Oriented_Perspective_Survey_on_
    Relevant_Technologies

13. https://ubidots.com/blog/exploring-cat-m1-nb-iot-lpwan-connections/

14.  Wireless Standards for IoT: http:// wireless.ictp.it/school_2017/Slides/IoTWirelessStandards.pdf
15.  Role of Wi-Fi and Unlicensed Technologies in 5G – https://wballiance.com/the-role-of-wi-fi-unlicensed-technologies-in-5g/