Brokerage System for Integration of LrWPAN Technologies
1.1. Aim and Research Objectives
- RO1: Integrate several low-energy low-rate wireless network protocols defined by IEEE 802.15.4 (e.g., Zigbee and Thread) and Bluetooth Low Energy through a novel broker (known as JosNet).
- RO2: Develop a network data framework using a sequence diagram for data transmission architecture to highlight the handing-over procedure from one network to the other (i.e., Bluetooth Low Energy to Zigbee) by JosNet as an integration interpreter.
- RO3: Performance Monitoring
- RO3.1: Develop a time synchronising mechanism using an end-to-end device IP address and port number to track or monitor network delay between the source and destination nodes;
- RO3.2: Build a predictive model for the delivery time and data packet size based on raw data collected by JosNet in CSV format;
- RO3.3: Build a predictive model for throughput based on raw data collected by JosNet in CSV format.
- RO4: Validation
- RO4.1: Design and implement experiments using JosNet to provide insight into the behaviour of low-energy WSN protocols or standards such as Zigbee, Bluetooth Low Energy, and Thread to validate their interoperability;
- RO4.2: Implement a large-scale campus-wide interconnection of multiple nodes, involving all network protocols tested during this research study (BLE, Zigbee, and Thread). Making use of a similar principle as the mesh routing feature in IEEE 802.15.4 to advocate the possibility of M2M long-distance mesh connectivity of an interoperable network.
1.2. Novel Contribution of Research
2. Literature Review
2.1. Low-Rate Network Standards and Protocols
2.2. WSN Interoperability
2.2.1. Interoperability of Network Protocols
2.2.2. Related Interoperability Approaches
2.2.3. Hardware Devices to Support Interoperability
- EFR32xG21 Wireless Gecko Starter Kit: Built with multiprotocol software and wireless SoC with Arm Cortex MCU. Wireless Gecko module has a single multiprotocol chip that “enables developers to create a mesh network and evaluate wireless connections” . First, connect a network to the module (e.g., using Bluetooth). Next, press the “PB1” button to switch between protocols—a physical button must be pressed; wait for 10–15 s to give the SoC time to readjust to the next network protocol. A unique feature of the EFR32xG21 series is the ability to manage the coexistence between Wi-Fi, Zigbee, Thread, and Bluetooth networks using the Packet Traffic Arbitration technique to avoid interference with adjacent radios between protocols. However, each network protocol operates independently and does not share data or communicate together.
- NXP USB-KW41Z dongle: A USB development board used as a packet sniffer to monitor over-the-air communication. Developers could configure packet sniffing and build customised gateways on targeted devices using Bluetooth or IEEE 802.15.4 protocols. The transmission frequency is 2.4 GHz, with ultra-low power. It is a multi-protocol MCU and not designed as a gateway interpreter or interoperable protocol. A development board facilitates monitoring of network communication in Bluetooth smart, BLE, and/or IEEE 802.15.4 protocols, since only one network protocol can operate at one single time [58,59].
- Redpine Signals RS9116/RS9113: A multiprotocol wireless SoC and modules n-Link, managed and controlled by an internal protocol arbitration manager . It manages and controls dual-band Wi-Fi (2.4/5 GHz), Dual-mode Bluetooth (4.1/5 GHz), and IEEE 802.15.4 (for Thread and Zigbee). Has ultra-low-power consumption (<50 μA), which is 25 times lower than competing solutions . Two operation modes: Hosted Mode, also called n-LinkTM (has Wi-Fi stack, Bluetooth stack and profiles, and two interfaces), and Embedded Mode, also called WiSeConnectTM (has Wi-Fi stack, TCP/IP stack, IP modules, and Bluetooth stack built within the RS9116W chip). Does not have an interoperability feature between network stacks that allows packets to travel from one network source and arrive at a different network destination.
- SimpleLink™ Multiprotocol Wireless MCU: Multiprotocol devices equipped with Microcontroller Units (MCU) to foster concurrent multiprotocol operations and coexistence with other protocols . (i) Concurrent Multiprotocol Single-chip: Allows a single radio to concurrently run multiple network protocols. Products are CC1352R, CC1352P, and CC2652R running Bluetooth LE 4.2 or Bluetooth 5.1, together with all IEEE 802.15.4 devices. (ii) Swapped Multiprotocol Provisioning: Allows devices to share or swap information such as device ID, security details, and network name (note: only possible with BLE). Products are CC1352R, CC1352P, CC2652R, CC3235SF, and CC3135 running BLE together with any network: Zigbee, Wi-Fi, or Thread; and (iii) Coexistence (Two-Chip Multiprotocol): Make use of time division multiplexing, and it allows two devices to share a single antenna without interference. Products are CC3235S and CC3235SF running BLE and Wi-Fi only.
3.1. JosNet Stack Architecture
- Firstly, all JosNet brokerage stations require a local connection host (the same concept applied in Time Synchronisation) to keep information local without the need for internet connectivity and thus maintains the objectives of this research for machine-to-machine communication. We created a local Wi-Fi hotspot for all station PCs to connect;
- Next, the requesting PC sends a trigger containing its own information: “#JS|#GAD|#HOST=192.168.1.180:2020,#NET=ZB”. This is an array of four elements from the requesting station #JS, which represents “JosNet” as an initial declaration of identity. #GAD is the second element, which represents “Get All Devices” and retrieves all information from the SPM, which are COM port, network protocol affiliated to that port (displayed as network type), active status of the COM port, baud rate, readline status, and IP and MAC address of PC. The third element is #HOST, which represents the IP address and port number of the requesting/source station. The final element is “#NET”, which represents the requesting/source network type. The source network type from the above example is Zigbee. It is important to note that any trigger without the complete element would yield an error message;
- The trigger is then picked up by the Controller of other JosNet stations; it processes the request, retrieves the information (as stated in (b)) of all the connected devices via the SPM, and attaches its hop number before the response is sent only to the IP address of the requesting brokerage station;
- Information is then populated in the table, as shown in Figure 2 above.
- For the effective interoperability of connected devices, JosNet stations make use of the Routing Table for effective routing in the large-scale implementation of JosNet.
3.2. JosNet and Network Sequence Diagram
- Phase 1 of Research:
- At point ZB1: For initialisation, clicking “Activate Listen” on JosNet allows connected USB devices to initiate connection requests in search for any advertising device; this is the case for all network protocols connected to JosNet. However, in this case, ZB1 is an external device and not connected via USB to a JosNet station. After obtaining a response from ZB2, it sends all information, including the UART COM port, address ID, PANID, baud rate, signal channel, IEEE, and address. For sending a message, clicking the “Send” button on JosNet will load the packet message on the channel, with ZB2 as the route to its target address. “M2M_ADDR_message” indicates machine-to-machine communication, therefore designed for a specified device on the network.
- At point ZB2: For Initialisation, regularly advertises for a connection request (REQ) and accepts REQ by sending “Y”, as well as sending its own device information (PANID, Device ID, channel, and more). For sending a message, packets are received from ZB1 together with information for the target destination, and it is responsible to drop off packets in the PAFP Module. Upon receiving the packet, ACK is sent back to ZB1 to confirm successful message delivery.
- At Point Station 1: JosNet scans for indicators to determine how incoming or outgoing messages should be handled. For example, “P2P_ADDR_message” is an indicator that the incoming packet has one target destination and cannot be shared across the network (broadcast) with other devices until it has arrived at its destination and “O2P_ADDR_Message” indicates a broadcast message across the network. At Station 1, JosNet looks up the Routing Table of connected devices for the following reasons: firstly, if the target destination device is connected at any point in the entire network; secondly, if the target device understands the network protocol or it is preconfigured; and thirdly, to find the quickest routing hops or path to the destination. Packets cannot be forwarded if the destination is not found on the Routing Table, and integration is activated if the source network protocol is different from the destination.
- Packets arrive at JosNet Station 1 via the physical layer of ZB2, and next, it reads all information or instruction included in the packet frame before forwarding them through the best-suited COM port to the appropriate destination (in this case, BL1 COM port). JosNet then triggers the sending command unique to Bluetooth device (BLE_ADDR_message); for Thread network, it is “UDP Send message”, and for Zigbee, it is “M2M” or “O2M”. These are unique triggers to the different network protocols. It is the responsibility of JosNet to automatically map out the correct routing path, at this point.
- At point BL1: For initialisation, all Bluetooth nodes connected to the JosNet station play both master and slave roles to allow external Bluetooth devices to connect to the network. To establish a connection, BL1 scans for available beacons and, once found, assumes the role of a master and exchanges information such as Unique Identifier, physical location, and other required details. The message “Start” is then sent across to BL2 node to confirm the connection. For sending a message, JosNet forwards received packets through BL1 COM port using “BLE_ADDR_Message” to initiate this. BL1 then sends received packets to BL2, which is connected to JosNet Station 2. Note that the connection between Bluetooth node 1 (BL1) and Bluetooth Node 2 (BL2) maintains all connection protocols standard affiliated to the technology.
- Phase 2 of Research:
- At point BL2: For initialisation, BL2 is responsible for advertising its beacon from time to time and can also scan for other available beacons. BL2 becomes the slave when BL1 requests for a connection then sends a “Y” to accept the connection request (REQ). For sending a message, BL2 receives a packet message from BL1 and drops it off at the PHY layer accessible to JosNet Station 2. Upon receiving the packet, ACK is sent back to BL1 to confirm successful message delivery.
- At point Station 2: Packet is retrieved from the PHY layer of BL2, and a check is carried out at this point by JosNet for the routing map and destination protocol. The routing map would help Station 2 place the packet on the right port for retransmission or forwarding, while knowing the destination protocol helps JosNet to carry out the right integration. Station 2 plays the same role as Station 1 (explained above). If a routing map is found, packets are then forwarded in the allocated direction; else, Station 2 sends a request for the list of devices on the network before forwarding the packet to the right destination.
- At point TH1: For initialisation, a Thread commissioner device needs to be authenticated by sending a series of initialisation codes beginning with its network name, extPANID, and PANID. When a Joiner device is found, TH1 sends the master key, starts Thread, starts ifConfig, starts commissioner, and EUI64. A connection is established after TH2 responds with further initialisation. For sending a message, the Thread commissioner device (TH1) uses “UDP send message” to send packets to TH2 when initiated from JosNet. Messages can either start from this point or be delivered here for further forwarding to the designated destination.
- At point TH2: For initialisation, the Joiner device also goes through an authentication process by starting up ifConfig and starting up Thread, Joiner ID, and the UDP bind port number, which are all sent to the commissioner device. After these are confirmed or verified by TH1, UDP is then started. NOTE that all initialisation codes with Thread network have been manually configured onto JosNet, as the OpenThread source code does not automatically provide this, giving room for programmers to configure this feature based on individual platform usage. Therefore, Thread network initialisation is configured, along with other integration processes. For sending a message, TH2 is the target destination (in this case) and therefore will not forward the message. Upon receiving the packet, ACK is sent back to TH1 to confirm successful message delivery.
3.3. Test Deployment of JosNet
3.3.1. CC2530 Zigbee Module and ZB502 Development/Evaluation Board
3.3.2. Bluetooth Core51822 Module and BLE400 Development Board
3.3.3. nRF52840-MDK IoT Development Kit
3.3.4. Nordic nRF52840 Dongle
3.4. Large-Scale Test Implementation of JosNet
4. Results and Evaluation
- End-to-end latency = time interval between departure time of first bit from source when the first bit leaves source to arrival time destination;
- Date Loss = difference between sent file size and received file size;
- Data Size = size of the data packet sent across the network from source to destination node;
- Average Time = (T1 + T2 + … + Tn)/n, where T represents time.
4.1. Experimental Setup
4.2. Experimental Results and Discussion
4.2.1. Average End-to-End Latency
4.2.2. Univariate Linear Regression Model
5. Conclusions and Future Work
- Sequence Diagram: We discussed further specific rules put in place for the integration of all connected network protocols, and they are as follows: initialisation and sending a message in device connectivity, JosNet indicators—used by the controller to determine the source and destination of a packet message, routing map—JosNet controller makes use of routing map, which is displayed on the routing table as the hop number to find the shortest path to destination devices, and JosNet Stations, which reside between any two network protocols in the sequence illustration and represent the core of JosNet;
- JosNet stack Architecture: The stack architecture shows the relationship and workflow between different components of the system;
- Repeated testing: To ensure the consistency and accuracy of the data collected, the results are repeated during every network set-up to obtain an average reading from a minimum of ten trials;
- Different network protocol set-up: Setting up communication between each network protocol (discussed in this research) to ensure all network protocols can communicate between each other;
- Large-scale implementation and routing table: It would be oversimplistic to end without implementing integration with multiple nodes. Large-scale implementation ensures that the network coverage is wide enough for large areas such as university campuses, shopping malls, large farmland, forests, and other similar wide area coverages. To accomplish this, a routing table is essential.
- Additional wireless network protocols to JosNet: A large number of network protocols or technology exists in the field of network communication regardless of the scope and delimitations of this research (limited to low-rate and low-power wireless networks); the addition of more wireless network protocols could create a robust system. JosNet has the potential to include other network technologies that transmit data in any form, as the same principle and standard applied during this research can be rebuilt, modified, or redesigned to share information within the confines of legal permits and moral standards. Information sharing is limitless in light of today’s high-speed connectivity; therefore, we envisage other network standards such as Wi-Fi, Sigfox, z-wave, LoRa, WirelessHart, etc. can be added to JosNet brokerage in the future to enhance interoperability;
- JosNet as a Hardware Device: Currently, JosNet is a piece of software application. It can be incorporated into a hardware device that can serve the same purpose within homes, offices, industries, the local community, and other commercial settings. This could provide users with the option of deciding what is best-suited for their environment or building settings. However, due to the limited resources available for this research, this cannot be possible. We used USB-connected cables to capture the activities of data packets throughout this research; this may not be practically sensible for JosNet stations to operate with PC/laptops or any other device with connected USB cables, as demonstrated;
- Security and Encryption: As mentioned earlier in the critique above, there is currently no encryption algorithm in place within JosNet to monitor packets at the PAFP before being forwarded to the next routing hop or device, as the case may be. Information such as the packet message, device IP and ID, routing table, and information included in each data frame may be captured, although very unlikely, as JosNet remains a physical station. Future work on data encryption should ensure this addition;
- Message sending for multiple selected devices: Currently, JosNet can only send to either one device node or the entire network using a “broadcast” message, regardless of the network protocol. In the future, we hope to extend the capacity of JosNet to send private messages to two nodes or more devices without broadcasting across the entire network. For example, if we have 50 connected devices on the entire network, a feature that allows users to send packet messages to only five devices would be desirable, without sending them to the 45 other devices.
Institutional Review Board Statement
Informed Consent Statement
Data Availability Statement
Conflicts of Interest
- Polastre, J.; Hui, J.; Levis, P.; Zhao, J.; Culler, D.; Shenker, S.; Stoica, I. A Unifying Link Abstraction for Wireless Sensor Networks. In Proceedings of the 3rd International Conference on Embedded Networked Sensor Systems, San Diego, CA, USA, 2–4 November 2005; Association for Computing Machinery: New York, NY, USA, 2005; pp. 76–89. [Google Scholar]
- Lee, J.-S.; Dong, M.-F.; Sun, Y.-H. A Preliminary Study of Low-power Wireless Technologies: ZigBee and Bluetooth Low Energy. In Proceedings of the 2015 IEEE 10th Conference on Industrial Electronics and Applications (ICIEA), Auckland, New Zealand, 15–17 June 2015; pp. 135–139. [Google Scholar]
- Rotsos, C.; King, D.; Farshad, A.; Bird, J.; Fawcett, L.; Georgalas, N.; Gunkel, M.; Shiomoto, K.; Wang, A.; Mauthe, A.; et al. Network Service Orchestration Standardization: A Technology Survey. Comput. Stand. Interfaces 2017, 54, 203–215. [Google Scholar] [CrossRef]
- Yannuzzi, M.; Masip-Bruin, X.; de Dios, O.G.; Argos, C.G.; Maciejewski, M.; Altmann, J. Bridging the Interoperability Gap between the Internet and Optical Network Management Systems. In Proceedings of the 2011 16th European Conference on Networks and Optical Communications, Newcastle upon Tyne, UK, 20–22 July 2011; pp. 177–180. [Google Scholar]
- Xia, Y.; Zeng, H.; Shen, Z. Design and Implementation of Switch Module for NS-3. In Proceedings of the Fourth International ICST Conference on Performance Evaluation Methodologies and Tools, Pisa, Italy, 20–22 October 2009; ICST (Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering): Brussels, Belgium, 2009; pp. 1–10. [Google Scholar]
- De Sanctis, M.; Stallo, C.; Parracino, S.; Ruggieri, M.; Prasad, R. Interoperability Solutions between Smartphones and Wireless Sensor Networks. In Proceedings of the 2012 IEEE First AESS European Conference on Satellite Telecommunications (ESTEL), Rome, Italy, 2–5 October 2012; pp. 1–6. [Google Scholar]
- Bello, O.; Zeadally, S.; Badra, M. Network Layer Inter-Operation of Device-to-Device Communication Technologies in Internet of Things (IoT). Ad Hoc Netw. 2017, 57, 52–62. [Google Scholar] [CrossRef]
- Wibowo, S.B.; Putra, G.D.; Hantono, B.S. Development of Embedded Gateway for Wireless Sensor Network and Internet Protocol Interoperability. In Proceedings of the 2014 6th International Conference on Information Technology and Electrical Engineering (ICITEE), Yogyakarta, Indonesia, 7–8 October 2014; pp. 1–4. [Google Scholar]
- Molina, B.; Palau, C.E.; Fortino, G.; Guerrieri, A.; Savaglio, C. Empowering Smart Cities through Interoperable Sensor Network Enablers. In Proceedings of the 2014 IEEE International Conference on Systems, Man, and Cybernetics (SMC), San Diego, CA, USA, 5–8 October 2014; pp. 7–12. [Google Scholar]
- Soursos, S.; Žarko, I.P.; Zwickl, P.; Gojmerac, I.; Bianchi, G.; Carrozzo, G. Towards the Cross-Domain Interoperability of IoT Platforms. In Proceedings of the 2016 European Conference on Networks and Communications (EuCNC), Atehns, Greece, 27–30 June 2016; pp. 398–402. [Google Scholar]
- Lin, C.; Kuo, J.; Liu, B.; Tsai, M. GPS-Free, Boundary-Recognition-Free, and Reliable Double-Ruling-Based Information Brokerage Scheme in Wireless Sensor Networks. IEEE Trans. Comput. 2012, 61, 885–898. [Google Scholar] [CrossRef]
- Ma, X.; Xue, Y. Adaptive Information Brokerage in Wireless Sensor Networks with Mobile Sinks. In Proceedings of the 2012 IEEE 12th International Conference on Computer and Information Technology, Chengdu, China, 27–29 October 2012; pp. 1–4. [Google Scholar]
- Gartner, G. Definition of IB (Integration Broker)—Gartner Information Technology Glossary. Available online: https://www.gartner.com/en/information-technology/glossary/ib-integration-broker (accessed on 9 October 2020).
- Elkhodr, M.; Shahrestani, S.; Cheung, H. The Internet of Things: New Interoperability, Management and Security Challenges. IJNSA 2016, 8, 85–102. [Google Scholar] [CrossRef]
- Noura, M.; Atiquzzaman, M.; Gaedke, M. Interoperability in Internet of Things: Taxonomies and Open Challenges. Mob. Netw. Appl 2019, 24, 796–809. [Google Scholar] [CrossRef][Green Version]
- Vasseur, J.-P.; Dunkels, A. Chapter 1—What Are Smart Objects. In Interconnecting Smart Objects with IP; Morgan Kaufmann: Boston, MA, USA, 2010; pp. 3–20. ISBN 978-0-12-375165-2. [Google Scholar]
- O’Connor, S. What Is Interoperability, and Why Is It Important? Available online: https://www.adsc.com/blog/what-is-interoperability-and-why-is-it-important (accessed on 3 April 2021).
- Atlam, H.F.; Wills, G.B. Chapter One—Technical Aspects of Blockchain and IoT. In Advances in Computers; Kim, S., Deka, G.C., Zhang, P., Eds.; Role of Blockchain Technology in IoT Applications; Elsevier: Amsterdam, The Netherlands, 2019; Volume 115, pp. 1–39. Available online: https://www.sciencedirect.com/science/article/abs/pii/S0065245818300664 (accessed on 22 November 2021).
- Gomez, C.; Paradells, J. Wireless Home Automation Networks: A Survey of Architectures and Technologies. IEEE Commun. Mag. 2010, 48, 92–101. [Google Scholar] [CrossRef]
- Nolan, K.E.; Guibene, W.; Kelly, M.Y. An Evaluation of Low-power Wide Area Network Technologies for the Internet of Things. In Proceedings of the 2016 International Wireless Communications and Mobile Computing Conference (IWCMC), Paphos, Cyprus, 5–9 September 2016; pp. 439–444. [Google Scholar]
- Krupka, L.; Vojtech, L.; Neruda, M. The Issue of LPWAN Technology Coexistence in IoT Environment. In Proceedings of the 2016 17th International Conference on Mechatronics—Mechatronika (ME), Prague, Czech Republic, 7–9 December 2016; pp. 1–8. [Google Scholar]
- ANT+ Tech FAQ—THIS IS ANT. Available online: https://www.thisisant.com/developer/resources/tech-faq/category/10 (accessed on 4 August 2020).
- IEEE Std 802.15.4-2020; IEEE Standard for Low-Rate Wireless Networks. (Revision of IEEE Std 802.15.4-2015). IEEE: Manhattan, NY, USA, 2020. Available online: https://ieeexplore.ieee.org/document/9144691 (accessed on 22 November 2021). [CrossRef]
- Hossen, M.S.; Kabir, A.F.M.S.; Khan, R.H.; Azfar, A. Interconnection between 802.15.4 Devices and IPv6: Implications and Existing Approaches. arXiv 2010, arXiv:1002.1146. [Google Scholar]
- IEEE Std 802.15.1-2005; IEEE Standard for Information Technology—Local and Metropolitan Area Networks—Specific Requirements—Part 15.1a: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Wireless Personal Area Networks (WPAN). (Revision of IEEE Std 802.15.1-2002). IEEE: Manhattan, NY, USA, 2005; pp. 1–700. Available online: https://ieeexplore.ieee.org/document/1490827 (accessed on 29 November 2021). [CrossRef]
- Balota, J.; Kor, A.-L.; Pattinson, C. Wireless Personal Area Networks—A Survey of Low-Rate and Low-power Network Technologies. In Proceedings of the World Congress on Sustainable Technologies; IEEE: Cambridge, UK, 2017; pp. 68–72. [Google Scholar]
- IEEE Std 610.12-1990; IEEE Standard Glossary of Software Engineering Terminology. IEEE: Manhattan, NY, USA, 1990; pp. 1–84. Available online: https://ieeexplore.ieee.org/document/159342 (accessed on 23 December 2021). [CrossRef]
- Schrickte, L.F.; Montez, C.; De Oliveira, R.; Pinto, A.R. Integration of Wireless Sensor Networks to the Internet of Things Using a 6LoWPAN Gateway. In Proceedings of the 2013 III Brazilian Symposium on Computing Systems Engineering, Niteroi, Brazil, 4–8 December 2013; pp. 119–124. [Google Scholar]
- Qiao, B.; Ma, K. An Enhancement of the ZigBee Wireless Sensor Network Using Bluetooth for Industrial Field Measurement. In Proceedings of the 2015 IEEE MTT-S International Microwave Workshop Series on Advanced Materials and Processes for RF and THz Applications (IMWS-AMP), Suzhou, China, 1–3 July 2015; pp. 1–3. [Google Scholar]
- Hawelikar, M.; Tamhankar, S. A Design of Linux Based ZigBee and Bluetooth Low Energy Wireless Gateway for Remote Parameter Monitoring. In Proceedings of the 2015 International Conference on Circuits, Power and Computing Technologies [ICCPCT-2015], Nagercoil, India, 19–20 March 2015; pp. 1–4. [Google Scholar]
- Gazis, V. A Survey of Standards for Machine-to-Machine and the Internet of Things. IEEE Commun. Surv. Tutor. 2017, 19, 482–511. [Google Scholar] [CrossRef]
- Montori, F.; Bedogni, L.; Di Felice, M.; Bononi, L. Machine-to-Machine Wireless Communication Technologies for the Internet of Things: Taxonomy, Comparison and Open Issues. Pervasive Mob. Comput. 2018, 50, 56–81. [Google Scholar] [CrossRef]
- Garroppo, R.G.; Gazzarrini, L.; Giordano, S.; Tavanti, L. Experimental Assessment of the Coexistence of Wi-Fi, ZigBee, and Bluetooth Devices. In Proceedings of the 2011 IEEE International Symposium on a World of Wireless, Mobile and Multimedia Networks, Lucca, Italy, 20–24 June 2011; pp. 1–9. [Google Scholar]
- Sonee, S. Top IoT Communication Protocols Updated 2021—ZigBee, NFC, And More 2020. Available online: https://hashstudioz.com/blog/top-iot-communication-protocols-2020/ (accessed on 20 September 2021).
- Shi, G.; Li, K. Signal Interference in WiFi and ZigBee Networks; Wireless Networks; Springer International Publishing: Cham, Switzerland, 2017; ISBN 978-3-319-47805-0. [Google Scholar]
- Lu, B.; Qin, Z.; Sun, Y.; Hu, J.; Wang, L. A Dynamic Self-Adapting Mechanism for ZigBee Performance Assurance under Wi-Fi Interference. IEEE Sens. J. 2018, 18, 3900–3909. [Google Scholar] [CrossRef]
- Li, P.; Yan, Y.; Yang, P.; Li, X.; Lin, Q. Coexist WiFi for ZigBee Networks with Fine-Grained Frequency Approach. IEEE Access 2019, 7, 135363–135376. [Google Scholar] [CrossRef]
- Tabish, R.; Ben Mnaouer, A.; Touati, F.; Ghaleb, A.M. A Comparative Analysis of BLE and 6LoWPAN for U-HealthCare Applications. In Proceedings of the 2013 7th IEEE GCC Conference and Exhibition (GCC), Doha, Qatar, 17–20 November 2013; pp. 286–291. [Google Scholar]
- Yacchirema, D.C.; Palau, C.E.; Esteve, M. Enable IoT Interoperability in Ambient Assisted Living: Active and Healthy Aging Scenarios. In Proceedings of the 2017 14th IEEE Annual Consumer Communications Networking Conference (CCNC), Las Vegas, NV, USA, 8–11 January 2017; pp. 53–58. [Google Scholar]
- Freescale Semiconductor; NXP Semiconductors Freescale IEEE® 802.15.4/ZigBeeTM. 2010. Available online: https://www.nxp.com/docs/en/reference-manual/ZRFETRM.pdf (accessed on 23 December 2021).
- Lennvall, T.; Svensson, S.; Hekland, F. A Comparison of WirelessHART and ZigBee for Industrial Applications. In Proceedings of the 2008 IEEE International Workshop on Factory Communication Systems, Dresden, Germany, 21–23 May 2008; pp. 85–88. [Google Scholar]
- Rahman, T.; Chakraborty, S.K. Provisioning Technical Interoperability within ZigBee and BLE in IoT Environment. In Proceedings of the 2018 2nd International Conference on Electronics, Materials Engineering Nano-Technology (IEMENTech), Kolkata, India, 4–5 May 2018; pp. 1–4. [Google Scholar]
- Aloi, G.; Caliciuri, G.; Fortino, G.; Gravina, R.; Pace, P.; Russo, W.; Savaglio, C. A Mobile Multi-Technology Gateway to Enable IoT Interoperability. In Proceedings of the 2016 IEEE First International Conference on Internet-of-Things Design and Implementation (IoTDI), Berlin, Germany, 4-8 April 2016; pp. 259–264. [Google Scholar]
- Chen, J.; Tarn, W.-H.; Hsu, W.-H.; Wang, C.-C. Cross-Layer End-to-End Label Switching Protocol for WiMAX–MPLS Heterogeneous Networks. J. Syst. Softw. 2012, 85, 2459–2469. [Google Scholar] [CrossRef]
- Smith, S. Introduction to MPLS. 2003. Available online: https://www.cisco.com/c/dam/global/fr_ca/training-events/pdfs/Intro_to_mpls.pdf (accessed on 20 September 2021).
- Azher, I.; Aurengzeb, M.; Masood, K. Virtual Private Network Implementation Over Multiprotocol Label Switching. In Proceedings of the 2005 Student Conference on Engineering Sciences and Technology, Karachi, Pakistan, 27 August 2005; pp. 1–5. [Google Scholar]
- Metz, C. Multiprotocol Label Switching and IP. Part 2. Multicast Virtual Private Networks. IEEE Internet Comput. 2006, 10, 76–81. [Google Scholar] [CrossRef]
- Ali, Z.B.; Samad, M.; Hashim, H. Performance Comparison of Video Multicasting over Asynchronous Transfer Mode (ATM) Multiprotocol Label Switching (MPLS) Networks. In Proceedings of the 2011 IEEE International Conference on System Engineering and Technology, Shah Alam, Malaysia, 27–28 June 2011; pp. 177–182. [Google Scholar]
- Shawl, R.Q.; Thaker, R. A Review: Multi Protocol Label Switching (Mpls). Int. J. Eng. Res. Appl. 2014, 4, 66–70. Available online: http://www.ijera.com/papers/Vol4_issue1/Version%202/I41026670.pdf (accessed on 20 September 2021).
- De Ghein, L. MPLS Fundamentals; Cisco Press Fundamentals Series; Cisco Press: Indianapolis, IN, USA, 2007; ISBN 978-1-58705-197-5. [Google Scholar]
- Exponential-e Exponential-e: The Network, the Technology and the Service. Available online: https://www.exponential-e.com/ (accessed on 20 September 2021).
- Balus, F.; Bitar, N.; Salam, S.; Sajassi, A. Virtual Private LAN Service (VPLS) Interoperability with Provider Backbone Bridges. Available online: https://tools.ietf.org/html/rfc7080 (accessed on 7 April 2021).
- Juniper Networks Interoperability between BGP Signaling and LDP Signaling in VPLS | Juniper Networks TechLibrary. Available online: https://www.juniper.net/documentation/us/en/software/junos/vpn-l2/topics/concept/vpn-bgp-signaling-and-ldp-signaling-interoperability-in-vpls.html (accessed on 7 April 2021).
- Zhang, F.; Zuo, Y.; Chou, L. Research on Metro Intelligent Optical Network Planning and Optimization. In Proceedings of the 2016 15th International Conference on Optical Communications and Networks (ICOCN), Hangzhou, China, 24–27 September 2016; pp. 1–3. [Google Scholar]
- Baroncelli, F.; Martini, B.; Castoldi, P. Autonomic Service Provisioning for Automatically Switched Transport Network. In Proceedings of the COIN-NGNCON 2006—The Joint International Conference on Optical Internet and Next Generation Network, Jeju, Korea, 9–13 July 2006; pp. 15–17. [Google Scholar]
- Casellas, R.; Muñoz, R.; Martínez, R.; Vilalta, R.; Mayoral, A.; Liu, L.; Tsuritani, T.; Morita, I. Overarching Control of Flexi Grid Optical Networks: Interworking of GMPLS and OpenFlow Domains. J. Lightwave Technol. 2015, 33, 1054–1062. [Google Scholar] [CrossRef]
- Silicon Labs. EFR32xG21 Wireless Gecko Reference Manual. 2019. Silicon Laboratories Inc. Available online: https://www.silabs.com/documents/public/reference-manuals/efr32xg21-rm.pdf (accessed on 10 May 2021).
- NXP Semiconductors USB-KW41Z|Bluetooth Low Energy Thread Zigbee Wireless Packet Sniffer | NXP Semiconductors. Available online: https://www.nxp.com/design/development-boards/freedom-development-boards/wireless-connectivy/bluetooth-low-energy-ieee-802-15-4-packet-sniffer-usb-dongle:USB-KW41Z (accessed on 6 April 2021).
- Zhuvasin, P. A Healthcare Monitoring Device. Technology and Communication; Vaasan Ammattikorkeakoulu, Vaasa University of Applied Sciences: Vaasan, Finland, 2019. [Google Scholar]
- Redpine, S. Multi-Protocol Wireless SoCs & Modules | Hosted Connectivity | Redpine Signals. Available online: https://www.redpinesignals.com/Products/Hosted_Connectivity/Multi-Protocol_Wireless_SoCs_&_Modules/ (accessed on 28 May 2020).
- René, H.; Rutronik, E.W. Redpine Signals’ Multiprotocol Wireless SoCs and Modules at Rutronik. Available online: https://www.rutronik.com/en/article/detail/News/redpine-signals-multiprotocol-wireless-socs-and-modules-at-rutronik/ (accessed on 28 May 2020).
- Texas Instruments LAUNCHXL-CC1352R1 Development Kit|TI.Com. Available online: https://www.ti.com/tool/LAUNCHXL-CC1352R1#overview (accessed on 7 April 2021).
- Pratik, T.; Lenka, R.K.; Nayak, G.K.; Kumar, A. An Architecture to Support Interoperability in IoT Devices. In Proceedings of the 2018 International Conference on Advances in Computing, Communication Control and Networking (ICACCCN), Greater Noida, India, 12–13 October 2018; pp. 705–710. [Google Scholar]
- March, S.T.; Smith, G.F. Design and Natural Science Research on Information Technology. Decision Support Systems 1995, 15, 251–266. [Google Scholar] [CrossRef]
- Oates, B.J. Researching Information Systems and Computing; SAGE Publications: London, UK; Thousand Oaks, CA, USA, 2006; ISBN 978-1-4129-0223-6. [Google Scholar]
- Saltuk, O.; Kosan, I.; Design and Creation. Ludwig Maximilian University of Munich. 2014. Available online: https://www.medien.ifi.lmu.de/lehre/ss14/swal/presentations/topic2-saltuk_kosan-DesignAndCreation.pdf (accessed on 15 April 2021).
- Repenning, A.; Webb, D.C.; Koh, K.H.; Nickerson, H.; Miller, S.B.; Brand, C.; Horses, I.H.M.; Basawapatna, A.; Gluck, F.; Grover, R.; et al. Scalable Game Design: A Strategy to Bring Systemic Computer Science Education to Schools through Game Design and Simulation Creation. ACM Trans. Comput. Educ. 2015, 15, 11:1–11:31. [Google Scholar] [CrossRef]
- ARTiFACTS. What Is an Artifact? Everything You Need to Know. 2020. Available online: https://artifacts.ai/what-is-an-artifact/ (accessed on 15 April 2021).
- Kammer, D.; McNutt, G.; Senese, B.; Bray, J. (Eds.) Chapter 2—Exploring the Foundations of Bluetooth. In Bluetooth Application Developer’s Guide; Syngress: Burlington, NJ, USA, 2002; pp. 69–102. ISBN 978-1-928994-42-8. [Google Scholar]
- Dhongdi, S.C.; Nahar, P.; Sethunathan, R.; Gudino, L.J.; Anupama, K.R. Cross-Layer Protocol Stack Development for Three-Dimensional Underwater Acoustic Sensor Network. J. Netw. Comput. Appl. 2017, 92, 3–19. [Google Scholar] [CrossRef]
- Matsumoto, A.; Yokogawa, T.; Amasaki, S.; Aman, H.; Arimoto, K. Consistency Verification of UML Sequence Diagrams Modeling Wireless Sensor Networks. In Proceedings of the 2019 8th International Congress on Advanced Applied Informatics (IIAI-AAI), Toyama, Japan, 7–11 July 2019; pp. 458–461. [Google Scholar]
- Samuel, P.; Joseph, A.T. Test Sequence Generation from UML Sequence Diagrams. In Proceedings of the 2008 Ninth ACIS International Conference on Software Engineering, Artificial Intelligence, Networking, and Parallel/Distributed Computing, Phuket, Thailand, 6–8 August 2008; pp. 879–887. [Google Scholar]
- IEEE Std 802.15.4-2015; IEEE Standard for Low-Rate Wireless Networks. (Revision of IEEE Std 802.15.4-2011). IEEE: Manhattan, NY, USA, 2016; pp. 1–709. Available online: https://ieeexplore.ieee.org/document/7460875 (accessed on 28 November 2020). [CrossRef]
- Mankar, D.; Chaudhari, B.S. Dynamic Performance Analysis of IEEE 802.15.4 Devices under Various RF Interferences. In Proceedings of the 2016 International Conference on Inventive Computation Technologies (ICICT), Coimbatore, India, 26–27 August 2016; Volume 1, pp. 1–4. [Google Scholar]
- Waveshare CC2530 Eval Kit ZigBee Development/Evaluation Kit Designed for CC2530F256. Available online: https://www.waveshare.com/product/iot-communication/short-range-wireless/zigbee/cc2530-eval-kit.htm (accessed on 2 December 2020).
- Waveshare NRF51822 Eval Kit BLE4.0 Bluetooth 2.4G Development/Evaluation Kit Designed for NRF51822. Available online: https://www.waveshare.com/product/iot-communication/short-range-wireless/bluetooth/nrf51822-eval-kit.htm (accessed on 21 September 2021).
- Makerdiary NRF52840-MDK IoT Development Kit. Available online: https://makerdiary.com/products/nrf52840-mdk-iot-development-kit (accessed on 15 August 2020).
- Nordic Semiconductors. NRF Connect for Desktop. Available online: https://www.nordicsemi.com/Software-and-tools/Development-Tools/nRF-Connect-for-desktop (accessed on 14 November 2020).
- Wynants, L.; Bouwmeester, W.; Moons, K.G.M.; Moerbeek, M.; Timmerman, D.; Van Huffel, S.; Van Calster, B.; Vergouwe, Y. A Simulation Study of Sample Size Demonstrated the Importance of the Number of Events per Variable to Develop Prediction Models in Clustered Data. J. Clin. Epidemiol. 2015, 68, 1406–1414. [Google Scholar] [CrossRef] [PubMed][Green Version]
- Forouzan, B.A.; Fegan, S.C. Data Communications and Networking, 4th ed.; McGraw-Hill Forouzan Networking Series; McGraw-Hill Higher Education: New York, NY, USA, 2007; ISBN 978-0-07-325032-8. [Google Scholar]
- Singhal, S.; Zyda, M. Networked Virtual Environments: Design and Implementation; SIGGRAPH Series; Addison-Wesley: Reading, MA, USA, 1999; ISBN 978-0-201-32557-7. [Google Scholar]
- Smed, J.; Kaukoranta, T.; Hakonen, H. Aspects of Networking in Multiplayer Computer Games. In Proceedings of the International Conference on Application and Development of Computer Games in the 21st Century (ADCOG), Hong Kong, China, 1 November 2001; pp. 74–81. [Google Scholar]
- Hammarfelt, B.; de Rijcke, S. Accountability in Context: Effects of Research Evaluation Systems on Publication Practices, Disciplinary Norms, and Individual Working Routines in the Faculty of Arts at Uppsala University. Res. Eval. 2015, 24, 63–77. [Google Scholar] [CrossRef][Green Version]
- Dong, G.; Taslimitehrani, V. Pattern-Aided Regression Modeling and Prediction Model Analysis. IEEE Trans. Knowl. Data Eng. 2015, 27, 2452–2465. [Google Scholar] [CrossRef]
- Cook, R.D.; Weisberg, S. Criticism and Influence Analysis in Regression. Sociol. Methodol. 1982, 13, 313–361. [Google Scholar] [CrossRef]
- Behera, A.; Panigrahi, A. Determining the Network Throughput and Flow Rate Using GSR and AAL2R. Int. J. UbiComp 2015, 6, 09–18. [Google Scholar] [CrossRef]
- Sharma, M. Transmission Time and Throughput Analysis of EEE LEACH, LEACH and Direct Transmission Protocol: A Simulation Based Approach. Adv. Comput. Int. J. 2012, 3, 75–82. [Google Scholar] [CrossRef]
- Eugene, P. What Is Protocol Overhead? Available online: http://www.easytechjunkie.com/what-is-protocol-overhead.htm (accessed on 14 March 2021).
- Liu, K. Performance Evaluation of ZigBee Network for Embedded Electricity Meters. Master’s Thesis, KTH Electrical Engineering, Stockholm, Sweden, 2009. [Google Scholar]
- Wilson, M. Network Throughput—What Is It, How to Measure & Optimize for Speed! Available online: https://www.pcwdld.com/network-throughput (accessed on 15 March 2021).
- Silicon Labs. AN1137: Bluetooth Mesh Network Performance. Silicon Laboratories Inc.. Available online: https://www.silabs.com/documents/public/application-notes/an1137-bluetooth-mesh-network-performance.pdf (accessed on 3 April 2021).
- Silicon Labs. AN1138: Zigbee Mesh Network Performance. Silicon Laboratories Inc. Available online: https://www.silabs.com/documents/login/application-notes/an1138-zigbee-mesh-network-performance.pdf (accessed on 3 March 2021).
- Decuir, J. Bluetooth 4.0: Low Energy, February 2014. Available online: https://californiaconsultants.org/wp-content/uploads/2014/05/CNSV-1205-Decuir.pdf (accessed on 15 March 2021).
- Afaneh, M. The Ultimate Bluetooth Low Energy (BLE) Guide. Novel Bits. 6 March 2016. Available online: https://www.novelbits.io/basics-bluetooth-low-energy/ (accessed on 15 March 2021).
- Silicon Labs. AN1141: Thread Mesh Network Performance. Silicon Laboratories Inc. Available online: https://www.silabs.com/documents/login/application-notes/an1141-thread-mesh-network-performance.pdf (accessed on 10 March 2021).
|OSI Reference Model||BL Protocol Stack|
|Application Layer||ZDO||User defined||HART7, HART AL, EDDL||APPS Layer||Higher Layers |
APP (Application profiles and Services)
|Session Layer||AES 128-bit encryption||SHA-256||AES 128-bit encryption||HOST Layer||GAP (Generic Access Profile) |
GATT (Generic Attribute Profile)
|Transport Layer||UDP||UDP + DTLS||UDP|
|Network Layer||Ad-hoc On-Demand Distance Vector (AODV)||Distance Vector Routing (DVR), |
|6LoWPAN, TDMA||ATT (Attribute Protocol), SMP (Security Manager)|
|Data Link Layer|
|IEEE 802.15.4 MAC||CSMA/CA||IEEE 802.15.4 MAC||L2CAP (Logical Link Control and Adaptation Protocol)|
|CONTROLLER Layer||Link Layer (LL)|
|IEEE 802.15.4 PHY||IEEE 802.15.4 PHY||IEEE 802.15.4, DSSS||BL PHY (Physical Layer)|
|RF Band||868/915/2400 MHz||2.4 GHz||868/915/2400 MHz||2.4–2.48 GHz|
|Transfer Rate||20/40/250 kbps||250 Kbps||20/40/250 kbps||125/500/1000/2000 kbps|
|Range||10–100 m||100 m||10–100 m||Up to 100 m|
|Channel Width||5 MHz||5 MHz||5 MHz||Forty 2 MHz channels|
|Error Control||Cyclic Redundancy Check (CRC)||Cyclic Redundancy Check (CRC)||16-bit CRC and ACK (Acknowledgement)||Cyclic Redundancy Check (CRC)|
|Data Size (Bytes)||Average Transmission Time (s)||Average End-to-End Latency Time (s)||Data Size (Bytes)||Average Transmission Time (s)||Average End-to-End Latency Time (s)|
|Data Size (Bytes)||Average Transmission Time (s)||Average End-to-End Latency Time (s)||Data Size (Bytes)||Average Transmission Time (s)||Average End-to-End Latency Time (s)|
|Data Size (Bytes)||Average Transmission Time (s)||Average End-to-End Latency Time (s)||Data Size (Bytes)||Average Transmission Time (s)||Average End-to-End Latency Time (s)|
|Data Size (Bytes)||Average Transmission Time (s)||Average End-to-End Latency Time (s)|
|Connection Pairs||Regression Model|
End-to-End Latency Model
|ZB–ZB||End-to-End Latency (Y) = 0.0001 × DS + 0.0345 (A)||0.7031|
|BL–BL||End-to-End Latency (Y) = 0.0001 × DS + 0.0265 (A)||0.6546|
|ZB–TH||End-to-End Latency (Y) = 0.0003 × DS + 0.0436 (A)||0.8001|
|TH–ZB||End-to-End Latency (Y) = 0.0004 × DS + 0.0533 (A)||0.8719|
|TH–TH||End-to-End Latency (Y) = 0.0002 × DS + 0.0098 (A)||0.9995|
|ZB–BL||End-to-End Latency (Y) = 0.0004 × DS + 0.0443 (A)||0.9240|
|Average Throughput (kbps)|
|Data Size (Bytes)||ZB–ZB||BL–BL||TH–TH||ZB–BL||ZB–TH||TH–ZB|
|Connection Pairs||Regression Model|
Average Throughput (kbps)
|ZB–ZB||Throughput (Y) = 0.0666 × DS + 12.939 (A)||0.9957|
|BL–BL||Throughput (Y) = 0.1137 × DS + 82.564 (A)||0.9058|
|TH–TH||Throughput (Y) = 0.0981 × DS + 35.722 (A)||0.9945|
|ZB–BL||Throughput (Y) = 0.0553 × DS + 11.039 (A)||0.9599|
|ZB–TH||Throughput (Y) = 0.0617 × DS + 16.558 (A)||0.9885|
|TH–ZB||Throughput (Y) = 0.0718 × DS + 25.290 (A)||0.9651|
Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.
© 2022 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https://creativecommons.org/licenses/by/4.0/).
Balota, J.E.; Kor, A.-L. Brokerage System for Integration of LrWPAN Technologies. Sensors 2022, 22, 1733. https://doi.org/10.3390/s22051733
Balota JE, Kor A-L. Brokerage System for Integration of LrWPAN Technologies. Sensors. 2022; 22(5):1733. https://doi.org/10.3390/s22051733Chicago/Turabian Style
Balota, Josiah E., and Ah-Lian Kor. 2022. "Brokerage System for Integration of LrWPAN Technologies" Sensors 22, no. 5: 1733. https://doi.org/10.3390/s22051733