draft-ietf-lwig-energy-efficient-01.txt   draft-ietf-lwig-energy-efficient-02.txt 
Internet Engineering Task Force Z. Cao Internet Engineering Task Force Z. Cao
Internet-Draft Leibniz University of Hannover Internet-Draft Leibniz University of Hannover
Intended status: Informational C. Gomez Intended status: Informational C. Gomez
Expires: April 30, 2015 Universitat Politecnica de Expires: September 8, 2015 Universitat Politecnica de Catalunya/i2CAT
Catalunya/i2CAT
M. Kovatsch M. Kovatsch
ETH Zurich ETH Zurich
H. Tian H. Tian
China Academy of China Academy of Telecommunication Research
Telecommunication Research
X. He X. He
Hitachi China R&D Hitachi China R&D Corporation
Corporation March 7, 2015
October 27, 2014
Energy Efficient Implementation of IETF Constrained Protocol Suite Energy Efficient Implementation of IETF Constrained Protocol Suite
draft-ietf-lwig-energy-efficient-01 draft-ietf-lwig-energy-efficient-02
Abstract Abstract
This document summarizes the problems and current practices of energy This document summarizes the problems and current practices of energy
efficient protocol implementation on constrained devices, mostly efficient protocol implementation on constrained devices, mostly
about how to make the protocols within IETF scope behave energy about how to make the protocols within IETF scope behave energy
friendly. This document also summarizes the impact of link layer friendly. This document also summarizes the impact of link layer
protocol power saving behaviors to the upper layer protocols, so that protocol power saving behaviors to the upper layer protocols, so that
they can coordinately make the system energy efficient. they can coordinately make the system energy efficient.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 30, 2015. This Internet-Draft will expire on September 8, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions used in this document . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. MAC and Radio Duty Cycling . . . . . . . . . . . . . . . . . . 6 3. MAC and Radio Duty Cycling . . . . . . . . . . . . . . . . . 5
3.1. Radio Duty Cycling techniques . . . . . . . . . . . . . . 6 3.1. Radio Duty Cycling techniques . . . . . . . . . . . . . . 6
3.2. Latency and buffering . . . . . . . . . . . . . . . . . . 7 3.2. Latency and buffering . . . . . . . . . . . . . . . . . . 7
3.3. Power save services available in example low-power 3.3. Throughput . . . . . . . . . . . . . . . . . . . . . . . 7
radios . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4. Radio interface tuning . . . . . . . . . . . . . . . . . 7
3.3.1. Power Save Services Provided by IEEE 802.11v . . . . . 8 3.5. Power save services available in example low-power radios 7
3.3.2. Power Save Services Provided by Bluetooth Low 3.5.1. Power Save Services Provided by IEEE 802.11 . . . . . 8
Energy . . . . . . . . . . . . . . . . . . . . . . . . 9 3.5.2. Power Save Services Provided by Bluetooth Low Energy 9
3.3.3. Power Save Services in IEEE 802.15.4 . . . . . . . . . 10 3.5.3. Power Save Services in IEEE 802.15.4 . . . . . . . . 10
4. IP Adaptation and Transport Layer . . . . . . . . . . . . . . 12 4. IP Adaptation and Transport Layer . . . . . . . . . . . . . . 11
5. Routing Protocols . . . . . . . . . . . . . . . . . . . . . . 13 5. Routing Protocols . . . . . . . . . . . . . . . . . . . . . . 12
6. Application Layer . . . . . . . . . . . . . . . . . . . . . . 14 6. Application Layer . . . . . . . . . . . . . . . . . . . . . . 13
7. Cross Layer Optimization . . . . . . . . . . . . . . . . . . . 15 6.1. Energy efficient features in CoAP . . . . . . . . . . . . 13
8. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.2. Sleepy node support . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 6.3. CoAP timers . . . . . . . . . . . . . . . . . . . . . . . 14
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
12.1. Normative References . . . . . . . . . . . . . . . . . . . 20 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
12.2. Informative References . . . . . . . . . . . . . . . . . . 21 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
In many scenarios, the network systems comprises many battery-powered In many scenarios, the network systems comprise many battery-powered
or energy-harvesting devices. For example, in an environmental or energy-harvesting devices. For example, in an environmental
monitoring system or a temperature and humidity monitoring system in monitoring system or a temperature and humidity monitoring system in
the data center, there are no always-on and handy sustained power a data center, there are no always-on and handy sustained power
supplies for the large number of small devices. In such deployment supplies for the potentially large number of constrained devices. In
environments, it is necessary to optimize the energy consumption of such deployment environments, it is necessary to optimize the energy
the entire system, including computing, application layer behavior, consumption of the entire system, including computing, application
and lower layer communication. layer behavior, and lower layer communication.
Various research efforts have been spent on this "energy efficiency" Significant research efforts have been spent on this "energy
problem. Most of this research has focused on how to optimize the efficiency" problem. Most of this research has focused on how to
system's power consumption regarding a certain deployment scenario or optimize the system's power consumption regarding a certain
how could an existing network function such as routing or security be deployment scenario or how could an existing network function such as
more energy-efficient. Only few efforts were spent on energy- routing or security be more energy-efficient. Only few efforts were
efficient designs for IETF protocols and standardized network stacks spent on energy-efficient designs for IETF protocols and standardized
for such constrained devices [I-D.kovatsch-lwig-class1-coap]. network stacks for such constrained devices
[I-D.kovatsch-lwig-class1-coap].
The IETF has developed a suite of Internet protocols suitable for The IETF has developed a suite of Internet protocols suitable for
such small devices, including 6LoWPAN ( [RFC6282],[RFC6775],[RFC4944] such constrained devices, including 6LoWPAN (
), RPL[RFC6550], and CoAP[I-D.ietf-core-coap]. This document tries [RFC6282],[RFC6775],[RFC4944] ), RPL[RFC6550], and
to summarize the design considerations of making the IETF protocol CoAP[I-D.ietf-core-coap]. This document tries to summarize the
suite as energy-efficient as possible. While this document does not design considerations of making the IETF protocol suite as energy-
provide detailed and systematic solutions to the energy efficiency efficient as possible. While this document does not provide detailed
problem, it summarizes the design efforts and analyzes the design and systematic solutions to the energy efficiency problem, it
space of this problem. summarizes the design efforts and analyzes the design space of this
problem. In particular, it provides a comprehensive overview of the
techniques used by the lower layers to save energy and how these may
impact on the upper layers.
After reviewing the energy-efficient design of each layer, an overall After reviewing the energy-efficient design of each layer, an overall
conclusion is summarized. Though the lower layer communication conclusion is summarized. Though the lower layer communication
optimization is the key part of energy efficient design, the protocol optimization is the key part of energy efficient design, the protocol
design at the network and application layers is also important to design at the upper layers is also important to make the device
make the device energy-efficient. energy-efficient.
1.1. Conventions used in this document 1.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] document are to be interpreted as described in [RFC2119]
1.2. Terminology 1.2. Terminology
The terminologies used in this document can be referred to [RFC7228]. The terminologies used in this document can be referred to [RFC7228].
2. Overview 2. Overview
The IETF has developed multiple protocols to enable end-to-end IP The IETF has developed multiple protocols to enable end-to-end IP
communication between constrained nodes and fully capable nodes. communication between constrained nodes and fully capable nodes.
This work has witnessed the evolution of the traditional Internet This work has witnessed the evolution of the traditional Internet
protocol stack to a light-weight Internet protocol stack. As show in protocol stack to a light-weight Internet protocol stack. As shown
Figure 1 below, the IETF has developed CoAP as the application layer in Figure 1 below, the IETF has developed CoAP as the application
and 6LoWPAN as the adaption layer to run IPv6 over IEEE 802.15.4 and layer and 6LoWPAN as the adaption layer to run IPv6 over IEEE
Bluetooth Low-Energy, with the support of routing by RPL and 802.15.4 and Bluetooth Low-Energy, with the support of routing by RPL
efficient neighbor discovery by 6LoWPAN-ND. 6LoWPAN is currently and efficient neighbor discovery by 6LoWPAN-ND. 6LoWPAN is currently
being adapted by the 6lo working group to support IPv6 over various being adapted by the 6lo working group to support IPv6 over various
other technologies, such as ITU-T G.9959, DECT ULE and MS/TP-BACnet. other technologies, such as ITU-T G.9959, DECT ULE, MS/TP-BACnet and
NFC.
+-----+ +-----+ +-----+ +------+ +-----+ +-----+ +-----+ +------+
|http | | ftp | |SNMP | | COAP | |http | | ftp | |SNMP | | COAP |
+-----+ +-----+ +-----+ +------+ +-----+ +-----+ +-----+ +------+
\ / / / \ \ / / / \
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| tcp | | udp | | tcp | | udp | | tcp | | udp | | tcp | | udp |
+-----+ +-----+ ===> +-----+ +-----+ +-----+ +-----+ ===> +-----+ +-----+
\ / \ / \ / \ /
+-----+ +------+ +-------+ +------+ +-----+ +-----+ +------+ +-------+ +------+ +-----+
skipping to change at page 4, line 41 skipping to change at page 4, line 33
|MAC/PHY| |6lowpan|--|6lowpan-nd| |MAC/PHY| |6lowpan|--|6lowpan-nd|
+-------+ +-------+ +----------+ +-------+ +-------+ +----------+
| |
+-------+ +-------+
|MAC/PHY| |MAC/PHY|
+-------+ +-------+
Figure 1: Traditional and Light-weight Internet Protocol Stack Figure 1: Traditional and Light-weight Internet Protocol Stack
There are numerous published studies reporting comprehensive There are numerous published studies reporting comprehensive
measurements of wireless communication platforms[Powertrace]. Below measurements of wireless communication platforms [Powertrace]. As an
we list the energy consumption profile of the most common atom example, below we list the energy consumption profile of the most
operations on a prevalent sensor node platform. The measurement was common atom operations on a prevalent sensor node platform. The
based on the Tmote Sky with ContikiMAC as the radio duty cycling measurement was based on the Tmote Sky with ContikiMAC [ContikiMAC]
algorithm. From the measurement, we can see that optimized as the radio duty cycling algorithm. From this and many other
transmissions and reception consume almost the same amount of energy. measurement reports (e.g. [AN053]), we can see that the energy
For IEEE 802.15.4 and UWB radios, transmitting may actually be even consumption of optimized transmission and reception may be in the
cheaper than receiving. Only for broadcast and non-synchronized same order. For IEEE 802.15.4 and UWB radios, transmitting may
communication transmissions become costly in terms of energy because actually be even cheaper than receiving. Only for broadcast and non-
they need to flood the medium for a long time. synchronized communication transmissions become costly in terms of
energy because they need to flood the medium for a long time.
+---------------------------------------+---------------+ +---------------------------------------+---------------+
| Activity | Energy (uJ) | | Activity | Energy (uJ) |
+---------------------------------------+---------------+ +---------------------------------------+---------------+
| Broadcast reception | 178 | | Broadcast reception | 178 |
+---------------------------------------+---------------+ +---------------------------------------+---------------+
| Unicast reception | 222 | | Unicast reception | 222 |
+---------------------------------------+---------------+ +---------------------------------------+---------------+
| Broadcast transmission | 1790 | | Broadcast transmission | 1790 |
+---------------------------------------+---------------+ +---------------------------------------+---------------+
skipping to change at page 6, line 26 skipping to change at page 5, line 45
reduce power consumption, the radio must be switched completely off reduce power consumption, the radio must be switched completely off
-- duty-cycled -- as much as possible. By applying duty-cycling, the -- duty-cycled -- as much as possible. By applying duty-cycling, the
lifetime of a device operating on a common button battery may be in lifetime of a device operating on a common button battery may be in
the order of years, whereas otherwise the battery may be exhausted in the order of years, whereas otherwise the battery may be exhausted in
a few days or even hours. Duty-cycling is a technique generally a few days or even hours. Duty-cycling is a technique generally
exploited by devices that use the P1 strategy [RFC7228], which need exploited by devices that use the P1 strategy [RFC7228], which need
to be able to communicate on a relatively frequent basis. Note that to be able to communicate on a relatively frequent basis. Note that
a more aggressive approach to save energy relies on the P0, Normally- a more aggressive approach to save energy relies on the P0, Normally-
off strategy, whereby devices sleep for very long periods and off strategy, whereby devices sleep for very long periods and
communicate infrequently, even though they spend energy in network communicate infrequently, even though they spend energy in network
reattachment procedures. ContikiMAC is an example of a very typical reattachment procedures.
Radio Duty Cycling (RDC) protocol [ContikiMAC].
From the perspective of MAC&RDC, all upper layer protocols, such as From the perspective of MAC&RDC, all upper layer protocols, such as
routing, RESTful communication, adaptation, and management flows, are routing, RESTful communication, adaptation, and management flows, are
all applications. Since the duty cycling algorithm is the key to all applications. Since the duty cycling algorithm is the key to
energy-efficiency of the wireless medium, it synchronizes the TX/RX energy-efficiency of the wireless medium, it synchronizes the
request from the higher layer. transmission and/or reception request from the higher layer.
The MAC&RDC are not in the scope of the IETF, yet lower layer The MAC&RDC are not in the scope of the IETF, yet lower layer
designers and chipset manufactures take great care of the problem. designers and chipset manufactures take great care of the problem.
For the IETF protocol designers, however, it is good to know the For the IETF protocol designers, however, it is good to know the
behaviors of lower layers so that the designed protocols can work behaviors of lower layers so that the designed protocols can work
perfectly with them. perfectly with them.
Once again, the IETF protocols we are going to talk about in the Once again, the IETF protocols we are going to talk about in the
following sections are the customers of the lower layer. If they following sections are the customers of the lower layers. If the
want to get better service in a cooperative way, they should be different protocol layers want to get better service in a cooperative
considerate and understand each other. way, they should be considerate and understand each other.
3.1. Radio Duty Cycling techniques 3.1. Radio Duty Cycling techniques
This subsection describes the main three RDC techniques. Note that This subsection describes the main three RDC techniques. Note that
more than one of the presented techniques may be available or can more than one of the presented techniques may be available or can
even be combined in a specific radio technology: even be combined in a specific radio technology:
a) Channel sampling. In this solution, the radio interface of a a) Channel sampling. In this solution, the radio interface of a
device periodically monitors the channel for very short time device periodically monitors the channel for very short time
intervals (i.e. with a low duty cycle) with the aim of detecting intervals (i.e. with a low duty cycle) with the aim of detecting
skipping to change at page 7, line 31 skipping to change at page 6, line 50
communication is reached by means of some form of negotation between communication is reached by means of some form of negotation between
the involved devices. Such negotiation may be performed per the involved devices. Such negotiation may be performed per
transmission or per session/connection. Bluetooth Low Energy is an transmission or per session/connection. Bluetooth Low Energy is an
example of a radio technology based on this mechanism. example of a radio technology based on this mechanism.
c) Listen after send. This technique allows a node to remain in c) Listen after send. This technique allows a node to remain in
sleep mode by default, wake up and poll a sender (which must be ready sleep mode by default, wake up and poll a sender (which must be ready
to receive a poll message) for pending transmissions. After sending to receive a poll message) for pending transmissions. After sending
the poll message, the node remains in receive mode, ready for a the poll message, the node remains in receive mode, ready for a
potential incoming transmission. After a certain time interval, the potential incoming transmission. After a certain time interval, the
node may go back to sleep. The Receiver Initated Transmission (RIT) node may go back to sleep. For example, the Receiver Initated
mode of 802.15.4e, and the transmission of data between a coordinator Transmission (RIT) mode of 802.15.4e, and the transmission of data
and a device in IEEE 802.15.4-2003 use this technique. between a coordinator and a device in IEEE 802.15.4-2003 use this
technique.
3.2. Latency and buffering 3.2. Latency and buffering
The latency of a data unit transmission to a duty-cycled device is The latency of a data unit transmission to a duty-cycled device is
equal to or greater than the latency of transmitting to an always-on equal to or greater than the latency of transmitting to an always-on
device. Therefore, duty-cycling leads to a trade-off between energy device. Therefore, duty-cycling leads to a trade-off between energy
consumption and latency. Note that in addition to a latency consumption and latency. Note that in addition to a latency
increase, RDC may introduce latency variance, since the latency increase, RDC may introduce latency variance, since the latency
increase is a random variable (which is uniformly distributed if increase is a random variable (which is uniformly distributed if
duty-cycling follows a periodical behavior). duty-cycling follows a periodical behavior).
On the other hand, due to the latency increase of duty-cycling, a On the other hand, due to the latency increase of duty-cycling, a
sender waiting for a transmission opportunity may need to store sender waiting for a transmission opportunity may need to store
subsequent outgoing packets in a buffer, increasing memory subsequent outgoing packets in a buffer, increasing memory
requirements and potentially incurring queuing waiting time that requirements and potentially incurring queuing waiting time that
contributes to the packet overall delay and increases the probability contributes to the packet overall delay and increases the probability
of buffer overflow, leading to losses. of buffer overflow, leading to losses.
3.3. Throughput
Although throughput is not typically a key concern in constrained
node network applications, it is indeed important in some services in
this kind of networks, such as over-the-air software updates or when
off-line sensors accumulate measurements that have to be quickly
transferred when there is a connectivity opportunity.
Since RDC introduces inactive intervals in energy-constrained
devices, it reduces the throughput that can achieved when
communicating with such devices. There exists a trade-off between
the achievable throughput and energy consumption.
3.4. Radio interface tuning
The parameters controlling the radio duty cycle have to be carefully The parameters controlling the radio duty cycle have to be carefully
tuned to achieve the intended application and/or network tuned to achieve the intended application and/or network
requirements. On the other hand, upper layers should take into requirements. On the other hand, upper layers should take into
account the expected latency behavior due to RDC. account the expected latency and/or throughput behavior due to RDC.
The next subsection provides details on key parameters controlling
RDC mechanisms, and thus fundamental trade-offs, for various examples
of relevant low-power radio technologies.
3.3. Power save services available in example low-power radios 3.5. Power save services available in example low-power radios
This subsection presents power save services and techniques used in a This subsection presents power save services and techniques used in a
few relevant examples of wireless low-power radios: IEEE 802.11v, few relevant examples of wireless low-power radios: IEEE 802.11v,
Bluetooth Low Energy and IEEE 802.15.4. For a more detailed overview Bluetooth Low Energy and IEEE 802.15.4. For a more detailed overview
of each technology, the reader may refer to the literature or to the of each technology, the reader may refer to the literature or to the
corresponding specifications. corresponding specifications.
3.3.1. Power Save Services Provided by IEEE 802.11v 3.5.1. Power Save Services Provided by IEEE 802.11
IEEE 802.11v [IEEE80211v] defines mechanisms and services for power IEEE 802.11 defines the Power Save Mode (PSM) whereby a station may
save of stations/nodes that include flexible multicast service (FMS), indicate to an Access Point (AP) that it will enter a sleep mode
proxy ARP advertisement, extended sleep modes, traffic filtering. It state. While the station is sleeping, the AP buffers any frames that
would be useful if upper layer protocols knows such capabilities should be sent to the sleeping station. The station wakes up every
provided by the lower layer, so that they can coordinate with each Listen Interval (which can be a multiple of the Beacon Interval) in
other. order to receive beacons. The AP signals in the beacon whether there
is data pending for the station or not. If there are not frames to
be sent to the station, the latter may get back to sleep mode.
Otherwise, the station may send a message requesting the transmission
of the buffered data and stay awake in receive mode.
IEEE 802.11v [IEEE80211v] further defines mechanisms and services for
power save of stations/nodes that include flexible multicast service
(FMS), proxy ARP advertisement, extended sleep modes, traffic
filtering. It would be useful if upper layer protocols knows such
capabilities provided by the lower layer, so that they can coordinate
with each other.
These services include: These services include:
Proxy ARP: The Proxy ARP capability enables an Access Point (AP) to Proxy ARP: The Proxy ARP capability enables an Access Point (AP) to
indicate that the non-AP station (STA) will not receive ARP frames. indicate that the non-AP station (STA) will not receive ARP frames.
The Proxy ARP capability enables the non-AP STA to remain in power- The Proxy ARP capability enables the non-AP STA to remain in power-
save for longer periods of time. save for longer periods of time.
Basic Service Set (BSS) Max Idle Period management enables an AP to Basic Service Set (BSS) Max Idle Period management enables an AP to
indicate a time period during which the AP does not disassociate a indicate a time period during which the AP does not disassociate a
skipping to change at page 9, line 9 skipping to change at page 9, line 13
traffic filters specified by the non-AP STA. traffic filters specified by the non-AP STA.
Using the above services provided by the lower layer, the constrained Using the above services provided by the lower layer, the constrained
nodes can achieve either client initiated power save (via TFS) or nodes can achieve either client initiated power save (via TFS) or
network assisted power save (Proxy-ARP, BSS Max Idel Period and FMS). network assisted power save (Proxy-ARP, BSS Max Idel Period and FMS).
Upper layer protocols would better synchronize with the parameters Upper layer protocols would better synchronize with the parameters
such as FMS interval and BSS MAX Idle Period, so that the wireless such as FMS interval and BSS MAX Idle Period, so that the wireless
transmissions are not triggered periodically. transmissions are not triggered periodically.
3.3.2. Power Save Services Provided by Bluetooth Low Energy 3.5.2. Power Save Services Provided by Bluetooth Low Energy
Bluetooth Low Energy (Bluetooth LE) is a wireless low-power Bluetooth Low Energy (Bluetooth LE) is a wireless low-power
communications technology that is the hallmark component of the communications technology that is the hallmark component of the
Bluetooth 4.0 and Bluetooth 4.1 specifications [Bluetooth41]"/>. Bluetooth 4.0 and Bluetooth 4.1 specifications [Bluetooth41]"/>. BT-
BT-LE has been designed for the goal of ultra-low-power consumption. LE has been designed for the goal of ultra-low-power consumption.
Currently, it is possible to run IPv6 over BT-LE networks by using a Currently, it is possible to run IPv6 over Bluetooth LE networks by
6LoWPAN variant adapted to BT-LE [I-D.ietf-6lowpan-btle]. using a 6LoWPAN variant adapted to BT-LE [I-D.ietf-6lowpan-btle].
Bluetooth LE networks comprise a master and one or more slaves which Bluetooth LE networks comprise a master and one or more slaves which
are connected to the master. The Bluetooth LE master is assumed to are connected to the master. The Bluetooth LE master is assumed to
be a relatively powerful device, whereas a slave is typically a be a relatively powerful device, whereas a slave is typically a
constrained device (e.g. a class 1 device). constrained device (e.g. a class 1 device).
Medium access in Bluetooth LE is based on a TDMA scheme which is Medium access in Bluetooth LE is based on a TDMA scheme which is
coordinated by the master. This device determines the start of coordinated by the master. This device determines the start of
connection events, in which communication between the master and a connection events, in which communication between the master and a
slave takes place. At the beginning of a connection event, the slave takes place. At the beginning of a connection event, the
skipping to change at page 10, line 5 skipping to change at page 10, line 9
connSupervisionTimeout parameter is in the range between 100 ms and connSupervisionTimeout parameter is in the range between 100 ms and
32 s. 32 s.
Upper layer protocols should take into account the medium access and Upper layer protocols should take into account the medium access and
duty-cycling behavior of Bluetooth LE. In particular, connInterval, duty-cycling behavior of Bluetooth LE. In particular, connInterval,
connSlaveLatency and connSupervisionTimeout determine the time connSlaveLatency and connSupervisionTimeout determine the time
between two consecutive connection events for a given slave. The between two consecutive connection events for a given slave. The
upper layer packet generation pattern and rate should be consistent upper layer packet generation pattern and rate should be consistent
with the settings of the aforementioned parameters (and vice versa). with the settings of the aforementioned parameters (and vice versa).
3.3.3. Power Save Services in IEEE 802.15.4 3.5.3. Power Save Services in IEEE 802.15.4
IEEE 802.15.4 is a family of standard radio interfaces for low-rate, IEEE 802.15.4 is a family of standard radio interfaces for low-rate,
low-power wireless networking [fifteendotfour]. Since the low-power wireless networking [fifteendotfour]. Since the
publication of its first version in 2003, IEEE 802.15.4 has become publication of its first version in 2003, IEEE 802.15.4 has become
the de-facto choice for a wide range of constrained node network the de-facto choice for a wide range of constrained node network
application domains and has been a primary target technology of application domains and has been a primary target technology of
various IETF working groups such as 6LoWPAN various IETF working groups such as 6LoWPAN
[RFC6282],[RFC6775],[RFC4944] and 6TiSCH [RFC6282],[RFC6775],[RFC4944] and 6TiSCH
[I-D.ietf-6tisch-architecture]. IEEE 802.15.4 specifies PHY and MAC [I-D.ietf-6tisch-architecture]. IEEE 802.15.4 specifies PHY and MAC
layer functionality. layer functionality.
skipping to change at page 10, line 32 skipping to change at page 10, line 36
suitable for nodes that do not suffer severe constraints (e.g. a suitable for nodes that do not suffer severe constraints (e.g. a
mains-powered node). The PAN coordinator is a special type of mains-powered node). The PAN coordinator is a special type of
coordinator that acts as a principal controller in an IEEE 802.15.4 coordinator that acts as a principal controller in an IEEE 802.15.4
network. network.
IEEE 802.15.4 has mainly defined two types of networks depending on IEEE 802.15.4 has mainly defined two types of networks depending on
their configuration: beacon-enabled and nonbeacon-enabled networks. their configuration: beacon-enabled and nonbeacon-enabled networks.
In the first network type, coordinators periodically transmit In the first network type, coordinators periodically transmit
beacons. The time between beacons is divided in three main parts: beacons. The time between beacons is divided in three main parts:
the Contention Access Period (CAP), the Contention Free Period (CFP) the Contention Access Period (CAP), the Contention Free Period (CFP)
and an inactive period. In the first period, nodes use slotted and an inactive period. In the first period, nodes use slotted CSMA/
CSMA/CA for data communication. In the second one, a TDMA scheme CA for data communication. In the second one, a TDMA scheme controls
controls medium access. During the idle period, communication does medium access. During the idle period, communication does not take
not take place, thus the inactive period is a good opportunity for place, thus the inactive period is a good opportunity for nodes to
nodes to turn the radio off and save energy. The coordinator turn the radio off and save energy. The coordinator announces in
announces in each beacon the list of nodes for which data will be each beacon the list of nodes for which data will be sent in the
sent in the subsequent period. Therefore, devices may remain in subsequent period. Therefore, devices may remain in sleep mode by
sleep mode by default and wake up periodically to listen to the default and wake up periodically to listen to the beacons sent by
beacons sent by their coordinator. If a device wants to transmit their coordinator. If a device wants to transmit data, or learns
data, or learns from a beacon that it is an intended destination, from a beacon that it is an intended destination, then it will
then it will exchange messages with the coordinator and will thus exchange messages with the coordinator and will thus consume energy.
consume energy. An underlying assumption is that when a message is An underlying assumption is that when a message is sent to a
sent to a coordinator, the radio of the latter will be ready to coordinator, the radio of the latter will be ready to receive the
receive the message. message.
The beacon interval and the duration of the beacon interval active The beacon interval and the duration of the beacon interval active
portion (i.e. the CAP and the CFP), and thus the duty cycle, can be portion (i.e. the CAP and the CFP), and thus the duty cycle, can be
configured. The parameters that control these times are called configured. The parameters that control these times are called
macBeaconOrder and macSuperframeOrder, respectively. As an example, macBeaconOrder and macSuperframeOrder, respectively. As an example,
when IEEE 802.15.4 operates in the 2.4 GHz PHY, both times can be when IEEE 802.15.4 operates in the 2.4 GHz PHY, both times can be
(independently) set to values in the range between 15.36 ms and 251.6 (independently) set to values in the range between 15.36 ms and 251.6
s. s.
In the beaconless mode, nodes use unslotted CSMA/CA for data In the beaconless mode, nodes use unslotted CSMA/CA for data
skipping to change at page 14, line 7 skipping to change at page 13, line 29
RFC 6551 [RFC6551] defines routing metrics and constraints to be used RFC 6551 [RFC6551] defines routing metrics and constraints to be used
by RPL in route computation. Among others, RFC 6551 specifies a Node by RPL in route computation. Among others, RFC 6551 specifies a Node
Energy object that allows to provide information related to node Energy object that allows to provide information related to node
energy, such as the energy source type or the estimated percentage of energy, such as the energy source type or the estimated percentage of
remaining energy. Appropriate use of energy-based routing metrics remaining energy. Appropriate use of energy-based routing metrics
may help to balance energy consumption of network nodes, minimize may help to balance energy consumption of network nodes, minimize
network partitioning and increase network lifetime. network partitioning and increase network lifetime.
6. Application Layer 6. Application Layer
6.1. Energy efficient features in CoAP
CoAP [RFC7252] was designed as a RESTful application protocol, CoAP [RFC7252] was designed as a RESTful application protocol,
connecting the services of smart devices to the World Wide Web. CoAP connecting the services of smart devices to the World Wide Web. CoAP
is not a chatty protocol, it provides basic communication services is not a chatty protocol, it provides basic communication services
such as service discovery and GET/POST/PUT/DELETE methods with a such as service discovery and GET/POST/PUT/DELETE methods with a
binary header. binary header.
The energy-efficient design is implicitly included in the CoAP The energy-efficient design is implicitly included in the CoAP
protocol design. CoAP uses a fixed-length binary header of only four protocol design. CoAP uses a fixed-length binary header of only four
bytes that may be followed by binary options. To reduce regular and bytes that may be followed by binary options. To reduce regular and
frequent queries of the resources, CoAP provides an observe mode, in frequent queries of the resources, CoAP provides an observe mode, in
skipping to change at page 14, line 31 skipping to change at page 14, line 7
energy-constrained server to remain in sleep mode during the period energy-constrained server to remain in sleep mode during the period
between observe notification transmissions. between observe notification transmissions.
Furthermore, [RFC7252] defines CoAP proxies which can cache resource Furthermore, [RFC7252] defines CoAP proxies which can cache resource
representations previously provided by sleepy CoAP servers. The representations previously provided by sleepy CoAP servers. The
proxies themselves may respond to client requests if the proxies themselves may respond to client requests if the
corresponding server is sleeping and the resource representation is corresponding server is sleeping and the resource representation is
recent enough. Otherwise, a proxy may attempt to obtain the resource recent enough. Otherwise, a proxy may attempt to obtain the resource
from the sleepy server. from the sleepy server.
6.2. Sleepy node support
Beyond these features of CoAP, there have been a number of proposals Beyond these features of CoAP, there have been a number of proposals
to further support sleepy nodes at the application layer by to further support sleepy nodes at the application layer by
leveraging CoAP mechanisms. A good summary of such proposals can be leveraging CoAP mechanisms. A good summary of such proposals can be
found in [I-D.rahman-core-sleepy-nodes-do-we-need]. The different found in [I-D.rahman-core-sleepy-nodes-do-we-need]. The different
approaches include exploiting the use of proxies, leveraging the approaches include exploiting the use of proxies, leveraging the
Resource Directory [I-D.ietf-core-resource-directory] or signaling Resource Directory [I-D.ietf-core-resource-directory] or signaling
when a node is awake to the interested nodes. As of the writing, when a node is awake to the interested nodes. A more recent work
none of these proposals has been adopted by the CoRE working group. defines publish- subscribe and message queuing extensions to CoAP and
the Resource Directory in order to support devices that spend most of
their time in a sleeping state [I-D.koster-core-coap-pubsub]. As of
the writing, none of these proposals has been adopted by the CoRE
working group.
In addition to the work within the scope of CoAP to support sleepy
nodes, other specifications define application layer functionality
for the same purpose. The Lightweight Machine-to-Machine (LWM2M)
specification from the Open Mobile Alliance (OMA) defines a Queue
Mode whereby an LWM2M Server queues requests to an LWM2M Client until
the latter (which may often stay in sleep mode) is online. LWM2M
functionality operates on top of CoAP.
On the other hand, oneM2M defines a CoAP binding with an application
layer mechanism for sleepy nodes.
6.3. CoAP timers
CoAP offers mechanisms for reliable communication between two CoAP CoAP offers mechanisms for reliable communication between two CoAP
endpoints. A CoAP message may be signaled as a confirmable (CON) endpoints. A CoAP message may be signaled as a confirmable (CON)
message, and an acknowledgment (ACK) is issued by the receiver if the message, and an acknowledgment (ACK) is issued by the receiver if the
CON message is correctly received. The sender starts a CON message is correctly received. The sender starts a
Retransmission TimeOut (RTO) for every CON message sent. The initial Retransmission TimeOut (RTO) for every CON message sent. The initial
RTO value is chosen randomly between 2 and 3 s. If an RTO expires, RTO value is chosen randomly between 2 and 3 s. If an RTO expires,
the new RTO value is doubled (unless a limit on the number of the new RTO value is doubled (unless a limit on the number of
retransmissions has been reached). Since duty-cycling at the link retransmissions has been reached). Since duty-cycling at the link
layer may lead to long latency (i.e. even greater than the initial layer may lead to long latency (i.e. even greater than the initial
RTO value), CoAP RTO parameters should be tuned accordingly in order RTO value), CoAP RTO parameters should be tuned accordingly in order
to avoid spurious RTOs which would unnecessarily waste node energy to avoid spurious RTOs which would unnecessarily waste node energy
and other resources. and other resources.
7. Cross Layer Optimization 7. Summary
The cross layer optimization is a technique used in many
scenarios.There are some technologies for power efficient
optimization via PHY to Routing cross layer design
[Cross-layer-Optimization]. In this research, cross-layer
optimization frameworks have been developed to minimize the total
power consumption or to maximize the utility-power trade-off using
cooperative diversity.
Also a cross-layer design in multihop wireless networks is proposed
for congestion control, routing and scheduling - in transport,
network and link layers into a coherent framework
[Cross-layer-design]. This method and thinking could be applied to
the implementation of energy effective cross layer design.
Todo: more discussion of Cross layer issues.
8. Summary
We find a summary section necessary although most IETF documents do We find a summary section necessary although most IETF documents do
not contain it. The points we would like to summarize are as not contain it. The points we would like to summarize are as
follows. follows.
a. All Internet protocols, which are in the scope of the IETF, are a. All Internet protocols, which are in the scope of the IETF, are
customers of the lower layers (PHY, MAC, and Duty-cycling). In customers of the lower layers (PHY, MAC, and Duty-cycling). In
order to get a better service, the designers of higher layers order to get a better service, the designers of higher layers
should know them better. should know them better.
b. The IETF has developed multiple protocols for constrained b. The IETF has developed multiple protocols for constrained
networked devices. A lot of implicit energy efficient design networked devices. A lot of implicit energy efficient design
principles have been used in these protocols. principles have been used in these protocols. The latter should
be fine-tuned to exploit the collaboration with the lower layer
protocols. Layers should offer interfaces that can be exploited
by other layers in order to optimize global protocol stack
performance.
c. The power trace analysis of different protocol operations showed c. The power trace analysis of different protocol operations showed
that for radio-duty-cycled networks broadcasts should be avoided. that for radio-duty-cycled networks broadcasts should be avoided.
Saving unnecessary states maintenance is also an effective method Saving unnecessary states maintenance is also an effective method
to be energy-friendly. to be energy-friendly.
9. Acknowledgments 8. Acknowledgments
Carles Gomez has been supported by Ministerio de Economia y Carles Gomez has been supported by Ministerio de Economia y
Competitividad and FEDER through project TEC2012-32531. Competitividad and FEDER through project TEC2012-32531.
Authors would like to thank the review and feedback from a number of Authors would like to thank the review and feedback from a number of
experts in this area: Carsten Bormann, Ari Keranen. experts in this area: Carsten Bormann, Ari Keranen, Hannes
Tschofenig.
The text of this document was improved based on IESG Document Editing The text of this document was improved based on IESG Document Editing
session during IETF87. Thank Ted Lemon, Joel Jaeggli, and efforts to session during IETF87. Thank Ted Lemon, Joel Jaeggli, and efforts to
initiate this facilities. initiate this facilities.
10. IANA Considerations 9. IANA Considerations
This document has no IANA requests. This document has no IANA requests.
11. Security Considerations 10. Security Considerations
This document discusses the energy efficient protocol design, and This document discusses the energy efficient protocol design, and
does not incur any changes or challenges on security issues besides does not incur any changes or challenges on security issues besides
what the protocol specifications have analyzed. what the protocol specifications have analyzed.
12. References 11. References
12.1. Normative References 11.1. Normative References
[AN053] Selvig, B., "Measuring power consumption with CC2430 and
Z-Stack", .
[Announcementlayer] [Announcementlayer]
Dunkels, A., "The Announcement Layer: Beacon Coordination Dunkels, A., "The Announcement Layer: Beacon Coordination
for the Sensornet Stack. In Proceedings of EWSN 2011". for the Sensornet Stack. In Proceedings of EWSN 2011", .
[Bluetooth41] [Bluetooth41]
"Bluetooth Core Specification Version 4.1", 2013. "Bluetooth Core Specification Version 4.1", 2013.
[ContikiMAC] [ContikiMAC]
Dunkels, A., "The ContikiMAC Radio Duty Cycling Protocol, Dunkels, A., "The ContikiMAC Radio Duty Cycling Protocol,
SICS Technical Report T2011:13", December 2011. SICS Technical Report T2011:13", December 2011.
[Cross-layer-Optimization]
Le and Hossain, "Cross-Layer Optimization Frameworks for
Multihop Wireless Networks Using Cooperative Diversity",
July 2008.
[Cross-layer-design]
Chen, Low, and Doyle, "Cross-layer design in multihop
wireless networks", 2011.
[I-D.ietf-6lowpan-btle] [I-D.ietf-6lowpan-btle]
Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets
over BLUETOOTH Low Energy", draft-ietf-6lowpan-btle-12 over BLUETOOTH Low Energy", draft-ietf-6lowpan-btle-12
(work in progress), February 2013. (work in progress), February 2013.
[I-D.ietf-6man-impatient-nud] [I-D.ietf-6man-impatient-nud]
Nordmark, E. and I. Gashinsky, "Neighbor Unreachability Nordmark, E. and I. Gashinsky, "Neighbor Unreachability
Detection is too impatient", Detection is too impatient", draft-ietf-6man-impatient-
draft-ietf-6man-impatient-nud-07 (work in progress), nud-07 (work in progress), October 2013.
October 2013.
[I-D.ietf-6tisch-architecture] [I-D.ietf-6tisch-architecture]
Thubert, P., Watteyne, T., and R. Assimiti, "An Thubert, P., Watteyne, T., Struik, R., and M. Richardson,
Architecture for IPv6 over the TSCH mode of IEEE "An Architecture for IPv6 over the TSCH mode of IEEE
802.15.4e", draft-ietf-6tisch-architecture-03 (work in 802.15.4e", draft-ietf-6tisch-architecture-05 (work in
progress), July 2014. progress), January 2015.
[I-D.ietf-6tisch-minimal] [I-D.ietf-6tisch-minimal]
Vilajosana, X. and K. Pister, "Minimal 6TiSCH Vilajosana, X. and K. Pister, "Minimal 6TiSCH
Configuration", draft-ietf-6tisch-minimal-02 (work in Configuration", draft-ietf-6tisch-minimal-05 (work in
progress), July 2014. progress), January 2015.
[I-D.ietf-core-coap] [I-D.ietf-core-coap]
Shelby, Z., Hartke, K., and C. Bormann, "Constrained Shelby, Z., Hartke, K., and C. Bormann, "Constrained
Application Protocol (CoAP)", draft-ietf-core-coap-18 Application Protocol (CoAP)", draft-ietf-core-coap-18
(work in progress), June 2013. (work in progress), June 2013.
[I-D.ietf-core-resource-directory] [I-D.ietf-core-resource-directory]
Shelby, Z., Bormann, C., and S. Krco, "CoRE Resource Shelby, Z. and C. Bormann, "CoRE Resource Directory",
Directory", draft-ietf-core-resource-directory-01 (work in draft-ietf-core-resource-directory-02 (work in progress),
progress), December 2013. November 2014.
[I-D.ietf-lwig-terminology] [I-D.ietf-lwig-terminology]
Bormann, C., Ersue, M., and A. Keranen, "Terminology for Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained Node Networks", draft-ietf-lwig-terminology-07 Constrained Node Networks", draft-ietf-lwig-terminology-07
(work in progress), February 2014. (work in progress), February 2014.
[I-D.koster-core-coap-pubsub]
Koster, M., Keranen, A., and J. Jimenez, "Publish-
Subscribe in the Constrained Application Protocol (CoAP)",
draft-koster-core-coap-pubsub-00 (work in progress),
October 2014.
[I-D.kovatsch-lwig-class1-coap] [I-D.kovatsch-lwig-class1-coap]
Kovatsch, M., "Implementing CoAP for Class 1 Devices", Kovatsch, M., "Implementing CoAP for Class 1 Devices",
draft-kovatsch-lwig-class1-coap-00 (work in progress), draft-kovatsch-lwig-class1-coap-00 (work in progress),
October 2012. October 2012.
[I-D.rahman-core-sleepy-nodes-do-we-need] [I-D.rahman-core-sleepy-nodes-do-we-need]
Rahman, A., "Sleepy Devices: Do we need to Support them in Rahman, A., "Sleepy Devices: Do we need to Support them in
CORE?", draft-rahman-core-sleepy-nodes-do-we-need-01 (work CORE?", draft-rahman-core-sleepy-nodes-do-we-need-01 (work
in progress), February 2014. in progress), February 2014.
[IEEE80211v] [IEEE80211v]
IEEE, "Part 11: Wireless LAN Medium Access Control (MAC) IEEE, , "Part 11: Wireless LAN Medium Access Control (MAC)
and Physical Layer (PHY) specifications, Amendment 8: IEEE and Physical Layer (PHY) specifications, Amendment 8: IEEE
802.11 Wireless Network Management.", February 2012. 802.11 Wireless Network Management.", February 2012.
[Powertrace] [Powertrace]
Dunkels, Eriksson, Finne, and Tsiftes, "Powertrace: Dunkels, , Eriksson, , Finne, , and Tsiftes, "Powertrace:
Network-level Power Profiling for Low-power Wireless Network-level Power Profiling for Low-power Wireless
Networks", March 2011. Networks", March 2011.
[fifteendotfour] [fifteendotfour]
"802.15.4-2011", 2011. "802.15.4-2011", 2011.
12.2. Informative References 11.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007. Networks", RFC 4944, September 2007.
[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
skipping to change at page 23, line 11 skipping to change at page 18, line 38
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, June 2014. Application Protocol (CoAP)", RFC 7252, June 2014.
Authors' Addresses Authors' Addresses
Zhen Cao (Ed.) Zhen Cao (Ed.)
Leibniz University of Hannover Leibniz University of Hannover
P.R.China P.R.China
Phone:
Email: zhencao.ietf@gmail.com Email: zhencao.ietf@gmail.com
Carles Gomez Carles Gomez
Universitat Politecnica de Catalunya/i2CAT Universitat Politecnica de Catalunya/i2CAT
C/Esteve Terradas, 7 C/Esteve Terradas, 7
Castelldefels, 08860 Castelldefels 08860
Spain Spain
Phone:
Fax:
Email: carlesgo@entel.upc.edu Email: carlesgo@entel.upc.edu
URI:
Matthias Kovatsch Matthias Kovatsch
ETH Zurich ETH Zurich
Universitaetstrasse 6 Universitaetstrasse 6
Zurich, CH-8092 Zurich, CH-8092
Switzerland Switzerland
Phone:
Fax:
Email: kovatsch@inf.ethz.ch Email: kovatsch@inf.ethz.ch
URI:
Hui Tian Hui Tian
China Academy of Telecommunication Research China Academy of Telecommunication Research
Huayuanbeilu No.52 Huayuanbeilu No.52
Beijing, Haidian District 100191 Beijing, Haidian District 100191
China China
Phone:
Fax:
Email: tianhui@mail.ritt.com.cn Email: tianhui@mail.ritt.com.cn
URI:
Xuan He Xuan He
Hitachi China R&D Corporation Hitachi China R&D Corporation
301, Tower C North, Raycom, 2 Kexuyuan Nanlu, Haidian District 301, Tower C North, Raycom, 2 Kexuyuan Nanlu, Haidian District
Beijing, 100190 Beijing 100190
P.R.China P.R.China
Phone:
Fax:
Email: xhe@hitachi.cn Email: xhe@hitachi.cn
URI:
 End of changes. 61 change blocks. 
181 lines changed or deleted 209 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/