wang-6lowpan-scheduling-00.txt

Internet DRAFT - draft-wang-6lowpan-scheduling

draft-wang-6lowpan-scheduling

Last Version:	draft-wang-6lowpan-scheduling-00.txt	Tracker Entry
Date:	`21-Apr-2012`
Disposition:	expired

6LoWPAN Working Group H. Wang
Internet Draft P. Wang
Interned status: Standards Track Chongqing University of
Expires: October 21, 2012 Posts and Telecommunications
C. Zhou
Cisco Systems
April 20, 2012

Transmission Scheduling of IPv6 Packets over IEEE 802.15.4 Networks-- -
Extension for Industrial Application Space
draft-wang-6lowpan-scheduling-00.txt

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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

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."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html

This Internet-Draft will expire on mouth date year.

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

Wang, et al. Expires October 21, 2012 [Page 1]

Internet-Draft draft-wang-6lowpan-scheduling-00 April 2012

Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.

Abstract

These years, wireless technologies, including the application of
6LoWPAN protocol, are more and more been applied in industrial
environment to improve productivity and safety of the plants. In
spite of the fact that [RFC4944] has introduced the methods of
transmitting IPv6 packets over IEEE 802.15.4 networks, industrial
automation field, either process automation or factory automation,
has its special characteristics and requirements. If 6LoWPAN is been
used in industrial environment, some change SHOULD be made in the
adaption layer. This document defines a Scheduling Header, to make
the adaption layer meet the requirements of industrial scheduling for
transmission of IPv6 packets over IEEE 802.15.4 networks.
Additionally, this document also provides an application example of
Scheduling Header.

Table of Contents

1. Introduction ................................................ 2
1.1. Requirements Notation .................................. 4
1.2. Terms Uesd ............................................. 4
2. Scheduling Header ........................................... 5
2.1. Scheduling dispatch and IPv6 header stack .............. 5
2.2. Scheduling Header ...................................... 6
3. An example using Scheduling Header .......................... 7
3.1. Route Discovery......................................... 7
3.2. Route Maintenance ..................................... 12
4. IANA Considerations ........................................ 12
5. Security Considerations .................................... 12
6. Conclusions ................................................ 13
7. References ................................................. 13
7.1. Normative References .................................. 13
7.2. Informative References ................................ 13
7.3. External Informative References ....................... 13
8. Acknowledgments ............................................ 14

1. Introduction

Wireless technology has been demonstrated as an effective option for
industrial applications. For convenient and fast deployment in a
global world, it has attracted huge attention to introduce IPv6
technology to wireless industrial networks. But in the industrial
environment, especially the environments (eg. a coal mine) with high

Wang, et al. Expires October 21, 2012 [Page 2]

Internet-Draft draft-wang-6lowpan-scheduling-00 April 2012

risk and low bandwidth, the resources are too limited. Which MUST be
scheduled properly to ensure every significant thing be done in its
specific time and channel and to ensure the safety and reliability.
It is worth mentioning that the MAC layers of some industrial
standards, [ISA100.11a]/[Wireless Hart]/[WIA-PA] standards, schedule
the slot time and channel resources of network with TDMA and ACA
Adaptive Channel Allocation mechanism. Through the investigation
of the data features and the application class of wireless
industrial applications, a conclusion can be draw that the important
requirements for wireless industrial networks are:

* Determinism

* Reliability

* Real time

* Security

* Synchronization

However, the adaption layer of 6LoWPAN defined in RFC 4944 is mainly
based on contention access and best effort delivery. It does not
make special optimization for industrial applications. To meet above
requirements, it is recommended to improve the design of the
adaption layer for transmission of IPv6 packets.

ISA100.11a adopts 6LoWPAN as its network layer, but the function of
6LoWPAN in is limited. For example, the operations of scheduling and
routing in the wireless subnet are performed by upper data link
layer of ISA100.11a rather than network layer. Moreover, ISA100.11a
is an integrated solution for industrial control net, including
system manager, gateway, provisioning and a series of new protocols
for every layer except physical layer. 6LoWPAN is just a part of
ISA100.11a system. For simple or lightweight industrial applications
which want to use IPv6 technology, the ISA100.11a has too much
overhead to deploy. Thus, it is attractive to add direct support
mechanism for industrial applications in 6LoWPAN. Industrial users
will benefit from more choices for different kinds of applications.

Consequently, it's hoped that 6LoWPAN supports the schedule
mechanism, and to be more suitable for industrial application. In
this case, the MAC layer is based on slot time, while the upper
layer, called the adaption layer, is based on non-slot. Therefore,
it is necessary to improve the frame format of the adaptation layer,
to make it support scheduling operations.

Wang, et al. Expires October 21, 2012 [Page 3]

Internet-Draft draft-wang-6lowpan-scheduling-00 April 2012

As a result, this document improves the frame format of the
adaptation and defines a scheduling header. In addition, this
document also introduces an application example of the Scheduling
Header.

1.1. Requirements Notation

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]

1.2. Terms Uesd

MAC: Medium Access Control

Industrial Wireless Standard: At present, there are three main
industrial wireless standards, ISA100.11a, WirelessHART, and WIA-PA.

ISA: ''International Society of Automation''. ISA is an ANSI
accredited standards-making society. ISA100 is an ISA committee
whose charter includes defining a family of standards for industrial
automation. [ISA100.11a] is a working group within ISA100 that is
working on a standard for monitoring and non-critical process
control applications.

HART: ''Highway Addressable Remote Transducer'', a group of
specifications for industrial process and control devices
administered by the HART Foundation. The specifications include the
additions for Wireless HART.

WIA-PA: ''Wireless Networks for Industrial Automation-Process
Automation'', a Chinese industrial wireless specification, is passed
by 96% of IEC(International Electrotechnical Commission) members,
and formally released as IEC/PAS 62601 standard document.

CSMA/CA: Carrier Sense Multiple Access / Collision Avoidance

TDMA: Time Division Multiple Address

GTS: Guaranteed Time Slot

Safety: It means the system's safety of industrial environment,
including the safety of devices and human safety.

Security: It means the specific security mechanism or security
algorithm.

Wang, et al. Expires October 21, 2012 [Page 4]

Internet-Draft draft-wang-6lowpan-scheduling-00 April 2012

Scheduling time: It means the time a node must to wait between the
time it wanted to send data or received data and the moment it send
data to a special node. When the MAC layer schedules the slot time
and channel resources of network with TDMA mechanism, every node get
send slots and receive slots. In this case if node A wants to send
data to node B, it have to send data at its send slot, which is also
the receive slot of node B. The time from the time A wanted to send
data to the slot above mentioned is the scheduling time from node A
to node B. It is noteworthy that the scheduling time from A to B is
usually different from the scheduling time from B to A.

Determinism: It is usually meant that access to the control
network by a node may be delayed by at most some time t, where t is
known. In industrial wireless network, it also means that data is
sent and received within the stipulated time.

Neighbor domain: It means the neighbors a node could reach to.
Node could use neighbor discovery to find its neighbors and store
the neighbors' addresses in its neighbor table.

2. Scheduling Header

In this section, we define the scheduling dispatch value and the
field of Scheduling Header, used for supporting scheduling
operations.

2.1. Scheduling dispatch and IPv6 header stack

The definition of LoWPAN headers, other than mesh addressing and
fragmentation, consists of the dispatch value, and the definition of
the header fields that follow. Note that [RFC 4944] has defined some
values for some headers. In order to avoid any conflicts with the
existing standard documents, including [RFC 4944] and [RFC 6282], we
make full use of the reserved symbols of dispatch. Here, we set the
value of Scheduling dispatch is 01 000011. The Scheduling dispatch
and the Scheduling Header are shown here:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1|0 0 0 0 1 1| Scheduling Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1 Scheduling dispatch and Scheduling Header

The dispatch value may be treated as unstructured namespace. Only a
few symbols have been used to represent current LoWPAN functionality

Wang, et al. Expires October 21, 2012 [Page 5]

Internet-Draft draft-wang-6lowpan-scheduling-00 April 2012

according to [RFC 4944]. We can use the non-defined values to encode
additional functionality.

According to RFC 4944, all LoWPAN encapsulated datagrams transported
over IEEE 802.15.4 are prefixed by an encapsulated header stack.
Whereas in an IPv6 header stack, the Scheduling dispatch and the
Scheduling Header follow the Mesh Header and the next are other
headers, or options, finally payload. An Ipv6 header stack
containing Scheduling Header is shown as figure 2.

Figure 2 An Ipv6 header stack containing Scheduling Header

Here, the other headers contain IPv6 header or other compressed IPv6
headers, and other types of header.

2.2. Scheduling Header

The Scheduling Header is shown here:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence ID | Scheduling ID | Scheduling Time Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3 Scheduling Header

Field definitions are as follows:

Sequence ID: This 8-bit field is a local counter maintained
separately by each node and SHALL be incremented by the originator
whenever it sends a datagram with a Scheduling Header. This field is
used for follow-up maintenance, for example it could be used to tell
new datagrams from old datagrams.

Scheduling ID: This 8-bit field is used for identifying paths or
other scheduling parameter, which SHALL meet the industrial
requirements mentioned in the above section of Introduction,
especially the requirements of determinism. During the transmission
of the datagram, the Scheduling ID could show the information of
propagation path.

Wang, et al. Expires October 21, 2012 [Page 6]

Internet-Draft draft-wang-6lowpan-scheduling-00 April 2012

Scheduling Time Limit: This 16-bit field is used mainly to identify
the maximum scheduling time a packet allowed to be sent. It is the
key field to ensure the requirement of determinism, and in units of
milliseconds. This field can contain values up to 65535.
Additionally, it is an accumulated metric, an aggregation of
scheduling time value of every node along the path. Especially, when
a datagram with the requirement of determinism is sent for the first
time, this field is necessary for it to choose a satisfying path.

It is worth noting that the above definition of the Scheduling
Header is originally envisaged. With the subsequent increase in
scheduling applications, it MAY be further modified. Meanwhile, the
definition of the fields SHOULD be applied flexibly, according to
actual needs.

3. An example using Scheduling Header

Scheduling Header defined aims to support scheduling operation, and
to meet the industrial application requirements of determinism.
According to the initial consideration, the Scheduling Time Limit is
the key field to ensure determinism, which is used mainly to
identify the maximum scheduling time a packet allowed along the
transmission path. It is also to say that a datagram must be
transmitted from source node to destination node with the given
Scheduling Time Limit. So, we can see it as an accumulated routing
metric. Along this train of thought, route discovery MAY be an
obvious application of Scheduling Header defined above.

The aim of this section is simply to provide an example of
Scheduling Header application, using it in route discovery. Needless
to say that the MAC layer SHOULD based on TDMA and ACA mechanism,
which schedules the slot time and channel resources of network.

3.1. Route Discovery

The way of route discovery in this section is an on-demand algorithm,
that is, it determines a route to some destination only when
somebody wants to send packet to this destination within a
Scheduling Time Limit. The Scheduling Time Limit is set by users.
The route discovery process is similar to AODV (Ad hoc On-demand
Distance Vector) routing algorithm. However, the broadcast slots in
the deterministic scheduling mechanism are usually for organizing
network and time synchronization, using broadcast slots in route
discovery MAY effect the functional aspects of whole network.
Meanwhile, the route discovery for datagram is on-demand and
optional. So, it usually uses the non-broadcast slot for route

Wang, et al. Expires October 21, 2012 [Page 7]

Internet-Draft draft-wang-6lowpan-scheduling-00 April 2012

discovery. One of the solutions is that node use a group of unicast
messages to realize the broadcast effectiveness.

In order to describe route discovery process in detail, we make
following assumptions:

o The MAC layer is based on TDMA, if node A could send packet to
node B in a slot, then node B could send packet to node A in a
slot too.

o Before the route discovery process, the scheduling process is
over, and every node knows its send slot and scheduling time to a
special node.

o The mesh network can be described by a graph of the nodes
(routers + end devices). Two nodes are connected (i.e., have an
arc between them in the graph) if they are in each other's
neighbor domain.

To describe the algorithm, consider the mesh network of figure 4, in
which a process on node A wants to send a packet to node H. This
algorithm maintains some tables at each node, including:

o Scheduling Path History Table, which is maintained by source node,
stores information about that destination, including the Path ID,
the destination address, as well as the Scheduling Time Limit.

o Neighbor Table, which is got from the neighbor discovery process
before scheduling process, stores the address information of the
node's neighbors.

o Route Table, which is maintained by routers, stores information
about that destination, including the Path ID, the destination
address, as well as the next hop address.

o Local History Table, which is maintained by routers, stores the
tuple (Source address, Request ID, Destination address) for
determining duplicate packet.

o Reverse Route Table, which is maintained by every node, stores
the reverse route information. This information used to construct
the reverse route so the reply packet can get back to the source
later. Meanwhile, a timer is also started for the newly-made
reverse route entry. If it expires, the entry is deleted.

According to the user's requirements, A wants to send data with
Scheduling Header to H. Suppose that A looks in its Scheduling Path

Wang, et al. Expires October 21, 2012 [Page 8]

Internet-Draft draft-wang-6lowpan-scheduling-00 April 2012

History table and does not find an entry for H to ensure the
requirements of Scheduling Time Limit. It now has to discover a path
to H, which could meet the constraints. This property of discovering
paths only when they are needed is what makes this algorithm ''on
demand.''

+-------------------------------------------------------------+
| +---------------+ +---------------+ +---------------+ |
| | (A) | | (A) | | (A) | |
| | / \ | | / \ | | / \ | |
| | / \ | | / \ | | / \ | |
| | [B]---[C] | | (B)---(C) | | (B)---(C) | |
| | / / \ | | / / \ | | / / \ | |
| | / / \ | | / / \ | | / / \ | |
| | (E) (F)--(G)| | [E] [F]--[G]| | (E) (F)--(G)| |
| | \ / | | \ / | | \ / | |
| | \ / | | \ / | | \ / | |
| | (H) | | (H) | | [H] | |
| +---------------+ +---------------+ +---------------+ |
| (a) (b) (c) |
+-------------------------------------------------------------+

Figure 4 The process of path discovery

In figure 4, every node has a neighbor domain. Node B and node C are
in A's neighbor domain, then B and C could receive A's message. In
the graph of (a), B and C have received A's messages. In the graph
of (b), E, F and G have received A's messages forwarded by B and C.
And in the graph of (c), node H has received A's messages forward by
E and F. The nodes in [square brackets] are new recipients.

To locate H, node A May construct a Scheduling Route Request (SRR)
message and send it to all of his neighbors to find a satisfying
path to H. This packet reaches B and C, as illustrated in (a) of
figure 4. In fact, the reason B and C are connected to A in the
graph is that they can receive communication from A. G, for example,
is not shown with an arc to A because it cannot receive A's radio
signal. Thus, G is not a neighbor to A and also not connected to A.

The main format of SRR message is shown in figure 5. It contains the
source and destination address, which identify who is looking for
whom. It also contains a Request ID, which is a local counter
maintained separately by each node and incremented each time a group
of SRR packets is sent to its neighbors. Together, the originator
address and the Request ID uniquely identify the special group of
SRR messages to allow nodes to discard any duplicates they may
receive.

Wang, et al. Expires October 21, 2012 [Page 9]

Internet-Draft draft-wang-6lowpan-scheduling-00 April 2012

Figure 5 Main format of a Scheduling Route Request packet

In addition to the Request ID counter, there is also a second
sequence counter, Source sequence, which is incremented whenever a
SRR message is sent (or forward someone else's SRR message). It
functions a little bit like a clock. The fourth field of figure 5 is
A's sequence counter.

The Hop limit of SRR is used for terminating the diffusion of SRR
messages in the network. It SHALL be decremented by each forwarding
node before sending this packet towards its next hop. The packet is
not forwarded any further if Hops Left is decremented to zero.

The Scheduling time limit of SRR message is an accumulated limit of
path. Every time node sends a packet to its neighbor, the Scheduling
time limit will minus the scheduling time value of the send node to
its special neighbor, whatever the originator or the forwarding
nodes. When it is decremented to zero, the node will discard the
packet, and stop to send it to his neighbor. The original value of
Scheduling time limit in SRR is the same to the Scheduling Time
Limit in Scheduling Header. The use of these fields will become
clear shortly.

Before sending it to his neighbors, Node A will firstly compute the
scheduling time to every neighbor node according to scheduling
mechanism, and then compute the Scheduling Time Limit to every
neighbor (the old Scheduling time limit minus scheduling time to the
neighbor). If the new Scheduling time limit to a neighbor becomes to
0 or negative, A will not send the SRR to the neighbor.

When a SRR arrives at a node (B and C in this case), it is processed
in the following steps.

o Step 1: The tuple of (Source address, Request ID, Destination
address) is looked up in a local history table to see if this
request has already been seen and processed. If is a duplicate,
it is discarded and processing stops. If it is not a duplicate,
the tuple is entered into the history table so future duplicates
can be rejected, and processing continues.

o Step2: The receiver looks up its Neighbor Table, compute the
scheduling time to every neighbor node according to scheduling
mechanism, and then compute the Scheduling Time Limit to every

Wang, et al. Expires October 21, 2012 [Page 10]

Internet-Draft draft-wang-6lowpan-scheduling-00 April 2012

neighbor. If the new Scheduling time limit to a neighbor becomes
to 0 or negative, A will not send the SRR to the neighbor.
Instead, it will decrease the Hop left, increase the Source
sequence and renew the Scheduling time limit, and then resend the
SRR message to its neighbor. It is worth noting that if the Hop
left field becomes to 0, the sending process is terminated too.

o Step3: The receiver also extracts the data from the packet and
stories it as a new entry in its Reverse Route Table. This
information will be used to construct the reverse route so that
the acknowledgement packet can get back to the source later. And
a timer is also started for the newly-made reverse route entry.
If it expires, the entry is deleted.

Neither B nor C knows where H is, so each of them creates a reverse
route entry pointing back to A, and resend the SRR with a new Hop
Left, a new Source sequence, and a new Scheduling Time Limit. The
SRR from B reaches E and C. E makes an entry for it in its reverse
route table and resend it. In contrast, C rejects it as a duplicate.
Similarly, C's SRR is rejected by B. The process goes on, until H
receives the broadcast, and the special datagram reaches a
destination that knows where H is, namely H, as illustrated in (c)
graph of Figure 4. Note that although we have shown the sending
process in three discrete steps here, the SRR forwarded from
different nodes are not coordinated in any way.

In response to the incoming SRR message, H SHOULD builds an
acknowledgement packet, here called Scheduling Route Acknowledgement
(SRA) message. The main format of SRA message is shown in figure 6.

Figure 6 Main format of a Scheduling Route Acknowledgement packet

The Source address, Destination address, and Request ID are copied
from the incoming request message, but the Hop count field is
initialized to 0. The Path ID is a counter maintained by the
destination node. Each time, the destination node receives a SRR
message sent or forwarded by different node, it will increase the
Path ID, which means there is a new path. This message is unicast to
the node that the SRR message came from, in this case, E and F. It
then follows the reverse path to B or C, and finally to A. At each
node, Hop count is incremented so the node can see how far from the
destination (H) it is.

Wang, et al. Expires October 21, 2012 [Page 11]

Internet-Draft draft-wang-6lowpan-scheduling-00 April 2012

At each intermediate node on the way back, the message is inspected.
It is entered into the Route Table as a path to H.

In this way, all the nodes on the reverse route learn the path with
Path ID to H. And the original node (A) set the Path ID of SRA into
the Scheduling ID of the Scheduling header. When data with
Scheduling Header is sending, the intermediate nodes will know which
path to forward the data.

This document only shows the main fields of the SRR and SRA messages,
in fact, the SRR and SRA could be extended from the RPL messages or
other exiting protocols. The specific extension methods are out of
this document.

3.2. Route Maintenance

Because nodes can move or be switched off, the topology can change
spontaneously. When the topology has changed, the algorithm needs to
be able to deal with the failure.

4. IANA Considerations

This document defines a new Scheduling Header for 6LoWPAN to support
scheduling mechanism and to meet the industrial requirement of
determinism.

[RFC 4944] has allocated some values of dispatch for some headers.
This assignment preempts the assignment of 01 111111 for ESC [RFC
4944]; this preemption is possible because extension bytes that
would enable the use of ESC have not been allocated yet. But [RFC
6282] takes 01 000000 as a replacement value for ESC, and allocates
the value between 01 100000 to 01 111111 for LoWPAN_IPHC. Meanwhile,
it also creates a new IANA registry for LoWPAN_NHC, and has used the
value from 1110000 to 1110111.

As a result, the document allocates 01 000011 of the dispatch for
Scheduling dispatch.

5. Security Considerations

In industrial environment, the wireless networks share the same
place and time. In this case, if the security mechanism is not very
brilliant, it will seriously affect the system's information
security. The security mechanism is beyond the scope of this draft.

Wang, et al. Expires October 21, 2012 [Page 12]

Internet-Draft draft-wang-6lowpan-scheduling-00 April 2012

6. Conclusions

This document describes the method of transmission scheduling
information over 6LoWPAN Adaption layer for industrial application.
6LoWPAN nodes use the Scheduling Header to determine the packets
scheduling information, including the transmission path and
constraints, to meet the requirement of determinism.

7. References

7.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2234] Crocker, D. and Overell, P. (Editors), "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, Internet Mail
Consortium and Demon Internet Ltd., November 1997.

[RFC4919] N. Kushalnagar, and G. Montenegro, ''IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs): Overview,
Assumptions, Problem Statement, and Goals'', RFC4919,
August 2007.

[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and Culler, D.,
"Transmission of IPv6 Packets over IEEE 802.15.4 Networks",
RFC 4944, September 2007.

[RFC6282] J. Hui, Ed, "Compression Format for IPv6 Datagrams over
IEEE 802.15.4-Based Networks", RFC 6282, September 2011.

7.2. Informative References

[I-D.ietf-roll-indus-routing-reqs] Dust Networks, ''Industrial
Routing Requirements in Low Power and Lossy Networks",
draft-ietf-roll-indus-routing-reqs-06 (work in progress),
June 2009.

7.3. External Informative References

[HART] HART Communication Foundation, HART 7.0 Specification[S],
2008

[IEEE802.15.4] IEEE Computer Society, "IEEE Std. 802.15.4-2006",
June 2006

Wang, et al. Expires October 21, 2012 [Page 13]

Internet-Draft draft-wang-6lowpan-scheduling-00 April 2012

[ISA100.11a] ISA100.11a Working Group,''Wireless systems for
industrial automation: Process control and related
applications,'' ISA100.11a Draft standard, September 2008.

[WIA-PA] IEC/PAS 62601 Ed.1.0[S], WIA-PA communication network and
communication profile, 2009

Perkins, C.E., and Royer, E., ''The Ad Hoc On-demand Distance Vector
Routing,'' IEEE Workshop on Mobile Computing Systems and
Applications, IEEE, pp. 90-100, 1999

8. Acknowledgments

Thanks to the authors of RFC 4944 and RFC 6282.And, thanks to XXX for
edit of this document. Also thanks to XXX et al.

This document was prepared using 2-Word-v2.0.template.dot.

Wang, et al. Expires October 21, 2012 [Page 14]

Internet-Draft draft-wang-6lowpan-scheduling-00 April 2012

Authors' Addresses

Heng Wang
Chongqing University of Posts and Telecommunications
Administrative Building, Chongqing University of Posts and
Telecommunications
Chongqing, 400065
China

Phone: (86) -23- 6248- 7845
Email: wangheng@cqupt.edu.cn

Ping Wang
Chongqing University of Posts and Telecommunications
Administrative Building, Chongqing University of Posts and
Telecommunications
Chongqing, 400065
China

Phone: (86) -23- 6246- 1061
Email: wangping@cqupt.edu.cn

Chao Zhou
Cisco Systems (China)
Research and Development Co., Ltd.
8Floor, Xinsi Mansion
926 Yishan Lu, Caohejing Hi-Tech Park,
Shanghai, 200233
China

Phone: (86) -21- 2407- 3419
Email: czhou@cisco.com

Wang, et al. Expires October 21, 2012 [Page 15]