5g
Factories of the Future
Media & Entertainment
Smart Cities
Smart Energy
Smart Ports
SME Opportunities
Societal Impacts
Technology Development
Telecoms Providers
5G CAM
5G Automotive
5G CAM KPIs
5G CAM Standardisation
5G Corridors
5G Multimodal Connectivity
5G Transport Network
Artificial Intelligence & Machine Learning
Artificial Intelligence & Machine Learning in big data
Artificial Intelligence & Machine Learning technologies
Big data
Big data algorithms
Big data analytics
Collaborative Classification and Models
Business Models, Process Improvement, Contract Management, KPIs and Benchmarking Indexes
Collaboration Risk and Value Sharing
Collaborative Planning and Synchromodality
Customs & Regulatory Compliance
Environmental Performance Management
Logistics Optimisation
Stock Optimisation
Supply Chain Corrective and Preventive Actions (CAPA)
Supply Chain Financing
Supply Chain Visibility
Common Information Objects
Booking
Customs Declarations
Transport Service Description
Transport Status
Waybills
Computing and Processing
Big Data Management and Analytics
Cloud
Edge
Fog
Knowledge Graphs
Machine Learning
MIST
Stream Processing
Connectivity
Architecture
Blockchain
Connectivity Interfaces
Technologies (Bluetooth, Ethernet, Wifi)
Data Management, Simulation and Dashboards
Dashboards
Data Fusion
Data Governance, Integrity, Quality Management and Harmonization
Event Handling
Open Data
Simulation
Statistics and Key Performance Indicators (KPIs)
Data market
Data ecosystem
Data marketplace
Data Platform
Data Providers
Devices
IoT Controllers
IoT Gateways
IoT Sensors
Tracking Sensors
Digitisation Frameworks
Control Towers
Data Pipelines
e-Freight
e-Maritime
National Single Windows
Port Community Systems
Federation
Data Federation
Platform Federation
Industrial IoT Sectors
Rail Sector Active Predictive Maintenance
Interoperability
Data interoperability
Data interoperability mechanisms
Interoperability solutions
Platform interoperability
IoT Secuirty, Privacy and Safety Systems
PKI Technology
Privacy-preservation
Data privacy preserving technologies
Privacy preserving technologies
Project Results
5G-SOLUTIONS Deliverables
5G-SOLUTIONS Publications
CHARIOT Capacity Building and Trainings
CHARIOT Deliverables
CHARIOT Publications
SELIS Deliverables
SELIS Publications and Press Releases
Project Results - 5g Routes
5G-ROUTES Deliverables
5G-ROUTES Innovation
5G-ROUTES Publications
Project Results - TRUSTS
TRUSTS Deliverable
TRUSTS Publications
Safety, Security and Privacy Systems
Access Management
Coordinated Border Management
Information Security
International Organisations
Risk Assessment and Management
Risk Management
Safety and Security Assessment
Source Code Analysis
Sectors and Stakeholders
Airports and Air Transport
Banks, investors and other funding providers
Custom Authorities
Facilities, Warehouses
Freight Forwarders
Inland Waterways
Multimodal Operators
Ports and Terminals
Railway
Retailers
Road Transport
Shippers
Shipping
Smart Buildings
Trusties and other Intermediary Organizations
Urban and Countryside Logistics
Urban Logistics
Sectors and Stakeholders - TRUSTS
Audit & Law firms
Corporate offices
Enterprises
Financial Institutions
Telecommunications
Security
Secured Data
Secured Infrastructure
Secured Platform
Sovereignty
Data sovereignty
Standards
Good Distribution Practices
International data standards
International Organization for Standardization (ISO)
UN/CEFACT
World Customs Organization (WCO)
Supply Chain Management
Business Models, Process Improvement, Contract Management, KPIs and Benchmarking Indexes
Risk Management
Risk-Based Controls
Screening and tracking
Supervision Approach
Technologies
5g
Agile Deployment, Configuration Management
Business Applications
Business Integration Patterns, Publish-Subscribe
Cloud Technologies/Computing, Services Virtualisation
Cognitive
Community Node Platform and Application Monitoring
Connectivity Technologies (Interfaces and Block Chain)
Hybrid S/T Communication and Navigation Platforms
IoT (Sensors, platforms)
Mobile
Physical Internet (PI)
Public key infrastructure (PKI)
Radio-frequency identification (RFID)

IoT Gateways

An experimental study of a reliable IoT gateway
Byungseok Kang, Hyunseung Choo 27/04/2017 00:00:00

1. Introduction

Many works have been carried out to advance Internet of Things (IoT) technology in business domains  [1], [2] because of the value gained by connecting an endpoint device for system reliability, automation, and centralized management. Although developed for business applications, many of these advances are applicable to all types of smart systems, including wearables, mobile phones, healthcare equipment, security devices, and cloud and deep-learning systems  [3], [4]. For engineers, the greatest challenge in designing the IoT is reliability  [5], [6]. The implementation of robust and secure access to the Internet or a wide area network (WAN) is outside their range of experience. To make design even more difficult, developers need to support access to multiple devices that are limited in their processing capability. Reliability must also be added in a way that does not adversely impact the overall cost efficiency  [7], [8], [9].

The diversity of endpoints that a gateway must support raises design concerns  [10], [11] as well. The direct connection of a simple device such as a humidity sensor to the Internet can be complex and expensive, especially if the device does not have its own processor. In addition, different types of end equipment support varying interfaces. The collection and aggregation of data from a disparate set of nodes require a means for bridging devices with a range of processing capabilities and interfaces together in a consistent and reliable way  [12], [13]. Gateways offer an elegant means for simplifying the networking of “things”. They achieve this by supporting the different methods of device connection, whether this is a varying voltage from a raw sensor, a stream of data over I2C from an encoder, or periodic updates from an appliance via WiFi. Gateways effectively mitigate the great variety and diversity of devices by consolidating data from disparate sources and interfaces and bridging them to the Internet. The result is that individual nodes do not need to bear the complexity or cost of a high-speed Internet interface in order to be connected.

An IoT gateway is an intelligent component based on an IoT platform  [14], [15]. It is typically employed between the network of the machine-to-machine (M2M) devices and the remote peers (e.g., clients) over the internet. The basic goal of the gateway is to settle the heterogeneity between different endpoint networks and the Internet, strengthen the management of the endpoint networks, and bridge the traditional Internet with endpoint networks. As state-of-the-art IoT gateways  [16], [17] are designed to connect to mobile and wireless networks, they emphasize the provision of flexible connections among smart devices and a user’s cloud to enable intelligent big data analysis and data-driven decision-making. Furthermore, they can be flexibly configured with different protocol-ready modules to communicate with end nodes or I/O devices.

However, current IoT gateways  [14] operate passively or semi-automatically. This means that, when a user buys a new IoT device, he/she manually installs the device using the setup manual. After that, the IoT gateway asks the user whether a new device should be registered. To solve this problem, we propose a reliable IoT gateway for small-scale IoT environments in this paper. When a user brings a new device in their home, the IoT gateway automatically detects this new device and registers this device by itself. If the user discards old devices from his/her home, the smart IoT gateway automatically deletes that device from the device list. In our system, the user does not have to worry about registering and installing new IoT devices. In the following sections, we detail our proposed self-configurable IoT gateway. The development of the testbed is presented in Section  3. Finally, we conclude the paper in Section  4.

 

2. Basic design of the self-configurable IoT gateway

 IoT gateways available today allow a user to configure a few properties such as the TV channel, light, refrigerator, etc. However, future smart homes, particularly those based on software-defined networks, are likely to have very rich configuration controls. The goal of this research is to develop algorithms that enable an IoT gateway to automatically configure itself. We propose an initial study of autoconfiguration that considers two properties: dynamic discovery and autoregistration.

We designed the IoT gateway using the IoTivity framework  [18]. The interaction model of IoTivity is similar to the client/server model of HTTP and uses the CoAP protocol for device-to-device (D2D) communications. We use the options and payload fields to collect each device’s attribute information. The detailed information of the CoAP fields in the header is defined in an IETF RFC document  [19]. However, D2D interactions typically result in an IoTivity implementation acting in both client and server roles. An IoTivity operation is equivalent to that of HTTP and is sent by a client to request an action on a resource (identified by a URI) on a server. The server then sends a response with a response code; this response includes a resource representation. IoTivity makes use of the GET, PUT, POST, DELETE, and OBSERVE operations in a similar manner to HTTP with semantics. We modified the existing “OBSERVE” operation and created a new operation “INIT”. The details of each operation are described as follows:

GET retrieves a representation for the information that currently corresponds to the resource identified by the request URI. If the request includes an accept option, this indicates the preferred content format of a response. If the request includes an ETag Option, this method requests that ETag be validated and that the representation be transferred only if validation failed.

POST requests that the representation enclosed in the request be processed. The actual function performed by this method is determined by the origin server and dependent on the target device. It usually results in a new IoT device being created or the target device being updated.

PUT requests that the resource identified by the request URI be updated or created with the enclosed representation. The representation format is specified by the media type and content coding given in the option of the content format, if provided.

DELETE requests that the resource identified by the request URI be deleted. A 2.02 (deleted) response code should be used on success or in case where the resource did not exist before the request.

OBSERVE fetches and registers as an observer for the value of an IoT device. The handling of observation registration is application-specific. It should not be assumed that a device is observable or that a device can handle any specific number of observers. If the master server responds with a success (2.12) code, the registration is considered successful.

INIT brings a device and its attribute information to the master server. Normally, this operation is generated by a sensor or an IoT machine and sends this information to the IoT gateway. If the IoT gateway receives this message, the gateway updates its device and attribute table based on the received data.


In Fig. 1(a), the current system detects a new IoT device by using the OBSERVE operation, but it does not know its detailed attributes and functions. Therefore, the master server sends a “FAIL” message to the slave server. However, in Fig. 1(b), the IoT machine sends its attribute information through the “INIT” operation. After receiving this INIT message, the IoT gateway automatically registers the attributes to the device and attribute table.

 

Fig. 1(a). (a) Current IoT gateway.

 

Fig. 1(b). (b) Proposed IoT gateway.

Fig. 1. Device discovery and auto-registration.

 

 

3. Testbed implementation and measurement

In the following section, we present the development of an in-home-scale testbed for experimentation and evaluation of the proposed IoT gateway. We concentrate the measurement on the device setup time.

 

3.1. Testbed development

The proposed testbed includes three main types of devices, which are the master server in Fig. 2(a), the two slave servers (client devices) in Fig. 2(b), and a user’s mobile device (see Fig. 3). The three server devices in the proposed testbed are built on a standard Raspberry-Pi-embedded machine and use a general Linux-kernel-based operating system called Raspbian. Thus, all devices can be easily reconfigured to evaluate various network environments. Raspberry Pi is widely used to implement IoT-based smart environments  [20], [21], [22]. We installed Android 6.0 (code name Marshmallow) and the IoTivity platform  [18] for easy-to-manage wireless IoT devices. IoTivity is an open-source-software framework enabling reliable D2D communication to address the emerging needs of the IoT. On the user’s mobile device, we installed the Android Marshmallow operating system.


Fig. 2(a). (a) Master server.

 

 


Fig. 2(b). (b) Slave server (client).

 

 

Fig. 2. Laboratory-scale IoT testbed.

Fig. 3. Example of device control of an IoT lamp.



A network substrate considers the interconnections between the master and slave servers, as shown in Fig. 2. If the master server is connected with IoTivity, then IoTivity identifies which machine is matched. If IoTivity cannot find any entry, then the master server sends an OBSERVE message to the slave servers on the basis of the IoT communication policy. For the testbed measurements, we use the recently published IoTivity framework (version 1.1.1, July 2016). We also use both the WiFi and LTE interfaces to communicate with the user’s mobile device. Fig. 3 shows result for the attribute registration of an IoT lamp. In this figure, the user can control the attribute functions of the lamp (on/off).

 


3.2. System measurement

 In order to carry out a performance evaluation of the proposed gateway, we measured each device’s registration time in the wireless network environments (WiFi and LTE). We increased the number of slave devices after every measurement. We also increased the number of measurements up to 100. In Fig. 4, the results show that the proposed gateway registers each device within 2.4 s. If this system measurement is carried out under the wired-network condition, the registration time will be improved further.

 

 

Fig. 4. Average response time for attribute registration.

 



4. Conclusion

 In this paper, we implemented a gateway that is better known as a reliable and self-configurable IoT gateway and designed to be suitable for in-home-scale environments. For testbed development, we use the state-of-the-art IoTivity framework. We have a plan for the system measurements by checking the performance of the proposed gateway. In addition, our future work will extend the reliable IoT gateway to large-scale and energy-aware mobile environments.



Acknowledgments

 This work was supported by the G-ITRC Program under Grant IITP-2015R6812-15-0001, the NRF Research Fellow program under Grant NRF-2016R1A6A3A11934080, and the NRF Korea under Grant 2010-0020210.

 


Conflict of interests

 The authors declare that there is no conflict of interest in this paper.

Reference Link

Attached Documents

The “CHARIOT IoT Search Index” aims to provide a web location where publications, articles, and relevant documents can be centralized hosted in a well-structured and easily accessed way.

Tags

Contact Us
Enter Text
Contact our department
123movie