Internet DRAFT - draft-wang-6tsch-6tus
draft-wang-6tsch-6tus
6TSCH Q. Wang, Ed.
Internet-Draft Univ. of Sci. and Tech. Beijing
Intended status: Informational X. Vilajosana
Expires: November 24, 2013 Universitat Oberta de Catalunya
T. Watteyne
Linear Technology
May 23, 2013
6tus Layer Specification
draft-wang-6tsch-6tus-01
Abstract
The recently published [IEEE802154e] standard formalizes the concept
of link-layer resources in LLNs. Nodes are synchronized and follow a
schedule. A time slot in that schedule corresponds to an atomic
link-layer resource, and can be allocated to any pair of neighbors in
the network. This allows the schedule to be built to tightly match
each node's bandwidth, latency and energy constraints, while ensuring
collision-free communication. The [IEEE802154e] standard does not,
however, present a mechanism to do so, as building and managing the
schedule is out of the standard's scope. Routing layers such as the
IETF IPv6 Routing Protocol for LLNs (RPL) provide a mechanism to
route multipoint-to-point traffic (from devices inside the LLN
towards a central control point) and point-to-multipoint traffic
(from the central control point to the devices inside the LLN).
Network layer overlays cannot be optimized and adapted to take
advantage of the cell-based topology created by the underlying TSCH
MAC layer as a missing set of functionalities need to be defined.
This document describes the 6tus layer and the main commands it
provides to upper network layers such as RPL or GMPLS. The set of
functionalities includes feedback metrics from cell states so network
layers can take routing decisions, TSCH configuration and control
procedures, and the support for centralized and decentralized
scheduling policies.
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/.
Wang, et al. Expires November 24, 2013 [Page 1]
Internet-Draft 6tsch-6tus May 2013
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 November 24, 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
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
2. 6tus Layer Specification . . . . . . . . . . . . . . . . . . 4
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Cell Model . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1. hard cells . . . . . . . . . . . . . . . . . . . . . 6
2.2.2. soft cells . . . . . . . . . . . . . . . . . . . . . 7
2.3. Data Convey Model . . . . . . . . . . . . . . . . . . . . 7
2.4. Commands . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.1. Cell Commands . . . . . . . . . . . . . . . . . . . . 8
2.4.2. Slotframe Commands . . . . . . . . . . . . . . . . . 13
2.4.3. Monitoring Commands . . . . . . . . . . . . . . . . . 14
2.4.4. Statistics Commands . . . . . . . . . . . . . . . . . 16
2.4.5. Network Formation Commands . . . . . . . . . . . . . 18
2.4.6. Time Source Neighbor Commands . . . . . . . . . . . . 20
2.4.7. Neighbor Commands . . . . . . . . . . . . . . . . . . 21
2.4.8. Queueing Commands . . . . . . . . . . . . . . . . . . 23
2.4.9. Security Commands . . . . . . . . . . . . . . . . . . 26
2.4.10. Data Commands . . . . . . . . . . . . . . . . . . . . 27
2.5. Message Formats . . . . . . . . . . . . . . . . . . . . . 29
2.5.1. Information Elements . . . . . . . . . . . . . . . . 29
2.5.2. Packet Formats . . . . . . . . . . . . . . . . . . . 37
2.6. Time Sequence . . . . . . . . . . . . . . . . . . . . . . 41
2.6.1. Network Formation . . . . . . . . . . . . . . . . . . 42
2.6.2. Creating soft cells . . . . . . . . . . . . . . . . . 43
Wang, et al. Expires November 24, 2013 [Page 2]
Internet-Draft 6tsch-6tus May 2013
2.6.3. Deleting soft cells . . . . . . . . . . . . . . . . . 44
2.6.4. Maintaining soft cells . . . . . . . . . . . . . . . 44
2.6.5. Creating hard cells . . . . . . . . . . . . . . . . . 44
2.6.6. Deleting hard cells . . . . . . . . . . . . . . . . . 45
2.7. Statistics . . . . . . . . . . . . . . . . . . . . . . . 45
2.7.1. Statistics Metrics . . . . . . . . . . . . . . . . . 45
2.7.2. Statistics Configuration . . . . . . . . . . . . . . 46
2.8. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 46
2.8.1. Monitor Configuration . . . . . . . . . . . . . . . . 46
2.8.2. Actuation . . . . . . . . . . . . . . . . . . . . . . 47
3. Using 6tus . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.1. RPL on 6tus . . . . . . . . . . . . . . . . . . . . . . . 47
3.1.1. Support to Neighbor Discovery and Parent Selection . 47
3.1.2. Support to Rank Computation . . . . . . . . . . . . . 48
3.1.3. Support to Control Messages Broadcast . . . . . . . . 49
3.1.4. Support to QoS . . . . . . . . . . . . . . . . . . . 50
3.2. GMPLS on 6tus . . . . . . . . . . . . . . . . . . . . . . 51
3.2.1. Cell Reservation Support for GMPLS on 6tus . . . . . 51
3.2.2. Supporting QoS . . . . . . . . . . . . . . . . . . . 52
4. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.1. Normative References . . . . . . . . . . . . . . . . . . 52
4.2. Informative References . . . . . . . . . . . . . . . . . 52
4.3. External Informative References . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55
1. Introduction
As presented in [I-D.watteyne-6tsch-tsch-lln-context], the
[IEEE802154e] standard defines the mechanisms for a TSCH node to
communicate given a schedule. It does not, however, define the
policies to build and maintain the TSCH schedule, match that schedule
to the multi-hop paths maintained by a network layer such as RPL or a
2.5 layer such as GMPLS, adapt the resources allocated between
neighbor nodes to the data traffic flows, enforce a differentiated
treatment for data generated at the application layer and signaling
messages needed by 6LoWPAN and RPL to discover neighbors, react to
topology changes, self-configure IP addresses, or manage keying
material.
In a TSCH network, the MAC layer is not in charge of setting up the
schedule that controls the connectivity graph of the network and the
resources allocated to each cell in that topology. This
responsibility is left to an upper layer, defined in this document
and called "6tus" (pronounced "sixtus").
This document describes the 6tus layer and the main commands provided
to upper network layers such as RPL or GMPLS. The set of
functionalities include feedback metrics from cell state so the
Wang, et al. Expires November 24, 2013 [Page 3]
Internet-Draft 6tsch-6tus May 2013
network layer can take routing decisions, TSCH configuration and
control procedures and support centralized and decentralized
scheduling policies. The 6tus layer addresses the set of
functionalities described in [I-D.watteyne-6tsch-tsch-lln-context].
For example, network formation in a TSCH network is handled by the
use of Enhanced Beacons (EB). EBs include information for joining
nodes to be able to synchronize and set up an initial network
topology, however [IEEE802154e] does not specify how the period of
EBs is configured, nor the rules for a node to select a particular
node to join. The 6tus layer offers a set of commands so control
mechanisms can be introduced on top of TSCH so nodes configure to
join a specific node and obtain an unique 16-bit identifier from the
network. Once a network is formed, 6tus maintains the network's
health, allowing for nodes to stay synchronized. It supplies
mechanisms to manage each node's time source neighbor and configure
the EB interval. Network layers running on top of 6tus take
advantage of the TSCH MAC layer information so routing metrics,
topological information, energy consumption and latency requirements
can be adjusted to TSCH and adapted to application requirements.
TSCH requires a mechanism to manage its schedule; 6tus provides a set
of commands for upper layers to set up specific schedules, either
explicitly by detailing specific cell information, or by allowing
6tus to establish a schedule given a bandwidth or latency
requirement. 6tus is designed to enable centralized, decentralized
or hybrid scheduling entities. 6tus enables internal TSCH queuing
configuration, size of buffers, packet priorities, and transmission
failure behavior, and defines mechanisms to encrypt and authenticate
MAC slotframes.
2. 6tus Layer Specification
2.1. Overview
6tus is a layer which is the next-higher layer for TSCH, as detailed
in [I-D.draft-thubert-6tsch-architecture]. 6tus offers both
management and data interfaces to an upper layer. It includes
monitoring and statistics collection, both of which are configurable
through the management interface.
6tus distinguishes between hard cells and soft cells. It therefore
requires an extra flag to all cells in the TSCH schedule, as detailed
in Section 2.2.
When a higher layer gives 6tus a 6LoWPAN packet for transmission,
6tus maps it to the appropriate outgoing priority-based queue, as
detailed in Section 2.3.
Wang, et al. Expires November 24, 2013 [Page 4]
Internet-Draft 6tsch-6tus May 2013
All commands of the management and data interfaces are detailed in
Section 2.4. This set of commands is designed to support
centralized, decentralized and hybrid scheduling entities.
6tus defines TSCH Information Elements (IEs) for neighbors nodes to
negociate scheduling cells in the TSCH schedule. The format of those
is given in Section 2.5.
Example data exchanges between neighbor nodes are illustrated in
Section 2.6.
Section 2.7 defines how 6tus gathers statistics (e.g. link quality,
energy level, queue usage), and what commands an upper layer can use
to configure and retrieve statistics.
6tus can be configured to monitor some cells it has scheduled to
detect cells with poor performance. It can then automatically move
those cells inside the TSCH schedule. This behavior is described in
Section 2.8
2.2. Cell Model
IEEE802.15.4e defines a set of options attached to each cell. A cell
can be a Transmit cell, a Receive cell, a Shared cell or a
Timekeeping cell. These options are not exclusive, as a cell can be
qualified with more than one of them. The IEEE802.15.4e MLME-SET-
LINK.request command uses a linkOptions bitmap to specify the options
of a cell. Acceptable values are:
b0 = Transmit
b1 = Receive
b2 = Shared
b3 = Timekeeping
b4-b7 = Reserved
Only Transmit cells can also be marked as Shared cells. When the
shared bit is set, and a back-off procedure is applied to handle
collisions. Shared behavior is not defined for Receive cells.
6tus allows an upper layer to schedule a cell at a specific timeslot
and channel offset in a specific slotframe. 6tus follows the hard
cell reservation process described in Section 2.6.5.
Wang, et al. Expires November 24, 2013 [Page 5]
Internet-Draft 6tsch-6tus May 2013
In addition, 6tus allows an upper layer to schedule a certain amount
of bandwidth to a neighbor, without having to specify the exact
timeslot(s) and channel offset(s). 6tus follows the soft cell
reservation process described in Section 2.6.2. Once bandwidth is
reserved, 6tus is in charge of ensuring that this requirement is
continuously satisfied, as described in Section 2.8. 6tus
dynamically reallocates slots if needed, and overprovisions if
required.
Given this mechanism, 6tus defines hard cells (which have been
requested specifically) and soft cells (which that can be reallocated
dynamically). The hard/soft flag is introduced by the 6tus layer as
an extension of the IEEE802.15.4e LinkOption flags. This option is
mandatory; all cells are either hard or soft.
With the addition of the Hard/Soft flag, the resulting flags are:
b0 = Transmit
b1 = Receive
b2 = Shared
b3 = Timekeeping
b4 = Hard (1)/Soft (0)
b5-b7 = Reserved
2.2.1. hard cells
A hard cell is a cell that cannot be dynamically reallocated by 6tus.
A hard cell is uniquely identified by the following tuple:
slotframe id: id of the slotframe this cell is part of.
timeslot: the slot within the slotframe.
channel offset.
LinkOption bitmap: bitmap as defined in Section 2.2, including the
hard/soft bit which must be set to 1.
Wang, et al. Expires November 24, 2013 [Page 6]
Internet-Draft 6tsch-6tus May 2013
2.2.2. soft cells
A soft cell is a cell that can be reallocated by 6tus dynamically.
The hard/soft bit must be set to 0. This cell is installed by 6tus
given a specific bandwidth requirement. soft cells are installed
through the soft cell negotiation process described in Section 2.6.
2.3. Data Convey Model
Based on the established TSCH schedule, 6tus is responsible for
feeding the data flow from the upper layer into TSCH. This section
describes how 6tus shapes data from upper layer (e.g. RPL, 6LoWPAN),
and feeds it to TSCH. Since 6tus is a layer between TSCH and
6LoWPAN, the properties assciated with a packet/fragment from the
upper layer includes the next hop neighbor (DestAddr) and expected
sending priority of the packet (Priority). The output to TSCH is the
fragment corresponding to the next active cell in the TSCH schedule.
6tus Data Convey Model
|
| (DestAddr, Priority, Fragment)
|
+---------------------------------------+
| I-MUX |
+---------------------------------------+
| | | | .... |
| | | | |
+---+ +---+ +---+ +---+ +---+
| | | | | | | | | |
|Q1 | |Q2 | |Q3 | |Q4 | |Qn |
| | | | | | | | | |
+---+ +---+ +---+ +---+ +---+
| | | | |
| | | | |
+---------------------------------------+
| MUX |
+---------------------------------------+
|
|
+---+
|PDU|
+---+
|
| TSCH MAC-payload
|
Figure 1
Wang, et al. Expires November 24, 2013 [Page 7]
Internet-Draft 6tsch-6tus May 2013
In Figure 1, Qi represents a queue, which is either broadcast or
unicast, and is assigned a priority. The number of queues is
configurable. The relationship between queues and slotframes is
configurable. For example, for a given queue, only one specific
slotframe can be used, or all of the slotframes can be used, or a
subset of slotframes can be used.
When 6tus receives a packet to transmit through a Send.data command
(Section 2.4.10), the I-MUX module selects a queue in which to insert
it. If the packet's destination address is a unicast (resp.
broadcast) address, it will be inserted into a unicast (resp.
broadcast) queue.
The MUX module is invoked at each scheduled transmit cell by TSCH.
When invoked, the MUX module goes through the queues, looking for the
best frame to send. If it finds a frame, it hands it over to TSCH
for transmission. If the next active cell is a broadcast cell, it
selects a fragment only from broadcast queues.
How the MUX module selects the best frame is configurable.
Typically, the following rules are used:
The frame's layer 2 destination address must match the neighbor
address associated with the transmit cell.
Frames from a queue with a high priority must be sent before
frames from a queue with a low priority.
Further rules can be configured to satisfy specific QoS requirements.
2.4. Commands
6tus provides a set of commands a higher layer can call, including
management commands and data commands. Most of these commands are
related to the management of slotframes, time slots and scheduling
information. 6tus also provides an interface allowing an upper layer
to retrieve status information and statistics. This section lists
the commands offered by 6tus.
2.4.1. Cell Commands
The following methods allow an upper layer to manage the network
schedule:
2.4.1.1. CREATE.hardcell
Wang, et al. Expires November 24, 2013 [Page 8]
Internet-Draft 6tsch-6tus May 2013
Creates one or more hard cells in the schedule. Fails if the cell
already exists. A cell is uniquely identified by the tuple
(slotframe id, timeslot, channel offset).
To create a hard cell, the upper layer specifies:
slotframe id: id of the slotframe this slot will be scheduled in.
time slot: the specific time slot number.
channel offset: the frequency offset.
LinkOption bitmap: bitmap as defined in Section 2.2
target node address: the address of that node to communicate with
over this cell. In case of broadcast cells this is the broadcast
address.
6tus schedules the cell and marks it as a hard cell, indicating that
it cannot reschedule this cell.
2.4.1.2. CREATE.softcell
To create a soft cell, the upper layer specifies:
slotframe id: id of the slotframe this slot will be scheduled in
number of cells: the required number of soft cells.
LinkOption bitmap: bitmap as defined in Section 2.2
target node address: the address of that node to communicate with
over this cell. In case of broadcast cells this is the broadcast
address.
QoS level: the cell redundancy policy. The policy can be for
example STRICT, BEST_EFFORT, etc.
6tus is responsible for picking the exact timeslot and channel offset
in the schedule, and ensure that the target node chooses the same.
6tus marks these cells as soft cell, indicating that it will
continuously monitor their performance and reschedule if needed.
6tus deals with the allocation process by negotiation with the target
node. The negotiation process is described in Section 2.6.2. The
command returns the list of created cells defined by (slotframe id,
time slot number, channel offset). It fails if the required number
of cells is higher than the available number of cells in the
Wang, et al. Expires November 24, 2013 [Page 9]
Internet-Draft 6tsch-6tus May 2013
schedule. It fails if the negotiation with the target node fails.
It fails if the cell Option bitmap indicates that the cell MUST be
Hard.
2.4.1.3. READ.cell
Given a (slotframe id, time slot number, channel offset), retrieves
the cell information. Fails if the cell does not exist. The
returned information contains:
slotframe id: the id of the slotframe where this cell is
installed.
time slot: the time slot where the cell is set.
channel offset: the selected channel offset for the cell.
LinkOption bitmap: bitmap as defined in Section 2.2
target node address: the target address of that cell. In case of
broadcast cells this is the broadcast address.
A read command can be issued for any cell, hard or soft.
2.4.1.4. UPDATE.cell
Update a hard cell, i.e. move it to a different timeslot and/or
channel offset. Fails if the cell does not exist. Requires a
(slotframe id, time slot, channel offset), type of cell and target
node are the fields that can be updated. soft cells cannot be
updated by the UPDATE.cell command. REALLOCATE.softcell
(Section 2.4.1.7) MUST be used instead.
2.4.1.5. DELETE.hardcell
To removes a hard cell, the upper layer specifies:
slotframe id: the id of the slotframe where this cell is
installed.
time slot: the time slot where the cell is set.
channel offset: the selected channel offset for the cell.
This removes the hard cell from the node's schedule.
2.4.1.6. DELETE.softcell
Wang, et al. Expires November 24, 2013 [Page 10]
Internet-Draft 6tsch-6tus May 2013
To remove a (number of) soft cell(s), the upper layer specifies:
slotframe id: the id of the slotframe where this cell is
installed.
number of cells: the number of cells to be removed
LinkOption bitmap: bitmap as defined in Section 2.2
target node address: the target address of that cell. In case of
broadcast cells this is the broadcast address.
In the case a soft cell wants to be moved from the allocated slot so
a hard cell can be installed instead, the REALLOCATE.softcell
(Section 2.4.1.7) MUST be used.
2.4.1.7. REALLOCATE.softcell
To force a move of a soft cell, the upper layer specifies:
slotframe id: the id of the slotframe where the cell is allocated.
time slot: the slot number where that cell is installed.
channel offset: the channel offset for that cell.
The reallocated cell will be installed in a different slot, channel
offset but same slotframe. hard cells cannot be reallocated.
2.4.1.8. Hardcell Command Behavior
The following table describe the behavior of 6tus upon reception of
the hard cell management commands.
hard cell Operations behavior
Wang, et al. Expires November 24, 2013 [Page 11]
Internet-Draft 6tsch-6tus May 2013
+---------------------------------+---------------------------------+
| 6tus commands | 6tus behavior |
+---------------------------------+---------------------------------+
| Create.hardcell | 6tus_ReserveHardCellReq() -ACK |
| (NeigAddr, SlotframeID, | |
| SlotOffset, | If NeigAddr ==Broadcast Address|
| ChannelOffset, LinkOption) | Then LinkType=ADVERTISING |
| | Add cell to EB's FrameAndCellIE |
+---------------------------------+---------------------------------+
| Read.cell | MLME-GET.request |
|(NeigAddr,SlotframeID,SlotOffset,| |
| ChannelOffset, LinkOption) | |
+---------------------------------+---------------------------------+
| Delete.hardcell | 6tus_RemoveHardCellReq() --ACK |
| (NeigAddr ,SlotOffset, | |
| ChannelOffset, LinkOption) | If LinkType=ADVERTISING, it is a|
| | broadcast cell, Then Remove cell|
| | from EB's FrameAndCellIE |
+---------------------------------+---------------------------------+
| Update.cell | 6tus_RemoveHardCellReq() --ACK |
| (OldFrameID, OldSlotOffset, | 6tus_ReserveHardCellReq() --ACK |
| OldChannelOffset, NewFrameID, | (with same NeigAddr,LinkOption) |
| NewSlotOffset,NewChannelOffset)| If old cell is in EB |
| | Then modify EB |
+---------------------------------+---------------------------------+
2.4.1.9. Softcell Command Behavior
The following table describe the behavior of 6tus upon reception of
the Softcell management commands.
soft cell Operations behavior
Wang, et al. Expires November 24, 2013 [Page 12]
Internet-Draft 6tsch-6tus May 2013
+--------------------------------+----------------------------------+
| 6tus commands | 6tus behavior |
+--------------------------------+----------------------------------+
| Create.softcell | 6tus_ReserveSoftCellReq() -ACK |
|(NeigAddr, NumCell,LinkOption, | ACK ---6tus_ReserveSoftCellResp()|
| SlotframeID, QoSLevel) | |
+--------------------------------+----------------------------------+
| Read.cell | MLME-GET.request |
|(NeigAddr,SlotframeID, | |
| SlotOffset,ChannelOffset) | |
+--------------------------------+----------------------------------+
| Delete.softcell | 6tus_RemoveSoftCellReq() -- ACK |
| (NeigAddr ,NumCell, | If LinkType =ADVERTISING |
| LinkOption, SlotframeID) | i.e. a broadcast cell Then Remove|
| | cell from EB's FrameAndCellIE |
+--------------------------------+----------------------------------+
| Reallocate.softcell | 6tus_RemoveSoftCellReq() -- ACK |
|(NeigAddr,SlotframeID, | 6tus_ReserveSoftCellReq() -- ACK |
| SlotOffset,ChannelOffset) | ACK ---6tus_ReserveSoftCellResp()|
+--------------------------------+----------------------------------+
2.4.2. Slotframe Commands
6tus provides the following commands to manage TSCH slotframes.
2.4.2.1. CREATE.slotframe
Creates a new slotframe. Returns the slotframe id that corresponds
to its priority (SlotFrameHandle). The command requires:
number of slots: the required number of slots.
Fails if the number of required slots is less than zero.
2.4.2.2. READ.slotframe
Returns the information of a slotframe given its slotframe id. The
command returns:
slotframe id: the id of the slotframe. (SlotFrameHandle)
number of slots: the number of slots.
Fails if the slotframe id does not exist.
2.4.2.3. UPDATE.slotframe
Wang, et al. Expires November 24, 2013 [Page 13]
Internet-Draft 6tsch-6tus May 2013
Change the number of slots in a slotframe. The command requires:
slotframe id: the id of the slotframe.
number of slots: the number of slots to be updated.
Fails if the number of required slots is less than zero. Fails if
the slotframe id does not exist.
2.4.2.4. DELETE.slotframe
Deletes a slotframe. The command requires:
slotframe id: the id of the slotframe.
Fails if the slotframe id does not exist.
2.4.2.5. Slotframe Command Behavior
The following table describes the behavior of 6tus upon reception of
the Slotframe management commands.
Slotframe Management Operations behavior
+--------------------------------+----------------------------------+
| 6tus commands | 6tus behavior |
+--------------------------------+----------------------------------+
| Create.slotframe(NumSlot) | MLME-SET-SLOTFRAME.request |
| |(operation=ADD) |
+--------------------------------+----------------------------------+
| Read.slotframe(SlotframeID) | MLME-GET.request |
+--------------------------------+----------------------------------+
| Delete.slotframe(SlotframeID) | MLME-SET-SLOTFRAME.request |
| |(operation=DELETE) |
+--------------------------------|----------------------------------+
| Update.slotframe(SlotframeID | MLME-SET-SLOTFRAME.request |
| ,NumSlot) |(operation=MODIFY) |
+--------------------------------+----------------------------------+
2.4.3. Monitoring Commands
Monitoring commands provide the means for upper layers to configure
whether 6tus must ensure the required bandwidth. This procedure is
achieved through over-provisioning according to cell status feedback.
Monitoring is also in charge of reallocating soft cells that are
under the required QoS. The mechanism is described in Section 2.8.
Wang, et al. Expires November 24, 2013 [Page 14]
Internet-Draft 6tsch-6tus May 2013
2.4.3.1. CONFIGURE.monitoring
Configures the level of QoS the Monitoring process must enforce. The
command requires:
slotframe id: the id of the slotframe.
target node: the destination node.
enforce policy: The policy used to enforce the QoS requirements.
Can be for example DISABLE, BEST_EFFORT, STRICT, OVER-PROVISION,
etc.
Fails if the slotframe id does not exist.
2.4.3.2. READ.monitoring.status
Reads the current Monitoring status. Requires the following
parameters.
slotframe id: the id of the slotframe.
target node: the destination node.
Returns the QoS levels for that Target node on that slotframe.
allocated_hard: Number of hard cells allocated.
allocated_soft: Number of soft cells allocated.
provisioned: the extra provisioned cells. 0 if CONFIGURE.qos
enforce is DISABLE.
QoS: the current QoS. Including overprovisioned cells, i.e what
bandwidth is being obtained including the overprovisioned cells.
RQoS: the real QoS without provisioned cells. What is the actual
bandwidth without taking into account the overprovisioned cells.
Fails if the slotframe id does not exist.
2.4.3.3. Monitoring Command Behavior
The following table describes the behavior of 6tus upon reception of
the Monitoring management commands.
Monitoring Management Operations behavior
Wang, et al. Expires November 24, 2013 [Page 15]
Internet-Draft 6tsch-6tus May 2013
+------------------------------------+------------------------------+
| 6tus commands | 6tus behavior |
+------------------------------------+------------------------------+
| Configure.monitoring(NeigAdd, | Create/Update Monitoring MIB |
| SlotframeID,Enforce) | Starts monitoring service |
+------------------------------------+------------------------------+
| Read.monitoring.status(SlotframeID)| Reads 6tus Monitoring MIB |
+------------------------------------+------------------------------+
Figure 2
2.4.4. Statistics Commands
6tus keeps track of TSCH statistics for upper layers to adapt
correctly to medium changes. The exact metrics for statistics are
out of the scope of this document but the present commands should be
used to configure and read monitored information regardless of the
specific metric.
2.4.4.1. CONFIGURE.statistics
Configures Statistics process. The command requires:
slotframe id: the id of the slotframe. If empty monitors all
slotframe ids
time slot: slot number to be monitored. If empty all slots are
monitored
channel offset: specific channel offset to be monitored. If empty
all channels are monitored.
target node: the destination node. If empty, all target nodes are
monitored.
metric: metric to be monitored. This may be PDR, ETX, queuing
statistics, energy-related metrics, etc.)
window: time window to be considered for the calculations. If 0
all historical data is considered.
enable: Enables statistics or disables them.
Fails if the slotframe id does not exist. The statistics service can
be configured to retrieve statistics at different levels. For
example to aggregate information by slotframe id, or to retrieve
statistics for a particular slot, etc. the CONFIGURE.statistics
enables flexible configuration by supporting empty parameters that
Wang, et al. Expires November 24, 2013 [Page 16]
Internet-Draft 6tsch-6tus May 2013
will force the monitoring of the statistics by all members of that
dimension.
2.4.4.2. READ.statistics
Reads a metric for the specified dimension. Information is
aggregated according to the parameters. The command requires:
slotframe id: the id of the slotframe. If empty aggregates
information of all slotframe ids
time slot: the slot number for which the information is required.
If empty all slots are aggregated
channel offset: the specific channel offset for which the
information is required. If empty all channels are aggregated.
target node: the destination node. If empty all target nodes are
aggregated.
metric: metric to be read.
Returns the value for the requested metric.
Fails if empty metric or metric does not exits.
2.4.4.3. RESET.statistics
Resets the gathered statistics. The command requires:
slotframe id: the id of the slotframe. If empty resets the
information of all slotframe ids
time slot: the slot number for which the information wants to be
reset. If empty statistics from all slots are reset
channel offset: the specific channel offset for which the
information wants to be reset. If empty all statistics for all
channels are reset.
target node: the destination node. If empty all statistics for
the target node are reset.
metric: metric to be reset.
Fails if empty metric or metric does not exits.
Wang, et al. Expires November 24, 2013 [Page 17]
Internet-Draft 6tsch-6tus May 2013
2.4.4.4. Statistics Command Behavior
The following table describes the behavior of 6tus upon reception of
the Statistics management commands.
Statistics Management Operations behavior
+--------------------------------+----------------------------------+
| 6tus commands | 6tus behavior |
+--------------------------------+----------------------------------+
| Configure.statistics | |
| (SlotFrameID,TSlot, ChannelOff,| Configures Statistics MIB. |
| NeigAdd,Metric,Window,En) | Enables statistics service |
+--------------------------------+----------------------------------+
| Read.statistics(SlotFrameID) | Returns the statistic MIB for the|
| Ch.Off,NeigAdd,Metric) | requested parameters |
+--------------------------------+----------------------------------+
| Reset.statistics(SlotFrameID) | Resets the required statistic MIB|
| Ch.Off,NeigAdd,Metric) | |
+--------------------------------+----------------------------------+
2.4.5. Network Formation Commands
EBs need to be configured, including their transmission period, the
slot number and channel offset that they should be sent on, and the
priority announced. The parameters for that command are optional and
enable a very flexible configuration of EBs. If slotframe id is
specified, the EBs will be configured to use that specific slotframe;
if not they will use the first slotframe where the configured time
slot is allocated. Time slot enforces the EB to a specific time
slot. In case time slot parameter is not present, the EB is sent in
the first available transmit time slot. In case channel offset
parameter is not set, the EB is configured to use the first available
channel.
2.4.5.1. CONFIGURE.eb
Configures EBs. The command requires:
slotframe id: the id of the slotframe where the EBs MUST be sent.
Zero if any slotframe can be used.
time slot: the slot number where the EBs MUST be sent. Zero if
any timeslot can be used.
channel offset: the channel offset where the EBs MUST be sent.
Zero if any channel offset can be used.
Wang, et al. Expires November 24, 2013 [Page 18]
Internet-Draft 6tsch-6tus May 2013
period: the EBs period, in seconds.
expires: when the EBs periodicity will stop. If Zero the period
never stops.
priority: the joining priority model that will be used for
advertisement. Joining priority MAY be for example
SAME_AS_PARENT, RANDOM, BEST_PARENT+1.
Fails if the tuple slotframe id, timeslot, channel offset is already
scheduled.
2.4.5.2. READ.eb
Reads the EBs configuration. No parameters are required.
Returns the current EBs configuraton for that slotframe, which
contains:
slotframe id: the slotframe where the EB is being sent.
time slot: the slot number where the EBs is being sent.
channel offset: the channel offset the EBs is being sent on.
period: the EBs period.
expires: when the EBs periodicity stops. If 0 the period never
stops.
priority: the joining priority that this node advertises.
Fails if the slotframe id does not exist.
2.4.5.3. Network Formation Command Behavior
The following table describes the behavior of 6tus upon reception of
the Network Configuration management commands.
Network Configuration Management Operations behavior
Wang, et al. Expires November 24, 2013 [Page 19]
Internet-Draft 6tsch-6tus May 2013
+----------------------------------+--------------------------------+
| 6tus commands | 6tus behavior |
+----------------------------------+--------------------------------+
| Configure.EB(SlotFrameID,TSlot, | Configures the 6tus MIB |
| Ch.Off,Period,Expires,Prio,Con_p)| regarding EB configuration |
+----------------------------------+--------------------------------+
| Read.EB() | Reads 6tus EB MIB |
| | |
+----------------------------------+--------------------------------+
2.4.6. Time Source Neighbor Commands
Commands to select time source neighbors.
2.4.6.1. CONFIGURE.timesource
Configures the Time Source Neighbor selection process. More than one
time source neighbor can be selected. The command requires:
selection policy: The policy used to select the time parent. The
policy MAY be for example ALL_PARENTS, BEST_CONNECTED,
LOWEST_JOIN_PRIORITY, etc.
Fails if any of the time source neighbors do not exist or it is not
reachable.
2.4.6.2. READ.timesource
Retrieves information about the time parents of that node. The
command does not require any parameter.
Returns the following information for each of the time sources:
target node: address of the time parent.
statistics: includes for example minimum, maximum, average time
correction for that time parent
policy: the used policy
Fails if the slotframe id or no time source neighbors exist.
Wang, et al. Expires November 24, 2013 [Page 20]
Internet-Draft 6tsch-6tus May 2013
2.4.6.3. Time Source Neighbor Command Behavior
The following table describes the behavior of 6tus upon reception of
the Time Source Neighbor Configuration management commands.
Time Source Neighbors Configuration Management Operations behavior
+---------------------------------+---------------------------------+
| 6tus commands | 6tus behavior |
+---------------------------------+---------------------------------+
| Configure.timesource(Policy) | Configures the 6tus MIB |
| | regarding timesource parents |
+---------------------------------+---------------------------------+
| Read.timesource() | Read 6tus timesource MIB |
| | |
+---------------------------------+---------------------------------+
Figure 3
2.4.7. Neighbor Commands
Commands to manage neighbor table. The commands SHOULD be used by
the upper layer to query the neighbor related information and by the
lower layer to keep track of neighbors information.
2.4.7.1. CREATE.neighbor
Creates an entry for a neighbor in the neighbor table.
neighbor address: The address of the neighbor.
neighbor stats: for example, RSSI of the last received packet from
that neighbor, ASN when that neighbor has been added, etc.
Returns whether the neighbor is created or not.
2.4.7.2. READ.all.neighbor
Returns the list of neighbors of that node. Fails if empty. For
each neighbor in the list it returns:
neighbor address: The address of the neighbor.
neighbor stats: for example, RSSI of the last received packet from
that neighbor, ASN when that neighbor has been added, packets
received from that neighbor, packets sent to it, etc. .
Wang, et al. Expires November 24, 2013 [Page 21]
Internet-Draft 6tsch-6tus May 2013
2.4.7.3. READ.neighbor
Returns the information of a specific neighbors of that node
specified by its neighbor address. Fails if it does not exists. For
that neighbor it returns:
neighbor address: The address of the neighbor.
neighbor stats: for example, RSSI of the last received packet from
that neighbor, ASN when that neighbor has been added, packets
received from that neighbor, packets sent to it, etc.
2.4.7.4. UPDATE.neighbor
Updates an entry for a neighbor in the neighbor table. Fails if the
neighbor does not exist. Updates stats parameters. Requires:
neighbor address: The address of the neighbor.
neighbor stats: for example, RSSI of the last received packet from
that neighbor, ASN when that neighbor has been added, etc. .
Returns whether the neighbor is updated or not.
2.4.7.5. DELETE.neighbor
Deletes a neighbor given its address. Fails if the neighbor does not
exists.
2.4.7.6. Neighbors Command Behavior
The following table describes the behavior of 6tus upon reception of
the Neighbors Configuration management commands.
Neighbors Management Operations behavior
Wang, et al. Expires November 24, 2013 [Page 22]
Internet-Draft 6tsch-6tus May 2013
+---------------------------------+---------------------------------+
| 6tus commands | 6tus behavior |
+---------------------------------+---------------------------------+
| Create.neighbor(address,stats) | Adds a neighbor to the neighbor |
| | table in the 6tus MIB. |
+---------------------------------+---------------------------------+
| Read.all.neighbor() | lists all neighbors from the |
| | neighbor table. |
+---------------------------------+---------------------------------+
| Read.neighbor(address) | Reads neighbor information from |
| | neighbor table in the 6tus MIB |
+---------------------------------+---------------------------------+
| Update.neighbor(address,stats) | Updates an entry for a neighbor |
| | in the 6tus MIB |
+---------------------------------+---------------------------------+
| Delete.neighbor(address) | Removes the neighbor from the |
| | 6tus MIB |
+---------------------------------+---------------------------------+
2.4.8. Queueing Commands
TSCH MAC layer queues need to be configured. This includes queue
length, retransmission policy, discarding of packets, etc.
2.4.8.1. CREATE.queue
Creates and Configures TSCH Queues. The command SHOULD be applied
for each required queue. The command requires:
txqlength: the desired transmission queue length.
rxqlength: the desired reception queue length.
numrtx: number of allowed retransmissions.
age: discard packet according to its age on the queue. 0 if no
discards are allowed.
rtxbackoff: retransmission back off in number of slotframes. 0 if
next available slot wants to be used.
statswindow: window of time used to compute stats.
queue priority: the priority of this queue.
Returns the queue id.
Wang, et al. Expires November 24, 2013 [Page 23]
Internet-Draft 6tsch-6tus May 2013
2.4.8.2. READ.queue
Reads the queue configuration. Requires the queue id.
The command returns:
txqlength: the transmission queue length.
rxqlength: the reception queue length.
numrtx: number of allowed retransmissions.
age: maximum age of a packet befoer being discarded. 0 if no
discards are allowed.
rtxbackoff: retransmission backoff in number of slotframes. 0 if
next available slot is used.
2.4.8.3. READ.queue.stats
Reads the queue stats. Requires queue id.
The command returns:
txqlengthstats: average, maximum, minimum length of the
transmission queue.
rxqlengthstats: average, maximum, minimum length of the reception
queue.
numrtxstats: average, maximum, minimum number of retransmissions.
agestats: average, maximum, minimum age of a packet in the queue.
rtxbackoffstats: average, maximum, minimum retransmission backoff.
queue priority: the priority of this queue.
2.4.8.4. UPDATE.queue
Update a TSCH Queue. The command requires:
queueid: the desired transmission queue length.
txqlength: the desired transmission queue length.
rxqlength: the desired reception queue length.
Wang, et al. Expires November 24, 2013 [Page 24]
Internet-Draft 6tsch-6tus May 2013
numrtx: number of allowed retransmissions.
age: discard packet according to its age on the queue. 0 if no
discards are allowed.
rtxbackoff: retransmission backoff in number of slotframes. 0 if
next available slot wants to be used.
statswindow: window of time used to compute stats.
2.4.8.5. DELETE.queue
Deletes a TSCH Queue. The command requires the queue id. All
packets in the queue are discarded and the queue is deleted.
2.4.8.6. Queueing Command Behavior
The following table describes the behavior of 6tus upon reception of
the Queue management commands.
Queue Management Operations behavior
+---------------------------------+---------------------------------+
| 6tus commands | 6tus behavior |
+---------------------------------+---------------------------------+
| Create.queue(tqlen,trlen,numrtx,| Creates a queue with specified |
| age,rtxbackoff,prio) | parameters. Updates 6tus MIB. |
+---------------------------------+---------------------------------+
| Read.queue(id) | Reads the queue configuration |
| | from 6tus MIB. |
+---------------------------------+---------------------------------+
| Update.queue(id,tqlen,trlen, | Updates the queue configuration |
| numrtx,age,rtxbackoff,prio) | from 6tus MIB. Readjustes actual|
| | queue size if required. |
+---------------------------------+---------------------------------+
| Delete.queue(id) | Deletes the queue from MIB. |
| | |
+---------------------------------+---------------------------------+
| Read.queue.stats() | Reads the queue |
| | stats from 6tus MIB. |
+---------------------------------+---------------------------------+
Wang, et al. Expires November 24, 2013 [Page 25]
Internet-Draft 6tsch-6tus May 2013
2.4.9. Security Commands
The following commands are used to manage underlying layer security.
In that case 6tus acts as delegating interface to IEEE802.15.4
security configuration commands.
2.4.9.1. CONFIGURE.security
Enables/Disables Security and configures the MAC PIB. The command
requires:
enable: enables underlying layer security.
macAutoRequestSecurityLevel: the security level used for automatic
data requests as described by IEEE 802.15.4 table 61.
macAutoRequestKeyIdMode: the key identifier mode used for
automatic data requests as described by IEEE 802.15.4 table 61.
macAutoRequestKeySource: the originator of the key for automatic
data requests as described by IEEE 802.15.4 table 61.
macAutoRequestKeyIndex: the index of the key used for automatic
data requests as described by IEEE 802.15.4 table 61.
macDefaultKeySource: the originator of the default key used for
key identifier mode 0x01 as described by IEEE 802.15.4 table 61.
macPANCordinatorExtendedAddress: Address of the PAN coordinator as
described by IEEE 802.15.4 table 61.
macPANCordinatorShortAddress: Short address of the PAN coordinator
as described by IEEE 802.15.4 table 61.
2.4.9.2. CONFIGURE.security.macKeyTable
Configures Security Keys. The command requires:
KeyIdLookupList: list of keyIdLookupDescriptor Entries as defined
by IEEE 802.15.4 table 61.
DeviceDescriptorHandleList: Implementation specific list of
devices that are using this key. As defined by IEEE 802.15.4
table 61.
KeyUsageList: List of slotframe types on which this key is being
used as specified by IEEE 802.15.4 section 7.4.1.2
Wang, et al. Expires November 24, 2013 [Page 26]
Internet-Draft 6tsch-6tus May 2013
Key: 16 octets key. As specified by IEEE 802.15.4 table 61.
2.4.9.3. CONFIGURE.security.macSecurityLevelTable
Configures the set of security levels. The command requires:
FrameType: Slotframe type as defined by IEEE802.15.4e std.
Command Identifier: The command identifier as defined by
IEEE802.15.4e std.
Security Minimum: The minimum required security level as specified
by IEEE 802.15.4e
Device Override Security Minimum: whether the minimum security
level can be overridden as specified by IEEE 802.15.4 Table 64
Allowed Security Levels: the key identifier field that identifies
the key that is being used as specified by IEEE 802.15.4 section
7.4.3
2.4.9.4. Security Command Behavior
6tus offers the interface to upper layers so underlying MAC layer can
be configured. In that sense, 6tus acts as a "none-layer" by only
delegating the functionalities to the MAC security services. For
more details Section 7 on IEEE802.15.4-2011 and its amendments on
IEEE802.15.4e-2012 should be referred.
2.4.10. Data Commands
2.4.10.1. Send.data
The command used by upper layers to queue a packet so underlying TSCH
sends it. According to the specific priority the packet is pushed
into a Queue with the equivalent priority or following a criteria out
of the scope of this document. Once a packet is inserted into a
queue it waits to be transmitted by TSCH according to the model
defined in Section 2.3.
The required parameters are:
src address: L2 source address
dest address: L2 unicast or broadcast destination address
priority: packet priority, usually is consistent with queue
priority
Wang, et al. Expires November 24, 2013 [Page 27]
Internet-Draft 6tsch-6tus May 2013
message length: the length of the message.
message: control message or data message
securityLevel:As defined by IEEE802.15.4e std.
2.4.10.2. Receive.data
The command is invoked whenever a packet is received and inserted
into a reception queue. The method acts as a callback function to
notify to the upper layers the received message. Upper layers MUST
provide an implementation for that method.
The function has the following parameters:
src address: L2 source address
dest address: L2 unicast or broadcast destination address
priority: packet priority, usually is consistent with queue
priority
message length: the length of the message.
message: control message or data message
2.4.10.3. Data Command Behavior
The following table describes the behavior of 6tus upon reception of
the Data Communication Configuration management commands.
Wang, et al. Expires November 24, 2013 [Page 28]
Internet-Draft 6tsch-6tus May 2013
Data Communication Management Operations behavior
+---------------------------------+---------------------------------+
| 6tus commands | 6tus behavior |
+---------------------------------+---------------------------------+
| Send.data(src,dest,prio, | The message is inserted in the |
| len,msg,seclevel) | the queue corresponding to the |
| | required priority. Fails if the |
| | queue is full. Fails if the |
| | destination address is not a |
| | L2 neighbor of the node. |
+---------------------------------+---------------------------------+
| Receive.data(src,dest,prio,len, | The method is invoked whenever a|
| msg) | message is inserted in the queue|
| | after successful reception. |
+---------------------------------+---------------------------------+
Figure 4
2.5. Message Formats
6tus has to negotiate the scheduling of soft cells with neighbor
nodes. This negotiation happens through 6tus-specific TSCH
Information Elements, the format of which is defined in this section.
This section also details the formats of the IEs defined in
[IEEE802154e] and reused without modification.
6tus messages can contain one or more IEs. Section 2.5.1 defines the
different IEs used by 6tus, both the ones used without modification
from [IEEE802154e], and the new ones defined by 6tus. Section 2.5.2
shows how those IEs are assembled to form the different packets used
by 6tus.
2.5.1. Information Elements
IEEE802.15.4e defines Information elements (IEs) which are formatted
data objects consisting of an ID, a length, and a data payload used
to pass data between layers or devices. IEEE802.15.4e defines Header
IEs and Payload IEs; 6tus only uses Payload IEs. A Payload IE
includes one or more IEs, and ends with a termination IE (ID = 0xf,
see [IEEE802154e]).
6tus uses the following Information Elements, in which the first four
IEs are defined in IEEE802.15.4e, and other three IEs are introduced
in this document.
Defined in [IEEE802154e] and used by 6tus without modification:
Wang, et al. Expires November 24, 2013 [Page 29]
Internet-Draft 6tsch-6tus May 2013
TSCH Synchronization IE (Section 2.5.1.1)
TSCH Slotframe and Cell IE (Section 2.5.1.2)
TSCH Timeslot Template IE (Section 2.5.1.3)
TSCH Channel Hopping IE (Section 2.5.1.4)
Defined by 6tus:
6tus Opcode IE (Section 2.5.1.5)
6tus Bandwidth IE (Section 2.5.1.6)
6tus Generic Schedule IE (Section 2.5.1.7)
2.5.1.1. TSCH Synchronization IE
A Synchronization IE (SyncIE) contains Information allowing a node to
synchronize to a TSCH network, including the current ASN and a join
priority. Synchronization IE must be included in all TSCH Enhanced
Beacons.
6tus re-uses this IE as defined in [IEEE802154e].
Format of a TSCH Synchronization IE (SyncIE).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | SubID |T| ASN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASN | Join Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5
Length=6
SubID=0x1a
T=0, i.e. short type
ASN (5 octets) contains the Absolute Slot Number corresponding to the
timeslot in which the TSCH Enhanced Beacon is sent.
Wang, et al. Expires November 24, 2013 [Page 30]
Internet-Draft 6tsch-6tus May 2013
The Join Priority can be used by a joining device to select among
beaconing devices when multiple beacons are heard. The PAN
coordinator's join priority is zero. A lower value of join priority
indicates that the device is the preferred one to connect to. The
beaconing device's join priority is the lowest join priority heard
when it joined the network plus one.
2.5.1.2. TSCH Slotframe and Cell IE
The Slotframe and Cell IE (FrameAndCellIE) contains one or more
slotframes and their respective cells that a beaconing device
advertises to allow other devices to join the network.
6tus re-uses this IE as defined in [IEEE802154e].
Format of a TSCH Slotframe and Cell IE (FrameAndCellIE).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | SubID |T| NumFrame | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
// Slotframe and cell information //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6
Length=variable
SubID=0x1b
T=0, i.e. short type
NumFrame is set to the total number of slotframe descriptors
contained in the TSCH Enhanced Beacon.
Wang, et al. Expires November 24, 2013 [Page 31]
Internet-Draft 6tsch-6tus May 2013
Format of a slotframe descriptor.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FrameID | FrameLen | NumCell |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Cell information for each cell (5x NumCell) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7
FrameID field shall be set to the slotframeHandle that uniquely
identifies the slotframe.
FrameLen field shall be set to the size of the slotframe in number of
timeslots.
NumCell field shall be set to the number of cells that belong to the
specific slotframe identified by the slotframeHandle.
Format of a Cell information.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SlotOffset | ChannelOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LinkOption |
+-+-+-+-+-+-+-+-+
Figure 8
SlotOffset shall be set to the timeslot of this cell.
ChannelOffset shall be set to the logic channel of this cell.
LinkOption indicates whether this cell is a TX cell, an RX cell, or a
SHARED TX cell, whether the device to which it is being linked is to
be used for clock synchronization, and whether this cell is hard
cell.
2.5.1.3. TSCH Timeslot Template IE
Timeslot Template IE (SlotTemplateIE) defines Timeslot template being
used by the TSCH device.
6tus re-uses this IE as defined in [IEEE802154e].
Wang, et al. Expires November 24, 2013 [Page 32]
Internet-Draft 6tsch-6tus May 2013
Format of a TSCH Timeslot Template IE (SlotTemplateIE).
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | SubID |T| TemplateID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9
Length=1
SubID=0x1c
T=0, i.e. short type
TemplateID shall be set to a Timeslot template handle. The full
time-slot template, which contains the macTimeslotTemplate of TSCH
(total 25 octets), may be included.(see IEEE802.15.4e).
2.5.1.4. TSCH Channel Hopping IE
Channel Hopping IE (ChHoppingIE) defines the Hopping Sequence being
used by the TSCH device.
6tus re-uses this IE as defined in [IEEE802154e].
Format of a TSCH Channel Hopping IE (ChHoppingIE).
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | SubID |T| HopSequenceID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10
Length=1
SubID=0x09
T=1, i.e. long type
HopSequenceID shall be set to a Hopping Sequence handle. The full
Hopping Sequence information may be included. (see IEEE802.15.4e).
2.5.1.5. 6tus Opcode IE
6tus Opcode IE (OpcodeIE) defines operation codes of packets in 6tus
layer.
Wang, et al. Expires November 24, 2013 [Page 33]
Internet-Draft 6tsch-6tus May 2013
This IE is not present in [IEEE802154e] and is defined by 6tus.
Format of a 6tus Opcode IE (OpcodeIE).
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | SubID |T| OpcodeID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11
Length=1
SubID=0x41
T=0, i.e. short type
OpcodeID field shall be set to one of the following codes.
0x00: Reserve Soft Cell Request
0x01: Reserve Soft Cell Response
0x02: Remove Soft Cell Request
0x03: Reserve Hard Cell Request
0x04: Remove Hard Cell Request
2.5.1.6. 6tus Bandwidth IE
Bandwidth IE (BwIE) defines the number of cells to be reserved or
actually be reserved.
This IE is not present in [IEEE802154e] and is defined by 6tus.
Format of a 6tus Bandwidth IE (BwIE).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | SubID |T| FrameID | NumCell |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12
Length=2
SubID=0x42
Wang, et al. Expires November 24, 2013 [Page 34]
Internet-Draft 6tsch-6tus May 2013
T=0, i.e. short type
FrameID field may be set to the SlotFrameHandle to identify the
slotframe from which cells are reserved. FrameID field may be set to
NOP, which means no specific slotframe is associated.
NumCell field shall be set to the number of cells. When BwIE is
combined with the OpecodeID of Reserve Soft Cell Request, NumCell
presents how many cells are required to reserve; and when BwIE is
combined with the OpecodeID of Reserve Soft Cell Response, NumCell
presents how many cells are reserved successfully.
2.5.1.7. 6tus Generic Schedule IE
Generic Schedule IE (ScheduleIE) describes cell sets. In different
packet, ScheduleIE represents different information. See
Section 2.5.2 for more detail.
This IE is not present in [IEEE802154e] and is defined by 6tus.
Format of a 6tus Generic Schedule IE (ScheduleIE).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | SubID |T| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
// Schedule Body //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13
Length=variable
SubID=0x43
T=0, i.e. short type
Schedule Body carries one or more schedule object. An object may
carry a TLV, which may itself comprise other TLVs. TLV format is as
follows. Type: 1 byte, Length: 1 byte, Value: variable
The following are some examples of schedule object TLV.
Example 1. Cell Set TLV
Wang, et al. Expires November 24, 2013 [Page 35]
Internet-Draft 6tsch-6tus May 2013
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=1 | Length | FrameID | NumCell |F|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// CellObjects //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14
FrameID shall be set to the slotframeHandle that uniquely identifies
the slotframe.
NumCell shall be set to the number of cells that belong to the
specific slotframe identified by the slotframeHandle.
F=1 means the specified cells equals to what are listed in
CellObjects, and F=0 means the specified cells equals to what are not
listed in CellObjects.
CellObjects carries the information for one or more cells, including
SlotOffset, ChannelOffset, LinkOption (Figure 8).
Example 2. Schedule Matrix TLV
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=2 | Length | FrameID |StartSlotOffset|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|StartSLotOffset| NumSlot | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
// SlotBitMap (2x NumSlot) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15
FrameID field shall be set to the slotframeHandle that uniquely
identifies the slotframe.
StartSlotOffset field (2 octets) shall be set to the slotoffset in
the specific slotframe identified by the slotframeHandle.
NumSlot field shall be set to the number of slots from
StartSlotOffset in the specific slotframe identified by the
slotframeHandle.
Wang, et al. Expires November 24, 2013 [Page 36]
Internet-Draft 6tsch-6tus May 2013
SlotBitMap (per slot) indicates for the given slot which channels are
specified. For the 16 channels in 2.4GHz band, 2-octets are used to
indicate which channel is specified. For example, given a slot and a
SlotBitmap with value (10001000,00010000); the bitmap represents that
ChannelOffset-0, ChannelOffset-4, ChannelOffset-11 are specified.
2.5.2. Packet Formats
This section describes the packets used in 6tus to form a network,
reserve/maintain bandwidth using soft cells, and reserve/remove hard
cells in both Tx side and Rx side. Each of these packets use one or
more IEs defined in Section 2.5.1.
2.5.2.1. TSCH Enhanced Beacon
The TSCH Enhanced Beacon is used to announce the presence of the
network and allow new nodes to join. It is and IEEE802.15.4e
Enhanced Beacon packet with the following Payload IEs:
TSCH Synchronization IE (Section 2.5.1.1)
TSCH Timeslot Template IE (Section 2.5.1.3)
TSCH Channel Hopping IE (Section 2.5.1.4)
TSCH Slotframe and Cell IE (Section 2.5.1.2)
Payload IE of TSCH Enhanced Beacon Packet
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |GroupID|T| SyncIE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SyncIE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SyncIE | SlotTemplateIE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SlotTemplateIE | ChHoppingIE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// FrameAndCellIE //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16
Length=variable
Wang, et al. Expires November 24, 2013 [Page 37]
Internet-Draft 6tsch-6tus May 2013
GroupID=0x1, i.e. MLME IE
T=1, i.e. payload IE
See Section 2.5.1.1, Section 2.5.1.3, Section 2.5.1.4,Section 2.5.1.2
for SyncIE, SlotTemplateIE, ChHoppingIE and FrameAndCellIE.
2.5.2.2. Soft Cell Reservation Request
Soft Cell Reservation Request packet is formatted in Data packet of
IEEE802.15.4e with following payload IE.
Payload IE of Soft Cell Reservation Request
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |GroupID|T| OpcodeIE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpcodeIE | BwIE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BwIE | |
+-+-+-+-+-+-+-+-+ |
// ScheduleIE //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17
Length=variable
GroupID=0x1, i.e. MLME IE
T=1, i.e. payload IE
The OpcodeID field in the 3-octet OpcodeIE should be set to 0x00,
indicates Reserve Soft Cell Request operation.
The NumCell field in 4-octet BwIE should be set to the number of
cells needed to be reserved.
The ScheduleIE specifies a candidate cell set, from which the cells
should be reserved. ScheduleIE may be empty, means there is no
constrain on which cells should not be reserved.
2.5.2.3. Soft Cell Reservation Response
Soft Cell Reservation Response is formatted in Data packet of
IEEE802.15.4e with following payload IE.
Wang, et al. Expires November 24, 2013 [Page 38]
Internet-Draft 6tsch-6tus May 2013
Payload IE of Soft Cell Reservation Response
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |GroupID|T| OpcodeIE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpcodeIE | BwIE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BwIE | |
+-+-+-+-+-+-+-+-+ |
// ScheduleIE //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18
Length=variable
GroupID=0x1, i.e. MLME IE
T=1, i.e. payload IE
The OpcodeID field in the 3-octet OpcodeIE should be set to 0x01,
indicates Reserve Soft Cell Response operation.
The NumCell field in 4-octet BwIE should be set to the number of
cells which have been reserved successfully.
The ScheduleIE should specify all of the cells which have been
reserved successfully.
2.5.2.4. Soft Cell Remove Request
Soft Cell Remove Request is formatted in a Data packet of
IEEE802.15.4e with the following payload IE.
Wang, et al. Expires November 24, 2013 [Page 39]
Internet-Draft 6tsch-6tus May 2013
Payload IE of Soft Cell Remove Request
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |GroupID|T| OpcodeIE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpcodeIE | |
+-+-+-+-+-+-+-+-+ |
// ScheduleIE //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19
Length=variable
GroupID=0x1, i.e. MLME IE
T=1, i.e. payload IE
The OpcodeID field in the 3-octet OpcodeIE should be set to 0x02,
indicates Remove Soft Cell Request operation.
The ScheduleIE should specify all the cells that need to be removed.
2.5.2.5. Hard Cell Reservation Request
Hard Cell Reservation Request packet is formatted in Data packet of
IEEE802.15.4e with following payload IE.
Payload IE of Hard Cell Reservation Request
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |GroupID|T| OpcodeIE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpcodeIE | |
+-+-+-+-+-+-+-+-+ |
// ScheduleIE //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20
Length=variable
GroupID=0x1, i.e. MLME IE
Wang, et al. Expires November 24, 2013 [Page 40]
Internet-Draft 6tsch-6tus May 2013
T=1, i.e. payload IE
The OpcodeID field in the 3-octet OpcodeIE should be set to 0x03,
indicates Reserve Hard Cell Request operation.
The ScheduleIE should specify all the cell that need to be reserved.
2.5.2.6. Hard Cell Remove Request
Hard Cell Remove Request is formatted in a Data packet of
IEEE802.15.4e with the following payload IE.
Payload IE of Hard Cell Remove Request
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |GroupID|T| OpcodeIE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpcodeIE | |
+-+-+-+-+-+-+-+-+ |
// ScheduleIE //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21
Length=variable
GroupID=0x1, i.e. MLME IE
T=1, i.e. payload IE
The OpcodeID field in the 3-octet OpcodeIE should be set to 0x04,
indicates Remove Hard Cell Request operation.
The ScheduleIE should specify all the cells that need to be removed.
2.6. Time Sequence
6tus neighbors exchange 6tus-specific packets in the following cases,
each detailed in a subsection.
Network formation is detailed in Section 2.6.1.
Creating soft cells is detailed in Section 2.6.2.
Deleting soft cells is detailed in Section 2.6.3.
Wang, et al. Expires November 24, 2013 [Page 41]
Internet-Draft 6tsch-6tus May 2013
Maintaining soft cells is detailed in Section 2.6.4.
Creating hard cells is detailed in Section 2.6.5.
Deleting hard cells is detailed in Section 2.6.6.
2.6.1. Network Formation
Network formation consists of two processes: joining and maintenance.
2.6.1.1. Joining
A node already in the network sends out TSCH Enhanced Beacons
periodically.
When a node is joining an existing network, it listens for TSCH
Enhanced Beacons. After collecting one or more TSCH Enhanced BEACONs
(the format of which is detailed in Section 2.5.2.1), the joining
node must do the following.
Initialize a neighbor table. Establish a neighbor table and
record all of the information described in the TSCH Enhanced
BEACONs as its initial schedule with those neighbors.
Select a time source neighbor. According to the Joining Priority
described by SyncIEs, the joining node chooses one or more of the
advertisers as its time source neighbors. 6tus does not specify
the criteria to choose time source neighbors from the Enhanced
BEACONs.
Select cells for Enhanced Beacons. The joining node selects one
or more cells to broadcast its own Enhanced Beacons, which may be
same as the cells used by its neighbors for Enhanced Beacon
broadcast, and record those cell(s) into the TSCH schedule with
LinkType=ADVERTISING.
From its Enhanced Beacons, including the cell(s) for its Enhanced
Beacon, which LinkOption should be set to "Receive" and
"Timekeeping", telling its neighbors that the cell is used for
broadcast.
Start broadcasting Enhanced Beacon and communicate with neighbors.
Wang, et al. Expires November 24, 2013 [Page 42]
Internet-Draft 6tsch-6tus May 2013
2.6.1.2. Maintenance
Nodes may broadcast Enhance Beacons on the cells marked with
LinkType=ADVERTISING, and listen for Enhanced Beacons from neighbors
on the cells with LinkOption = "Receive" and "Timekeeping". If a
cell with both LinkType=ADVERTISING has both the "Receive" and
"Timekeeping" LinkOption, it is shared by neighbors and itself to
broadcast, then broadcast Enhanced Beacon has higher priority.
Whenever a node receives an Enhanced Beacon, it must update its
schedule if there is a difference.
2.6.2. Creating soft cells
The upper layer instructs 6tus to schedule one or more soft cells by
calling the Create soft cell command. This command can also be
called by the monitoring process internal to 6tus.
When receiving a Create soft cell command, Node A's 6tus layer forms
a Soft Cell Reservation Request packet which includes BwIE and
ScheduleIE. The BwIE includes the number of cells needed to be
reserved (N1), and ScheduleIE includes a candidate cell set from
which the new cells should be selected. If the ScheduleIE is empty,
Node A indicates there is no constraint on cell selection. The Soft
Cell Reservation Request is then sent to the neighbor (Node B) with
whom new cells need to be added. After receiving the Soft Cell
Reservation Request, Node B selects the cells from the candidate cell
set defined by the ScheludeIE in the Soft Cell Reservation Request,
and forms a Soft Cell Reservation Response packet, in which BwIE
indicates the number of cells actually being reserved (N2), and
ScheduleIE indicates those reserved cells. If N2 is smaller than N1,
node B indicates to node A that there are not enough qualified cells
to be reserved. Node B must record the reserved cells into its local
schedule while sending out Soft Cell Reservation Response. After
receiving the Soft Cell Reservation Response, Node A must record the
reserved cells into its local schedule.
The policy to build a candidate cell set and the policy to select
cells from the candidate cell set to reserve is flexiable. For
example, the candidate cell set can be all of the cells not used by
Node A, and Node B can randomly choose N1 cells, which are not used
by Node B, from the candidate cell set.
The expression of Schedule Body is flexible. For example, Node A can
use Cell Set TLV defined in Figure 14 with field 'F' set to '0', and
the CellObjects includes all of the cells being used by Node A. In
another word, the cell candidate set is all of the cells not being
included in the list defined by CellObjects.
Wang, et al. Expires November 24, 2013 [Page 43]
Internet-Draft 6tsch-6tus May 2013
The policy to deal with the failure or not fully satisfaction in a
soft cell Reservation process is flexible. For example, Node A may
initiate another soft cell reservation procedure, or simply report to
upper layer.
2.6.3. Deleting soft cells
The upper layer instructs 6tus to delete one or more soft cells by
calling the Delete soft cell command. This command can also be
called by the monitoring process internal to 6tus.
When receiving a Delete soft cell command, Node A's 6tus layer
selects cells to be removed from its local schedule, and creates a
Soft Cell Remove Request, including a ScheduleIE. The ScheduleIE
indicates which specific cells to remove with a neighbor (Node B).
The cells specified in the ScheduleIE should be removed from local
schedule of Node A while the Soft Cell Remove Request is sent to Node
B. When receiving the Soft Cell Remove Request, the cells specified
in the ScheduleIE should be removed from the local schedule of Node
B.
The policy to select cells corresponding to a Delete soft cell
command is out of scope.
2.6.4. Maintaining soft cells
The monitoring process internal to 6tus (Section 2.8) is responsible
for monitoring and re-scheduling soft cells to meet some QoS
requirements. The monitoring process may issue a soft cell
Maintenance command, which indicate a set of cells to be moved in the
TSCH schedule.
When a receiving a soft cell Maintenance command, 6tus initializes a
Soft Cell Remove Request (Section 2.6.3) with the neighbor in
question, followed by a Soft Cell Reservation Request
(Section 2.6.2).
2.6.5. Creating hard cells
The upper layer instructs 6tus to create one or more hard cells by
calling the Create hard cell command.
When receiving a Create hard cell command, Node A's 6tus layer
creates a Hard Cell Reservation Request, including a ScheduleIE. The
ScheduleIE indicates which specific cells with a neighbor (Node B) to
be added. The cells specified in the ScheduleIE should be added in
local schedule of Node A while the Hard Cell Reserve Request is sent
to Node B. When receiving the Hard Cell Reserve Request, the cells
Wang, et al. Expires November 24, 2013 [Page 44]
Internet-Draft 6tsch-6tus May 2013
specified in the ScheduleIE should be added in the local schedule of
Node B.
2.6.6. Deleting hard cells
The upper layer instructs 6tus to delete one or more hard cells by
calling the Delete hard cell command.
When receiving a Delete hard cell command, Node A's 6tus layer
creates a Hard Cell Remove Request, including a ScheduleIE. The
ScheduleIE indicates which specific cells with a neighbor (Node B) to
be removed. The cells specified in the ScheduleIE should be removed
from local schedule of Node A while the Hard Cell Remove Request is
sent to Node B. When receiving the Hard Cell Remove Request, the
cells specified in the ScheduleIE should be removed from the local
schedule of Node B.
2.7. Statistics
The 6tus Statistics Fuction (SF) is responsible for collecting
statistics, which it can provide to an upper layer and the Monitoring
Function (Section 2.8).
2.7.1. Statistics Metrics
6tus is in charge of keeping statistics from a set of metrics
gathered from the behavior of the TSCH layer.
The statistics data related to node states and cell metrics should be
provided to upper layer for management, e.g. for RPL to calculate
Rank or to GMPLS to determine whether the link in a multi-hop path is
meeting the required bandwidth. The specific algorithm to generate
the statistics is implementation dependent and hence out of the scope
of this document. However, the statistics component should include
the following metrics:
1. LinkThroughput: associated with a link, Node A->Node B. For
example, LinkThroughput can be calculated with:
SUM(NumOfCell(i)*NumOfBytePerPacket)/(FrameLen(i)*SlotDuration)
where NumOfCell(i) is the total number of cells from Node A to
Node B in Slotframe-i, FrameLen(i) is the length of Slotframe-i.
Wang, et al. Expires November 24, 2013 [Page 45]
Internet-Draft 6tsch-6tus May 2013
2. Latency: associated with a link, Node A->Node B. For example,
latency can be expressed as Minimum and Maximum Latency. Minimum
Latency = Min(MinNumOfSlot(i),i=1..) * SlotDuration and Maximum
Latency = Max(MaxNumOfSlot(i),i=1..) * SlotDuration where,
MinNumOfSlot(i) and MaxNumOfSlot(i) are the minimum or maximum
number of slots between two dedicated cells from Node A to Node B
in Slotframe-i, respectively.
3. LinkQuality. For example, average LQI, ETX;
4. TafficLoad. For example, Queue Full Rate, Queue Empty Rate;
5. NodeEnergy. For example, E_E=E_bat / [E_0 (T-t)/T].
2.7.2. Statistics Configuration
Statistics Function should be configurable. The configuration
parameters should include:
LinkQualityStatisticsEn.
TafficLoadStatisticsEn.
DeviceStatisticsEn.
6tus statistics function is enabled/disabled and configured by the
commands defined in Section 2.4.4
2.8. Monitoring
Monitoring Fuction (MF) in 6tus is responsible for monitoring cell
quality, traffic load, and issuing soft cell Maintenance command, or
Create/Delete soft cell command. The data provided by Statistics
Function may be used as a input of MF in making monitoring decision.
2.8.1. Monitor Configuration
Monitoring Function should be configurable. The configuration
parameters should include:
MaintainCellEn.
CreateDeleteCellEn.
QosLevel. QosLevel should associate with specific neighbor
address. QosLevel may reflect the latency constraint, cell
quality constraint, and so on. The value of QosLevel works as the
bandwidth redundancy coefficient.
Wang, et al. Expires November 24, 2013 [Page 46]
Internet-Draft 6tsch-6tus May 2013
6tus monitoring function is enabled/disabled and configured by the
commands defined in Section 2.4.3
2.8.2. Actuation
The cell quality statistics may be used to generate soft cell
Maintenance command, which leads to a soft cell Maintenance procedure
(see Section 2.6.4). The traffic load statistics may be used to
generate internal Create/Delete soft cell commands, which leads to a
soft cell Reservation process or a soft cell Remove process,
respectively. (see Section 2.6.2 and Section 2.6.3)
The policy to generate the soft cell Maintenance command and the
policy to generate Create/Delete soft cell commands is out of the
scope.
The policy to generate Create/Delete soft cell commands may take
QosLevel into account. For example, there are two slotframes
existing, Slotframe-1 consists of 32 slots, Slotframe-2 consists of
96 slots; Slot duration is 10ms; QosLevel=1.5. If, from the traffic
load statistics, MF figures out 2 packet/second should be added, then
it leads to a Create soft cell command, where FrameID=2, NumCell=3.
3. Using 6tus
This part describes how 6tus gives support to specific upper layers.
3.1. RPL on 6tus
6tus provides a set of functionalities so higher layers can obtain
information about the status of the network and take advantage of the
slotted structure to improve metric calculation and objective
function optimization. The following sections describe how RPL can
make use of 6tus layer.
In order to optimize the combination of RPL and TSCH, 6tus provides
specific support to RPL in the following aspects:
RPL Neighbor Discovery and Parent Selection
RPL Rank Computation
RPL Control Messages Broadcast
QoS
3.1.1. Support to Neighbor Discovery and Parent Selection
Wang, et al. Expires November 24, 2013 [Page 47]
Internet-Draft 6tsch-6tus May 2013
The Section 2.4.7 defines a set of commands so the neighbor table can
be managed and queried by RPL. An entry to the neighbor table is
inserted whenever an EBs is received at L2. The EB causes the 6tus
layer to create an entry to the neighbors table. A neighbor table
entry contains a set of statistics with respect to that specific
neighbor such as the ASN when the last packet has been received from
that neighbor, a set of cell quality metrics (RSSI, LQI), number of
packets sent to it or number of packets received from it amongst
others. 6tus updates that table upon sending or reception of a
packet from/to a neighbor. RPL can query at any time the neighbor
table to retrieve information about a particular neighbor. This
information can be used to compute the routing objective function as
for example the inverse of the Probability Delivery Ratio (PDR).
Parent selection can also be driven by the information contained on
the neighbor table as well as complemented with the cells statistics
defined in Section 2.4.4 and Section 2.7.
6tus enables RPL to configure EB periodicity. By controlling the EBs
periodicity, RPL can configure how network dynamism and support to
mobility are addressed, as more frequent beacons the more prone to
cope with mobility. Section 2.4.5 enables to configure how the
network is formed and EBs periodicity.
RPL may want to select the policy to determine the time source
neighbor, this can be interesting when time source neighbors can be
aligned to the routing topology, i.e, the selected time source
neighbor can be the node's favorite parent in a specific DODAG.
Section 2.4.6 describes the 6tus command to setup the desired policy.
The policy is selected by RPL and enforced by 6tus layer.
The rule for 6tus to select and maintain time sources is as follows.
Time source of one node should be one member of the node's
neighbor set.
Time sources should be the neighbors which have relatively lower
Join Priority in the neighbor set. Lower Join Priority means
closer to TSCH Pan coordinator.
The link from a node to its time sources should be in a good link
quality.
3.1.2. Support to Rank Computation
RPL objective function is computed by a set of metrics. The specific
metrics and how the objective function is calculated are out of the
scope of the present document, however, 6tus builds a set of
functionalities to provide more accurate statistics of the underlying
Wang, et al. Expires November 24, 2013 [Page 48]
Internet-Draft 6tsch-6tus May 2013
layer so the objective function can be accommodated to the nature of
a TSCH MAC layer.
6tus provides Statistics for Rank computation as described in
sections(Section 2.4.4 and Section 2.7). The function to compute the
Rank based on those statistics is out of scope of 6tus, however the
provided metrics are aligned to the behavior of the TSCH MAC layer.
3.1.3. Support to Control Messages Broadcast
In RPL, some control messages, e.g. DIO, and DAO in sorting mode,
need to be broadcasted to the neighbors. The broadcast channel
requirement has to be addressed by 6tus by configuring TSCH to
provide such a channel.
In order to decouple the upper (RPL) layer to TSCH, instead of
carrying DIO message in the Enhance Beacon, 6tus introduces a
mechanism to establish broadcast cells.
In TSCH schedule, every cell has the LinkType attribute. If
LinkType=ADVERTISING, indicates that the cell may be used to send an
Enhanced Beacon. When a node forms its Enhanced Beacon, the cell,
with LinkType=ADVERTISING, should be included in the FrameAndCellIE,
and its LinkOption field should be set to the combination of
"Receive" and "Timekeeping". The receiver of the Enhanced Beacon may
listen to at the cell to get the Enhanced Beacon ([IEEE802154e]).
6tus takes this way to establish broadcast channel, which not only
allows TSCH broadcast Enhanced Beacon, but also allows an upper layer
like RPL broadcast.
To support DIO and DAO broadcast, 6tus uses the payload of a Data
Packet to carry the DIO or DAO. The message is inserted into the
queue associated with the cells which LinkType is set to ADVERTISING.
Then, taking advantage of the broadcast cell feature established with
FrameAndCellIE as described above, the data packet with DIO or DAO in
payload can be received by neighbors, which leads to the maintenance
of DODAG.
The LinkOption of combining "Receive" and "Timekeeping" let the
receivers of the Enhanced Beacon understand that the cell is used as
broadcast cell. But the frequency of sending Enhance Beacon or other
broadcast messages by upper layer is determined by the timers
associated with the messages, e.g. Enhance Beacon is triggered by
the timer in 6tus, and the DIO message is triggered by the trickle
timer of RPL. Therefore, for energy efficiency, receivers can have
some policy to wake up at the broadcast cell, but it is
implementation dependent.
Wang, et al. Expires November 24, 2013 [Page 49]
Internet-Draft 6tsch-6tus May 2013
3.1.4. Support to QoS
TSCH MAC layer is decoupled from the upper layers and its interaction
with them is asynchronous. This means that the MAC layer executes a
schedule and checks at each slot according to the type of cell
whether there is something to send or receive. If that is the case
the packet is sent and the MAC layer continues its operation. When
an upper layer sends a packet, this packet is pushed into a queue
waiting to the MAC layer to read it and sent it in a particular slot
according to is destination and priority (Section 2.3). 6tus
provides a set of queue management operations which enable upper
layers to create different queues and determine their priorities. In
that sense different classes of traffic can be handled by the routing
layer, i.e inserting a packet to a specific queue according to its
priority.
6tus provides at least a Broadcast Queue, a Transmit Queue, and a
Receive Queue. RPL can configure the queues with Internal Queueing
Command (Section 2.4.8.1). Broadcast Queue are associated with cells
with LinkType=ADVERTISING in sender's schedule, and
LinkOption="Receive" and "Timekeeping" in all neighbors' schedule.
That indicates the cells can be used for broadcast from the sender to
its neighbors. Transmit Queues are associated with the dedicated
Transmit cells or Shared Cells. RPL can benefit from having
different priority queues in order to improve latency or provide
integrated services with different priorities, i.e different traffic
classes.
Data Communication Command (Section 2.4.10) can be used to send
control messages and data messages. The operation is used to insert
a message to an specific queue.
For example a suitable configuration can include two Broadcast Queues
with priority High and Low, respectively; three Transmit Queues, with
priority High, Mid, and Low, respectively; and one Receive Queue.
When DestAddr is a broadcast address, its related MAC layer packets
will be pushed into the Broadcast Queue with the corresponding
priority. 6tus is responsible for feeding these packets to TSCH at
broadcast cells.
When DestAddr is unicast address, its related MAC layer packets will
be push into the Transmit Queue with corresponding priority. 6tus is
responsible for feeding these packets to TSCH at Transmit cells or
Shared Cells.
6tus conducts a QoS policy, which is out of scope. Here is an
example. Packets in higher priority queue MUST be sent out before
Wang, et al. Expires November 24, 2013 [Page 50]
Internet-Draft 6tsch-6tus May 2013
the packets in lower priority queue. Then, when there is an
available broadcast/unicast cell, 6tus checks the broadcast/unicast
queue with higher priority first, if there is a packet, then feed it
to TSCH at the cell, otherwise checks broadcast/unicast queue with
lower priority further. Repeat the process, until find a broadcast/
unicast packet to feed to TSCH or find all of broadcast/unicast
queues are empty.
3.2. GMPLS on 6tus
GMPLS is a 2.5 layer service that is used to forward packets based on
the concept of generalized label. Labels are determined by a
reservation protocol during the formation of a multi-hop path. As
defined by [RFC3471],[RFC3473] and [RFC4606] a generalized label
identifies a flow of data through a set of nodes that conform to a
multi-hop path. Instead of being appended to each packet as is the
case in MPLS [RFC3031], the generalized label it is kept at each node
in the form of a table. The table can be used to map input cells to
output cells so routing decisions can be taken at that layer.
In order to optimize the combination of GMPLS and TSCH, 6tus provides
specific support to GMPLS in the following aspects:
Cell Reservation Support
QoS
3.2.1. Cell Reservation Support for GMPLS on 6tus
The GMPLS control plane is used to send path reservation requests and
reservation confirmations. When reservation confirmations are
received, GMPLS needs to configure the underlying MAC layer to
provide the required bandwidth. 6tus provides a set of commands to
deal with bandwidth allocation, i.e. cell allocation. Section 2.4.1
describes the operations that GMPLS layer may use for cell
configuration. Note that 6tus supports different types of
reservations: soft cell and hard cell. How the reservation
requirements are expressed is out of scope of this document, but 6tus
is able to handle a reservation done as a specific bandwidth
requirement, done through specifying exact cells.
GMPLS can also give different priorities to its control plane and
data plane. It can for example be interesting to have a higher
priority for control messages so the network adapts to new bandwidth
requirements quickly. In contrast, data plane messages can be given
a higher priority when they need to meet higher throughput or lower
latency. 6tus provides commands (Section 2.4.8) to manage MAC layer
queues and assign different priorities to them.
Wang, et al. Expires November 24, 2013 [Page 51]
Internet-Draft 6tsch-6tus May 2013
3.2.2. Supporting QoS
GMPLS can use 6tus statistics to determine whether some QoS
requirement is met. Metrics defined in Section 2.7 and operations
defined in Section 2.4.4.4 can be used by GMPLS to trigger new
bandwidth allocation, or to map different input bundles to output
bundles.
4. References
4.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
4.2. Informative References
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
Wood, "Advice for Internet Subnetwork Designers", BCP 89,
RFC 3819, July 2004.
[RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi-
Protocol Label Switching (GMPLS) Extensions for
Synchronous Optical Network (SONET) and Synchronous
Digital Hierarchy (SDH) Control", RFC 4606, August 2006.
Wang, et al. Expires November 24, 2013 [Page 52]
Internet-Draft 6tsch-6tus May 2013
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals", RFC
4919, August 2007.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007.
[RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel,
"Routing Requirements for Urban Low-Power and Lossy
Networks", RFC 5548, May 2009.
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation
Routing Requirements in Low-Power and Lossy Networks", RFC
5826, April 2010.
[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
"Building Automation Routing Requirements in Low-Power and
Lossy Networks", RFC 5867, June 2010.
[RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney,
"Industrial Routing Requirements in Low-Power and Lossy
Networks", RFC 5673, October 2009.
[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
September 2011.
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
Lossy Networks", RFC 6550, March 2012.
[RFC6568] Kim, E., Kaspar, D., and JP. Vasseur, "Design and
Application Spaces for IPv6 over Low-Power Wireless
Personal Area Networks (6LoWPANs)", RFC 6568, April 2012.
[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
Statement and Requirements for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Routing", RFC
6606, May 2012.
[RFC6755] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace
for OAuth", RFC 6755, October 2012.
[I-D.thubert-roll-forwarding-frags]
Wang, et al. Expires November 24, 2013 [Page 53]
Internet-Draft 6tsch-6tus May 2013
Thubert, P. and J. Hui, "LLN Fragment Forwarding and
Recovery", draft-thubert-roll-forwarding-frags-01 (work in
progress), February 2013.
[I-D.tsao-roll-security-framework]
Tsao, T., Alexander, R., Daza, V., and A. Lozano, "A
Security Framework for Routing over Low Power and Lossy
Networks", draft-tsao-roll-security-framework-02 (work in
progress), March 2010.
[I-D.thubert-roll-asymlink]
Thubert, P., "RPL adaptation for asymmetrical links",
draft-thubert-roll-asymlink-02 (work in progress),
December 2011.
[I-D.ietf-roll-terminology]
Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-12 (work in
progress), March 2013.
[I-D.ietf-roll-p2p-rpl]
Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J.
Martocci, "Reactive Discovery of Point-to-Point Routes in
Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-17
(work in progress), March 2013.
[I-D.ietf-roll-trickle-mcast]
Hui, J. and R. Kelsey, "Multicast Protocol for Low power
and Lossy Networks (MPL)", draft-ietf-roll-trickle-
mcast-04 (work in progress), February 2013.
[I-D.thubert-6lowpan-backbone-router]
Thubert, P., "6LoWPAN Backbone Router", draft-thubert-
6lowpan-backbone-router-03 (work in progress), February
2013.
[I-D.sarikaya-core-sbootstrapping]
Sarikaya, B., Ohba, Y., Moskowitz, R., Cao, Z., and R.
Cragie, "Security Bootstrapping Solution for Resource-
Constrained Devices", draft-sarikaya-core-
sbootstrapping-04 (work in progress), April 2012.
[I-D.gilger-smart-object-security-workshop]
Gilger, J. and H. Tschofenig, "Report from the 'Smart
Object Security Workshop', 23rd March 2012, Paris,
France", draft-gilger-smart-object-security-workshop-00
(work in progress), October 2012.
Wang, et al. Expires November 24, 2013 [Page 54]
Internet-Draft 6tsch-6tus May 2013
[I-D.phinney-roll-rpl-industrial-applicability]
Phinney, T., Thubert, P., and R. Assimiti, "RPL
applicability in industrial networks", draft-phinney-roll-
rpl-industrial-applicability-02 (work in progress),
February 2013.
[I-D.ietf-core-coap]
Shelby, Z., Hartke, K., and C. Bormann, "Constrained
Application Protocol (CoAP)", draft-ietf-core-coap-16
(work in progress), May 2013.
[I-D.watteyne-6tsch-tsch-lln-context]
Watteyne, T., "Using IEEE802.15.4e TSCH in an LLN context:
Overview, Problem Statement and Goals", draft-watteyne-
6tsch-tsch-lln-context-01 (work in progress), February
2013.
[I-D.draft-palattella-6tsch-terminology]
Palattella, MR., Ed., Thubert, P., Watteyne, T., and Q.
Wang, "Terminology in IPv6 over Time Slotted Channel
Hopping. draft-palattella-6tsch-terminology-00 (work in
progress) ", March 2013.
[I-D.draft-thubert-6tsch-architecture]
Thubert, P., Ed., Assimiti, R., and T. Watteyne, "An
Architecture for IPv6 over Time Synchronized Channel
Hopping. draft-thubert-6tsch-architecture-00 (work in
progress) ", March 2013.
4.3. External Informative References
[IEEE802154e]
IEEE standard for Information Technology, "IEEE std.
802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area
Networks (LR-WPANs) Amendament 1: MAC sublayer", April
2012.
[IEEE802154]
IEEE standard for Information Technology, "IEEE std.
802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
and Physical Layer (PHY) Specifications for Low-Rate
Wireless Personal Area Networks", June 2011.
[OpenWSN] , "Berkeley's OpenWSN Project Homepage", ,
<http://www.openwsn.org/>.
Authors' Addresses
Wang, et al. Expires November 24, 2013 [Page 55]
Internet-Draft 6tsch-6tus May 2013
Qin Wang (editor)
Univ. of Sci. and Tech. Beijing
30 Xueyuan Road
Beijing, Hebei 100083
China
Phone: +86 (10) 6233 4781
Email: wangqin@ies.ustb.edu.cn
Xavier Vilajosana
Universitat Oberta de Catalunya
156 Rambla Poblenou
Barcelona, Catalonia 08018
Spain
Phone: +34 (646) 633 681
Email: xvilajosana@uoc.edu
Thomas Watteyne
Linear Technology
30695 Huntwood Avenue
Hayward, CA 94544
USA
Phone: +1 (510) 400-2978
Email: twatteyne@linear.com
Wang, et al. Expires November 24, 2013 [Page 56]