Internet DRAFT - draft-ychoi-eman-energy-efficient-management
draft-ychoi-eman-energy-efficient-management
Network Working Group Y. Choi
Internet-Draft S. Jeong
Intended status: Informational ETRI
Expires: October 30, 2014 April 28, 2014
Energy-efficient Management Framework
draft-ychoi-eman-energy-efficient-management-01.txt
Abstract
Wireless network devices which have limited resources (e.g., power
supply, memory, computing capabilities, and so on) should consider
energy-efficient management. However, the existing network
architectures for the network devices have some problems on energy
management about device failures and errors. To improve the energy
management problem, this document proposes energy-efficient
management framework for the network devices.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 30, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Choi & Jeong Expires October 30, 2014 [Page 1]
Internet-Draft EEMF April 2014
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
3. Overview of Energy-efficient Management Framework . . . . . . 3
4. Requirements and Considerations of Energy Management
Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.1. Scenarios for Energy Consumption Analysis . . . . . . . . 4
4.2. Requirements and Considerations . . . . . . . . . . . . . 6
4.2.1. Separation of Control Plane and Data Plane . . . . . 6
4.2.2. Centralized Control Support . . . . . . . . . . . . . 6
4.2.3. Versatile and Programmable . . . . . . . . . . . . . 7
4.2.4. Remote Monitoring and Managements . . . . . . . . . . 7
4.2.5. Channel Support to Control Network Devices . . . . . 7
5. Reference Architecture of Energy-efficient Management
Framework for Constrained Network Devices . . . . . . . . . . 7
5.1. Reference Architecture . . . . . . . . . . . . . . . . . 7
5.2. Functionalities . . . . . . . . . . . . . . . . . . . . . 8
5.2.1. Control Plane . . . . . . . . . . . . . . . . . . . . 8
5.2.2. Data Plane . . . . . . . . . . . . . . . . . . . . . 9
6. Procedures of Energy-efficient Management Framework . . . . . 9
6.1. Initialization Processing . . . . . . . . . . . . . . . . 9
6.2. On-demand Processing . . . . . . . . . . . . . . . . . . 10
6.3. Event-driven Processing . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
Energy efficiency is one of the important issues for wireless
constrained network devices, which have limited resources as low-cost
and low-power devices, such as power supply, memory, computing
capability, and so on. Therefore, this document specifies motivation
and functional architecture of energy efficient management for such
light weight low-cost network devices so that the network devices can
reduce energy consumption. Then, it describe specification for
network device control as follows:
o Motivation for energy efficient management of network devices;
Choi & Jeong Expires October 30, 2014 [Page 2]
Internet-Draft EEMF April 2014
o Functional architecture and requirements of energy efficient
management;
o Operational procedures and messages for device delegation control
protocol.
2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Overview of Energy-efficient Management Framework
Wireless network devices which have limited resources (e.g., power
supply, memory, computing capabilities, and so on) should consider
energy-efficient management as one of the important functions when
they are designed for applications. However, the existing network
architectures for resource-constrained network devices have some
problems on energy management because they typically have
architectures to support both control plane and data plane. For
example, one of the network devices which gets in troubles on power
supply, gives negative effects on energy waste of the other network
devices to recover the errors. As the worst case, network overhead,
such as message broadcasting, could be required.
To improve such a problem, roles of network devices should be
minimized for data obtaining and forwarding, and control plane, such
as topology control and routing control, should be taken by the other
entity, which do not have resource-constraint. Therefore, this
document describes requirements and considerations for energy-
efficient management framework based on general application scenarios
of the existing network architectures. Then reference architectures
for separation of control plane and data plane is stated, and also
procedures for network initializing, on-demand, and event-driven
process are specified.
4. Requirements and Considerations of Energy Management Framework
This section provides a scenario to show an example of energy
consumption in wireless low-power network devices which have light-
weight and low-cost properties, then requirements and considerations
to reduce energy consumption are analysed based on the scenario.
Choi & Jeong Expires October 30, 2014 [Page 3]
Internet-Draft EEMF April 2014
4.1. Scenarios for Energy Consumption Analysis
There are two applications, such as target-tracking services and
temperature reporting services, provided. In the network, there are
two kinds of devices. One is to obtain temperature data, the other
is for target-tracking.
User Gateway Network Devices
| | |
| Request temperature info. | |
|----------------------------->| Send msgs to discover devices|
| |----------------------------->|
| | Report info. of devices |
| |<-----------------------------|
| | |
| | Deliver tasks |
| |----------------------------->|
| | |
| | Obtain temperature data
| | |
| | Relay the temperature
| | data to gateway
| | |
| | Report the obtiaining data |
| |<-----------------------------|
| | |
| Data Processing for User |
| | |
| Reply tempertature info. | |
|<-----------------------------| |
| | |
| Request modification for | |
| temperature service | |
|----------------------------->| |
| Modify the temperature service |
| | Send msg to modified tasks |
| |----------------------------->|
| | |
Figure 1: Scenario of an application for temperature reporting
services
In Figure 1, a user wants to know current temperature of the network
field, so the user requests temperature information to a gateway.
The gateway should recognize which one of the deployed devices can be
available in the field. The gateway starts message broadcasting to
discover devices available, and the available devices reply to the
gateway by hop-by-hop networking. If the number of the available
Choi & Jeong Expires October 30, 2014 [Page 4]
Internet-Draft EEMF April 2014
devices is satisfied for providing temperature information, the
gateway delivers a task to gather temperature data to the available
devices. The task is broadcasted to all of the devices. Whenever
the devices obtain temperature data, the data is delivered to the
gateway through hop-by-hop networking. When all of the temperature
data obtained are collected to gateway, the data is processed to
temperature information and provided to the user.
User Gateway Network Devices Target
| Req. | | |
| target-tracking | Send messages to | |
|----------------->| discover devices | |
| |------------------->| |
| | Report device info.| |
| |<-------------------| |
| | | |
| | Deliver tasks | Sensing the target |
| |------------------->| and obtaining data |
| | |<------------------>|
| | | |
| | Report obtained | |
| | data | Sensing the target |
| |<-------------------| and obtaining data |
| Data Processing for User |<------------------>|
| | | |
| Rep. target info.| Report obtained | |
|<-----------------| data | |
| |<-------------------| |
| | | |
| Data Processing for User | |
| | | |
| Rep. target info.| | |
|<-----------------| | |
| | | |
Figure 2: Scenario of an application for target-tracking services
Figure 2 shows another scenario, which is for target-tracking. A
user wants to know current location information of a target in the
network field, so the user requests target location information to a
gateway. The gateway should recognize which one of the deployed
devices can be available in the field. The gateway starts message
broadcasting to discover devices available, and the available devices
reply to the gateway by hop-by-hop networking. If the number of the
available devices is satisfied for providing temperature information,
the gateway delivers a task to gather temperature data to the
available devices. The task is broadcasted to all of the devices.
Whenever the target moves to another location, the devices obtain
Choi & Jeong Expires October 30, 2014 [Page 5]
Internet-Draft EEMF April 2014
location data of the target. Then the data is delivered to the
gateway through hop-by-hop networking, and real-time location
information of the target is provided to the user.
In the two scenarios, the two different application services, such as
temperature reporting and target-tracking, are provided in the same
network. Some of the devices are involved into the temperature
reporting, the others are involved into the target-tracking, but all
devices commonly participated in message broadcasting, task
broadcasting, and data delivering without regard to the types of
application services.
4.2. Requirements and Considerations
In the two scenarios, lots of possible situations of energy
consumption exist while network devices are operated to provide
application services. If such a network architecture is redesigned
to improve inefficient energy consumption, several requirements and
considerations need to be reflected as follows:
4.2.1. Separation of Control Plane and Data Plane
In the scenarios, there are two kinds of devices; one is for the
temperature reporting application, and the other is for target-
tracking application. There is no devices for both of them.
However, they should participate in message broadcasting, task
broadcasting, and obtained data delivering to gateway. Especially,
broadcasting messages and tasks is one of the most critical ways to
inefficient energy consumption. To minimize the inefficient energy
consumption, network devices should mainly participate in data
delivering or data forwarding in data plane. Instead, control plane
can be operated by the other centralized methodology, such as the
gateway. Then such a broadcasting method can be reduced.
4.2.2. Centralized Control Support
To discover neighbours and routing paths, typically all network
devices should involve in processes in control plane. However, if an
entity (i.e., a centralized controller) is aware of all the
information (e.g., location, remaining energy levels, etc.) of the
network devices in a local network, only the entity can computes and
create routing paths and links among the network devices. In other
words, the network devices can reduce energy consumption. The
centralized entity can be a third party or gateway.
Choi & Jeong Expires October 30, 2014 [Page 6]
Internet-Draft EEMF April 2014
4.2.3. Versatile and Programmable
If a network architecture is conveniently designed to apply for
various application services, it gives a positive influence to
efficient energy consumption. For example, requirements for service
types, such as on-demand reporting, regularly reporting, and event-
driven reporting, can be temporally changed in temperature reporting
services. Therefore, energy managements need to be differently
programed and changed for the service types.
4.2.4. Remote Monitoring and Managements
To centrally control network devices, remotely monitoring and
management are required.
4.2.5. Channel Support to Control Network Devices
To remotely manage network devices, protocols for control plane is
supported between network devices and centralized entity.
5. Reference Architecture of Energy-efficient Management Framework for
Constrained Network Devices
5.1. Reference Architecture
As above the requirements and considerations in Section 4.2, energy-
efficient management framework is divided into three parts, such as
applications, control plane, and data plane. Figure 3 shows a
reference architecture of energy-efficient management framework for
network devices. Applications are just described as examples so they
are out of scope in this document.
Choi & Jeong Expires October 30, 2014 [Page 7]
Internet-Draft EEMF April 2014
+- Applications ----------------------------------------------+
| +-----------+ +----------+ +--------------+ +----------+ |
| |Temperature| | Humidity | | Air Pollution| | Target- | |
| | Reporting | | Reporting| | Monitoring | | tracking | |
| +-----------+ +----------+ +--------------+ +----------+ |
+-------------------------------------------------------------+
=========================== Open API ==========================
+- Control Plane (Control Center) ----------------------------+
| +---------------------------------------------------------+ |
| | Application Management | |
| +---------------------------------------------------------+ |
| +------------+ +------------------------+ +-------------+ |
| | Topology | | Node Energy Monitoring | | Network | |
| | Management | | and Management | | Operating | |
| +------------+ +------------------------+ +-------------+ |
+-------------------------------------------------------------+
================= Open Channel and Protocol ===================
+- Data Plane (Network Devices) ------------------------------+
| +-------------------+ +-----------------------------------+ |
| | Ctl Plane Support | | Data Plane Support | |
| +-------------------+ +-----------------------------------+ |
| +-----++-----++-----+ +----++-----++----------++----------+ |
| |Mobi-||Loca-||Power| |Sen-||Data ||In-network|| Data | |
| |lity ||tion || | |sing||Cache||Processing||Forwarding| |
| +-----++-----++-----+ +----++-----++----------++----------+ |
+-------------------------------------------------------------+
Figure 3: Reference architecture of energy-efficient management
framework for network devices
According to the Section 4.2.1, the proposed framework have a
separated structure of control plane and data plane. Control plane
includes application management, device topology management,
networking management, and device energy management. The control
plane can be accomplished by gateway or the third party. On the
other hand, data plane includes mobility control support, location
control support, power control support, and data plane support. The
data plane is only accomplished by network devices.
5.2. Functionalities
5.2.1. Control Plane
o Application Management
o Topology Management
o Node Energy Monitoring and Management
Choi & Jeong Expires October 30, 2014 [Page 8]
Internet-Draft EEMF April 2014
5.2.2. Data Plane
5.2.2.1. Contol Plane Support
o Mobility
o Location Management
o Power Management
5.2.2.2. Data Plane
o Sensing
o Data Cache
o In-network Processing
o Data Fowarding
6. Procedures of Energy-efficient Management Framework
This section describes how to operate the energy-efficient management
framework for devices. The energy-efficient management framework
have three operations, such as network initialization, on-demand
processing, and event-driven processing.
6.1. Initialization Processing
Figure 4 shows how network initialization procedure is needed when
application services are provided based on the energy-efficient
management framework.
(6) (4)
+-------+ (3) +-------+ +------------+
|Network|-------------->|Control| (1) |Applications|
|devices|<--------------|center |<--------------| (Users) |
+-------+ (2), (5) +-------+ +------------+
Figure 4: Procedure for initialization processing
(1) A user requests required application service results to a
control server.
(2) The control server creates a task and delivers the task message
to all network devices. The task message includes what data
should be obtained.
Choi & Jeong Expires October 30, 2014 [Page 9]
Internet-Draft EEMF April 2014
(3) When the network devices receive the task message, they decide
whether to participate in the task or not. If so, they send
their information (e.g., ID, location, remaining energy level,
etc.) to the control server.
(4) After all necessary information of network devices is received
to satisfy the task, the control server creates networking
information, such as routing paths, links, and so on, by
analyzing all the information of involving network devices.
(5) The networking information is delivered to the involving network
devices.
(6) The network devices does self-configuration for data gathering
and forwarding.
6.2. On-demand Processing
On-demand processing means a process to modify on-going application
services according to demands on users as shown in Figure 5.
(4) (2)
+-------+ +-------+ +------------+
|Network| (3) |Control| (1) |Applications|
|devices|<--------------|center |<--------------| (Users) |
+-------+ +-------+ +------------+
Figure 5: Procedure for on-demand processing
(1) A user requested for modification of the requested application
service to a control server.
(2) The control server evaluates which devices is related with the
previously collected information of network devices, and the
control server modifies the on-going task policy.
(3) A task modification message is delivered to only related network
devices.
(4) When the network devices receive the task modification message,
they does self-configuration again for data gathering and
forwarding based on the modified task.
(5) The network devices does self-configuration for data gathering
and forwarding.
Choi & Jeong Expires October 30, 2014 [Page 10]
Internet-Draft EEMF April 2014
6.3. Event-driven Processing
If a network device, which is involved in the on-going task, runs out
of battery, the network device cannot participate in the task any
more. Likewise, event-driven processing means a process to modify
on-going application services according to network situation changes,
such as node failures and errors, as shown in Figure 6.
(1),(5) (3)
+-------+ (2) +-------+
|Network|------------------------>|Control|
|devices|<------------------------|center |
+-------+ (4) +-------+
Figure 6: Procedure for event-driven processing
(1) When energy level of a network device goes to lower limit or
moves to another place, the network device is aware of network
situation changes.
(2) The network device sends a modification request message to the
control server.
(3) When the control server receives the message, it evaluates which
other devices can be instead of the failed device with the
previously collected information of network devices, and the
control server modifies the on-going task policy.
(4) A task modification message is delivered to only related network
devices.
(5) When the network devices receive the task modification message,
they does self-configuration again for data gathering and
forwarding based on the modified task.
7. Security Considerations
[TBD]
8. IANA Considerations
[TBD]
9. References
Choi & Jeong Expires October 30, 2014 [Page 11]
Internet-Draft EEMF April 2014
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative References
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
February 2013.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, February 2013.
Authors' Addresses
Younghwan Choi
ETRI
218 Gajeongno, Yuseong
Daejeon 305-700
Korea
Phone: +82 42 860 1429
Email: yhc@etri.re.kr
Sangjin Jeong
ETRI
218 Gajeongno, Yuseong
Daejeon 305-700
Korea
Phone: +82 42 860 1877
Email: sjjeong@etri.re.kr
Choi & Jeong Expires October 30, 2014 [Page 12]
