Internet DRAFT - draft-cao-lwig-syn-layer
draft-cao-lwig-syn-layer
Internet Engineering Task Force Z. Cao
Internet-Draft China Mobile
Intended status: Informational Y. Ma
Expires: August 29, 2013 Hitachi (China) R&D
H. Tian
China Academy of
Telecommunications Research
February 25, 2013
Synchronization Layer: an Implementation Method for Energy Efficient
Sensor Stack
draft-cao-lwig-syn-layer-01
Abstract
This document analyzes the problem of energy efficient protocol
implementation, and proposes an energy efficient design of mulitiple
protocols by utilizing a common shim layer to synchronize the packet
receipt and transimission on a single node.
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 August 29, 2013.
Copyright Notice
Copyright (c) 2013 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
Cao, et al. Expires August 29, 2013 [Page 1]
Internet-Draft Lwig Synchronization Layer February 2013
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . . . . 3
2. Energy Consumption Analysis . . . . . . . . . . . . . . . . . . 3
3. Synchronization Layer Design . . . . . . . . . . . . . . . . . 4
3.1. Synchronization Layer . . . . . . . . . . . . . . . . . . . 5
3.2. After Synchronization . . . . . . . . . . . . . . . . . . . 6
3.3. Cross layer Optimization . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Cao, et al. Expires August 29, 2013 [Page 2]
Internet-Draft Lwig Synchronization Layer February 2013
1. Introduction
This document analyzes the problem of energy efficient protocol
implementation. And inspired by the idea originally proposed in
[ref.dunkel], proposes an energy efficient design of mulitiple
protocols by utilizing a common shim layer to synchronize the packet
receipt and transimission on a single node.
The idea is straightforward. Because different protocol cyclings
result into the frequent and out-of-order wake-up of the radio, the
energy consumption would be high. By utilizing a shim layer between
different applicaiton-layer protocols and the MAC/Link layer, the
sending and receiving behavior of different protocols can be
synchronized, which will wake up the radio at a low frequency and
conserve energy consumption on the sensor.
1.1. Conventions used in this document
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]
2. Energy Consumption Analysis
Chipset normally provides different modes of operation that consume
different levels of energy. There are normally three modes of
operation on a wireless chipset.
Transmit mode: The mode at a node when transmitting a packet.
Receive mode: The mode at a node when receiving a packet.
Idle mode: The mode generally used at a node with the node is
neither transmitting nor receiving a packet. This mode consumes
power because the node has to listen to the wireless medium
continuously in order to detect a packet that it should receive,
so that the node can then switch into receive mode.
Sleep mode: Sleep mode has very low power consumption. The network
interface at a node in sleep mode can neither transmit nor receive
packets; the network interface must be woken up to idle mode first
by an explicit instruction from the node.
Sleep mode is the most energy efficient mode. Some transceivers
provide different levels of sleeping mode. For example, CC3530
provides three of them, PM1, PM2 and PM3, according to its
specificaiton. PM3 is the most efficient mode of them.
Cao, et al. Expires August 29, 2013 [Page 3]
Internet-Draft Lwig Synchronization Layer February 2013
Some research studies the energy efficiency of different operations
on the sensor. According to the investigation in [ref.icccn], the
energy consumption of different operations are as follows.
Operation
/\
Hum |*
Temp |**
AES |******
|
RX(10B)|***********************
|
TX(10B)|*******************************************************
+-------------------------------------------------------->
Energy Consumption (uJ)
From this analysis we can clearly see that the most energy efficient
way is to keep the sensor transciever sleep as much as possible.
3. Synchronization Layer Design
The key optimization direction is to reduce the frequency of radio
wakeup. But if there are multiple protocols running on a sensor
node, the situation is unavoidable. For example, as depicted in
Figure 1 , there are three protocols running on a sensor node. The
three protocols have their different rate and phase of sending and/or
receiving packets. The figure shows an extreme case that their
sending phases are totally un-overlapped. In this case, the sensor
radio stack should be active roughly 70% of time. This makes the
sensor stack not very energy efficient at all.
The idea of handling this problem is to synchronize the transmission
of different protocols. We will introduce the synchronization layer
and its impact in the following subsections.
Cao, et al. Expires August 29, 2013 [Page 4]
Internet-Draft Lwig Synchronization Layer February 2013
/|
Prtl1 | __ __
| | | | |
|______| |___________| |__________
Prtl2 | __ __
| | | | |
|_________| |____________| |_________
Prtl3 | __ __
| | | | |
|_____________| |____________| |_______
Radio | _________ _________
| | | | |
|______| |_____| |__________
|-------------------------------------------------->
Time
Figure 1: Radio Wakeup for multiple protocols
3.1. Synchronization Layer
The synchronization layer is set between the application protocols
and MAC/Phy layer. The Syn-layer provides API to the upper layer
protocols and has its own frequency of sending and receiving packets.
After synchronization, the protocol's transceiving behavior has been
adapted. The synchronization layer keeps its own clock and will wake
up the radio once the clock times up.
+-------+ +-------+ +-------+
| Prtl1 | | Prtl2 | | Prtl3 |
+-------+ +-------+ +-------+
\ | /
\_________ | __________/
\ | /
+-------------------------+
| Syn Layer |
+-------------------------+
||
+-------------------------+
| MAC/Phy Layer |
+-------------------------+
Figure 2: The Synchronization Layer
As envisioned, after synchronization, the protocol's realtime
requirement will affected. The protocol's behavior has been delayed
until the Syn-layer's clock has been trigger. To support the
realtime communication requirement, we can utilize a design of the
API between the application-layer protocol and the Syn-layer. If the
Cao, et al. Expires August 29, 2013 [Page 5]
Internet-Draft Lwig Synchronization Layer February 2013
protocol in consideration has specific realtime requirement, it can
specify this requirement in the API call function.
// protocol can specify the realtime requirment in the API call
Pull (Key, Flag)
3.2. After Synchronization
After the synchronization layer is implemented and enabled, the
packet transceiver is synchronized. As shown in Figure 3, the radio
wakeup rate is reduced to about 30%.
Prtl1 | __ __
| | | | |
|______| |___________| |__________
Prtl2 | __ __
| | | | |
|_________| |____________| |_________
Prtl3 | __ __
| | | | |
|_____________| |____________| |________
Radio | _________ _________
| | | | |
|______| |_____| |__________
| ____ ____
Syn | | | | |
|________________| |____________| |_____
|
+-------------------------------------------------->
Time
Figure 3: Radio Wakeup for multiple protocols
3.3. Cross layer Optimization
After synchronization layer reduces radio wakeup rate, how to reduce
the amount of transferred packet also should be considered.
In current resource constrained device implementation, every layer
has its own registration process. For example, IEEE 802.15.4
initialization at MAC layer, and resource registration for CoAP or
other protocols at APP layer. Thus these processes are hard to
integrated, and lack of efficiency.
The MAC layer and APP layer registration also can be implemented into
same packet, the synchronization layer can further decrease the whole
Cao, et al. Expires August 29, 2013 [Page 6]
Internet-Draft Lwig Synchronization Layer February 2013
registration process transferred packet, as well the communication
cost.
4. IANA Considerations
This document has no IANA requests.
5. Security Considerations
This document does not design any protocols or mechanisms, and hence
does not introduce any security issues or challenges that need to be
resolved further.
6. References
6.1. Normative References
[ref.dunkel]
Dunkels, A., "The Announcement Layer: Beacon Coordination
for the Sensornet Stack. In Proceedings of EWSN 2011".
[ref.icccn]
Margi, C., "Impact of Operating Systems on Wireless Sensor
Networks (Security) Applications and Testbeds, ICCCN
2010".
6.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Zhen Cao
China Mobile
Xuanwumenxi Ave. No. 32
Beijing, 100871
China
Phone: +86-10-52686688
Email: zehn.cao@gmail.com, caozhen@chinamobile.com
Cao, et al. Expires August 29, 2013 [Page 7]
Internet-Draft Lwig Synchronization Layer February 2013
Yuanchen Ma
Hitachi (China) R&D
301, Tower C North, Raycom, 2 Kexuyuan Nanlu, Haidian District
Beijing, 100190
P.R.China
Phone:
Fax:
Email: ycma@hitachi.cn
URI:
Hui Tian
China Academy of Telecommunications Research
Huayuanbeilu No.52
Beijing, 100191
P.R.China
Phone:
Fax:
Email: tianhui@mail.ritt.com.cn
URI:
Cao, et al. Expires August 29, 2013 [Page 8]
