Internet DRAFT - draft-wang-6tisch-6top
draft-wang-6tisch-6top
6TiSCH Q. Wang, Ed.
Internet-Draft Univ. of Sci. and Tech. Beijing
Intended status: Informational X. Vilajosana
Expires: April 23, 2014 Universitat Oberta de Catalunya
T. Watteyne
Linear Technology
October 20, 2013
6TiSCH Operation Sublayer (6top)
draft-wang-6tisch-6top-00
Abstract
The recently published [IEEE802154e] standard formalizes the concept
of link-layer resources in LLNs. Nodes are synchronized and follow a
schedule. A cell 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. The [IEEE802154e]
standard does not, however, present a mechanism to do so, as building
and managing the schedule is out of scope of the standard. This
document describes the 6TiSCH Operation Sublayer (6top) and the
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 decentralized and centralized
scheduling. In addition, 6top can be configured to enable packet
switching at layer 2.5, analogous to GMPLS.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 23, 2014.
Wang, et al. Expires April 23, 2014 [Page 1]
Internet-Draft 6tisch-6top October 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. 6TiSCH Operation Sublayer (6top) . . . . . . . . . . . . . . 4
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Cell Model . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1. hard cells . . . . . . . . . . . . . . . . . . . . . 7
2.2.2. soft cells . . . . . . . . . . . . . . . . . . . . . 7
2.3. Data Convey Model . . . . . . . . . . . . . . . . . . . . 7
2.4. Commands . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.1. Cell Commands . . . . . . . . . . . . . . . . . . . . 11
2.4.2. Slotframe Commands . . . . . . . . . . . . . . . . . 14
2.4.3. Monitoring Commands . . . . . . . . . . . . . . . . . 15
2.4.4. Statistics Commands . . . . . . . . . . . . . . . . . 16
2.4.5. Network Formation Commands . . . . . . . . . . . . . 17
2.4.6. Time Source Neighbor Commands . . . . . . . . . . . . 19
2.4.7. Neighbor Commands . . . . . . . . . . . . . . . . . . 20
2.4.8. Queueing Commands . . . . . . . . . . . . . . . . . . 21
2.4.9. Security Commands . . . . . . . . . . . . . . . . . . 23
2.4.10. Data Commands . . . . . . . . . . . . . . . . . . . . 25
2.4.11. Label Switching Commands . . . . . . . . . . . . . . 26
2.5. Message Formats . . . . . . . . . . . . . . . . . . . . . 27
2.5.1. Information Elements . . . . . . . . . . . . . . . . 27
2.5.2. Packet Formats . . . . . . . . . . . . . . . . . . . 35
2.6. Time Sequence . . . . . . . . . . . . . . . . . . . . . . 40
2.6.1. Network Formation . . . . . . . . . . . . . . . . . . 40
2.6.2. Creating soft cells . . . . . . . . . . . . . . . . . 41
2.6.3. Deleting soft cells . . . . . . . . . . . . . . . . . 42
2.6.4. Maintaining soft cells . . . . . . . . . . . . . . . 42
2.6.5. Creating hard cells . . . . . . . . . . . . . . . . . 43
2.6.6. Deleting hard cells . . . . . . . . . . . . . . . . . 43
2.7. Statistics . . . . . . . . . . . . . . . . . . . . . . . 43
2.7.1. Statistics Metrics . . . . . . . . . . . . . . . . . 43
Wang, et al. Expires April 23, 2014 [Page 2]
Internet-Draft 6tisch-6top October 2013
2.7.2. Statistics Configuration . . . . . . . . . . . . . . 44
2.8. Monitoring . . . . . . . . . . . . . . . . . . . . . . . 44
2.8.1. Monitor Configuration . . . . . . . . . . . . . . . . 44
2.8.2. Actuation . . . . . . . . . . . . . . . . . . . . . . 45
2.9. Label Switching . . . . . . . . . . . . . . . . . . . . . 45
3. Using 6top . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.1. RPL on 6top . . . . . . . . . . . . . . . . . . . . . . . 46
3.1.1. Support to Neighbor Discovery and Parent Selection . 46
3.1.2. Support of Rank Computation . . . . . . . . . . . . . 47
3.1.3. Support of Control Messages Broadcast . . . . . . . . 47
3.1.4. Support for QoS . . . . . . . . . . . . . . . . . . . 48
3.2. GMPLS on 6top . . . . . . . . . . . . . . . . . . . . . . 49
3.2.1. Cell Reservation Support for GMPLS on 6top . . . . . 50
3.2.2. Supporting QoS . . . . . . . . . . . . . . . . . . . 50
4. References . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.1. Normative References . . . . . . . . . . . . . . . . . . 50
4.2. Informative References . . . . . . . . . . . . . . . . . 51
4.3. External Informative References . . . . . . . . . . . . . 54
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
mechanism 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 signalling 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 "6top".
This document describes the 6TiSCH Operation Sublayer (6top) 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 network layer can take routing decisions, TSCH configuration
and control procedures, and support for the different scheduling
mechanisms defined in [I-D.thubert-6tisch-architecture]. 6top
addresses the set of functionalities described in
[I-D.watteyne-6tsch-tsch-lln-context].
Wang, et al. Expires April 23, 2014 [Page 3]
Internet-Draft 6tisch-6top October 2013
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. 6top offers a set of commands so control mechanisms can
be introduced on top of TSCH to configure nodes to join a specific
node and obtain a unique 16-bit identifier from the network. Once a
network is formed, 6top 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 6top 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; 6top provides a set
of commands for upper layers to set up specific schedules, either
explicitly by detailing specific cell information, or by allowing
6top to establish a schedule given a bandwidth or latency
requirement. 6top is designed to enable decentralized, centralized or
hybrid scheduling solutions. 6top enables internal TSCH queuing
configuration, size of buffers, packet priorities, transmission
failure behavior, and defines mechanisms to encrypt and authenticate
MAC slotframes.
As described in [label-switching-154e], due to the slotted nature of
a TSCH network, it is possible to use a label switched architecture
on top of TSCH cells. As a cell belongs to a specific track, a label
header is not needed at each packet; the input cell (or bundle) and
the output cell (or bundle) uniquely identify the data flow. The
6top sublayer provides operations to manage the cell mappings.
2. 6TiSCH Operation Sublayer (6top)
2.1. Overview
6top is a sublayer which is the next-higher layer for TSCH (Figure
1), as detailed in [I-D.thubert-6tisch-architecture]. 6top 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.
Protocol Stack
Wang, et al. Expires April 23, 2014 [Page 4]
Internet-Draft 6tisch-6top October 2013
+-----------------------------------+
| PCEP | CoAP | | 6LoWPAN | |
| PCC | DTLS | PANA | ND |RPL |
+------------------------------------------+
| TCP | UDP | ICMP | RSVP |
+------------------------------------------+
| IPv6 |
+------------------------------------------+
| 6LoWPAN HC |
+------------------------------------------+
| 6top |
+------------------------------------------+
| IEEE802.15.4e TSCH |
+------------------------------------------+
| IEEE802.15.4 |
+------------------------------------------+
Figure 1
6top 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 6top a 6LoWPAN packet for transmission,
6top maps it to the appropriate outgoing priority-based queue, as
detailed in Section 2.3.
All commands of the management and data interfaces are detailed in
Section 2.4. This set of commands is designed to support
decentralized, centralized and hybrid scheduling solutions.
6top defines TSCH Information Elements (IEs) for neighbors nodes to
negotiate 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 6top gathers statistics (e.g., link quality,
energy level, queue usage), and what commands an upper layer can use
to configure and retrieve statistics.
6top can be configured to monitor the cells it has scheduled in order
to detect cells with poor performance. It can automatically re-
allocate those cells inside the TSCH schedule. This behavior is
described in Section 2.8
2.2. Cell Model
Wang, et al. Expires April 23, 2014 [Page 5]
Internet-Draft 6tisch-6top October 2013
[IEEE802154e] 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 MLME-SET-LINK.request
command defined in [IEEE802154e] 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, a back-off procedure is applied to handle
collisions. Shared behavior does not apply to Receive cells.
6top allows an upper layer to schedule a cell at a specific
slotOffset and channelOffset, in a specific slotframe. 6top follows
the hard cell reservation process described in Section 2.6.5.
In addition, 6top allows an upper layer to schedule a certain amount
of bandwidth to a neighbor, without having to specify the exact
slotOffset(s) and channelOffset(s). 6top follows the soft cell
reservation process described in Section 2.6.2. Once bandwidth is
reserved, 6top is in charge of ensuring that this requirement is
continuously satisfied, as described in Section 2.8. 6top dynamically
reallocates cells if needed, and over-provisions if required.
6top allows an upper layer to associate a hard/soft cell with a
specific track by using a TrackID. A TrackID is a tuple
(TrackOwnerAddr,InstanceID), where TrackOwnerAddr is the address of
the node which initializes the process of creating the track, i.e.,
the owner of the track; and InstanceID is an instance identifier
given by the owner of the track. InstanceID comes from upper layer;
InstanceID could for example be the local instance ID defined in RPL.
If the TrackID is set to (0,0), the cell can be used by the best-
effort QoS configuration or as a Shared cell. If the TrackID is not
set to (0,0), i.e., the cell belongs to a specific track, the cell
MUST not be set as Shared cell.
Given this mechanism, 6top defines hard cells (which have been
requested specifically) and soft cells (which can be reallocated
Wang, et al. Expires April 23, 2014 [Page 6]
Internet-Draft 6tisch-6top October 2013
dynamically). The hard/soft flag is introduced by the 6top sublayer
as an extension of LinkOption flags defined in [IEEE802154e]. 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 6top.
A hard cell is uniquely identified by the following tuple:
slotframe ID: ID of the slotframe this cell is part of.
slotOffset: the slotOffset for the cell.
channelOffset: the channelOffset for the cell.
LinkOption bitmap: bitmap as defined in Section 2.2, including
the hard/soft bit which MUST be set to 1.
2.2.2. soft cells
A soft cell is a cell that can be reallocated by 6top dynamically.
The hard/soft bit MUST be set to 0. This cell is installed by 6top
given a specific bandwidth requirement. Soft cells are installed
through the soft cell negotiation procedure described in Section 2.6.
2.3. Data Convey Model
Once a TSCH schedule is established, 6top is responsible for feeding
the data from the upper layer into TSCH. This section describes how
6top shapes data from the upper layer (e.g., RPL, 6LoWPAN), and feeds
it to TSCH. Since 6top is a sublayer between TSCH and 6LoWPAN, the
properties associated with a packet/fragment from the upper layer
includes the next hop neighbor (DestAddr) and expected sending
priority of the packet (Priority), and/or TrackID(s). The output to
Wang, et al. Expires April 23, 2014 [Page 7]
Internet-Draft 6tisch-6top October 2013
TSCH is the fragment corresponding to the next active cell in the
TSCH schedule.
6top Data Convey Model
|
| (DestAddr, Priority, Fragment)
|
+---------------------------------------+
| I-MUX |
+---------------------------------------+
| | | | .... |
| | | | |
+---+ +---+ +---+ +---+ +---+
| | | | | | | | | |
|Q1 | |Q2 | |Q3 | |Q4 | |Qn |
| | | | | | | | | |
+---+ +---+ +---+ +---+ +---+
| | | | |
| | | | |
+---------------------------------------+
| MUX |
+---------------------------------------+
|
|
+---+
|PDU|
+---+
|
| TSCH MAC-payload
|
Figure 2
In Figure 2, 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 tracks is
configurable. For example, for a given queue, only one specific
track can be used, all of the tracks can be used, or a subset of the
tracks can be used.
When 6top 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.
Wang, et al. Expires April 23, 2014 [Page 8]
Internet-Draft 6tisch-6top October 2013
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 matching 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. The
following rules are a typical example:
The frame's layer 2 destination address MUST match the neighbor
address associated with the transmit cell.
If the transmit cell is associated with a specific track, the
frames in the queue corresponding to the TrackID have the
highest priority.
If the transmit cell is not associated with a specific track,
i.e., TrackID=(0,0), frames from a queue with a higher priority
MUST be sent before frames from a queue with a lower priority.
Further rules can be configured to satisfy specific QoS requirements.
2.4. Commands
6top provides a set of commands as the interface with the higher
layer. Most of these commands are related to the management of
slotframes, cells and scheduling information. 6top also provides an
interface allowing an upper layer to retrieve status information and
statistics. This section describes the following commands provided
by 6top.
CREATE.hardcell: Section 2.4.1.1
CREATE.softcell: Section 2.4.1.2
READ.cell: Section 2.4.1.3
UPDATE.cell: Section 2.4.1.4
DELETE.hardcell: Section 2.4.1.5
DELETE.softcell: Section 2.4.1.6
REALLOCATE.softcell: Section 2.4.1.7
CREATE.slotframe: Section 2.4.2.1
READ.slotframe: Section 2.4.2.2
Wang, et al. Expires April 23, 2014 [Page 9]
Internet-Draft 6tisch-6top October 2013
UPDATE.slotframe: Section 2.4.2.3
DELETE.slotframe: Section 2.4.2.4
CONFIGURE.monitoring: Section 2.4.3.1
READ.monitoring: Section 2.4.3.2
CONFIGURE.statistics: Section 2.4.4.1
READ.statistics: Section 2.4.4.2
RESET.statistics: Section 2.4.4.3
CONFIGURE.eb: Section 2.4.5.1
READ.eb: Section 2.4.5.2
CONFIGURE.timesource: Section 2.4.6.1
READ.timesource: Section 2.4.6.2
CREATE.neighbor: Section 2.4.7.1
READ.all.neighbor: Section 2.4.7.2
READ.neighbor: Section 2.4.7.3
UPDATE.neighbor: Section 2.4.7.4
DELETE.neighbor: Section 2.4.7.5
CREATE.queue: Section 2.4.8.1
READ.queue: Section 2.4.8.2
READ.queue.stats: Section 2.4.8.3
UPDATE.queue: Section 2.4.8.4
DELETE.queue: Section 2.4.8.5
CONFIGURE.security: Section 2.4.9.1
CONFIGURE.security.macKeyTable: Section 2.4.9.2
CONFIGURE.security.macSecurityLevelTable:Section 2.4.9.3
Wang, et al. Expires April 23, 2014 [Page 10]
Internet-Draft 6tisch-6top October 2013
Send.data: Section 2.4.10.1
Receive.data: Section 2.4.10.2
LabelSwitching.map: Section 2.4.11.1
LabelSwitching.unmap: Section 2.4.11.2
2.4.1. Cell Commands
6top provides the following commands to manage TSCH cells.
2.4.1.1. CREATE.hardcell
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, slotOffset, channelOffset).
To create a hard cell, the upper layer specifies:
slotframe ID: ID of the slotframe this timeslot will be
scheduled in.
slotOffset: the slotOffset for the cell.
channelOffset: channelOffset for the cell.
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.
TrackID: ID of the track the cell will belong to.
6top 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 soft cell(s), the upper layer specifies:
slotframe ID: ID of the slotframe the cell(s) will be scheduled
in
number of cells: the required number of soft cells.
LinkOption bitmap: bitmap as defined in Section 2.2
Wang, et al. Expires April 23, 2014 [Page 11]
Internet-Draft 6tisch-6top October 2013
target node address: the address of the node to communicate
with over the cell(s). In case of broadcast cells this is the
broadcast address.
TrackID: ID of the track the cell(s) will belong to.
QoS level: the cell redundancy policy. The policy can be for
example STRICT, BEST_EFFORT, etc.
6top is responsible for picking the exact slotOffset and
channelOffset in the schedule, and ensure that the target node choose
the same cell and TrackID. 6top marks these cells as soft cell,
indicating that it will continuously monitor their performance and
reschedule if needed.
6top 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,
slotOffset, channelOffset). It fails if the required number of cells
is higher than the available number of cells in the schedule. It
fails if the negotiation with the target node fails. It fails if the
LinkOption bitmap indicates that the cell(s) MUST be Hard.
2.4.1.3. READ.cell
Given a (slotframe ID, slotOffset, channelOffset), retrieves the cell
information. Fails if the cell does not exist. The returned
information contains:
slotframe ID: ID of the slotframe where this cell is installed.
slotOffset: the slotOffset for the cell.
channelOffset: the selected channelOffset 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.
TrackID: ID of the track the cell will belong to.
A read command can be issued for any cell, hard or soft.
2.4.1.4. UPDATE.cell
Update a hard cell, i.e., re-allocate it to a different slotOffset
and/or channelOffset. Fails if the cell does not exist. Requires
Wang, et al. Expires April 23, 2014 [Page 12]
Internet-Draft 6tisch-6top October 2013
both old (slotframe ID, slotOffset, channelOffset) and new (slotframe
ID, slotOffset, channelOffset) as parameters. And, the type of cell,
target node address and TrackID are the fields that cannot be
updated. Soft cells MUST NOT 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 remove a hard cell, the upper layer specifies:
slotframe ID: the ID of the slotframe where this cell is
installed.
slotOffset: the slotOffset for the cell.
channelOffset: the selected channelOffset for the cell.
This removes the hard cell from the node's schedule.
2.4.1.6. DELETE.softcell
To remove a (number of) soft cell(s), the upper layer specifies:
slotframe ID: 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.
TrackID: ID of the track the cell will belong to.
In the case a soft cell wants to be re-allocated from the allocated
cell 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 re-allocation of a soft cell, the upper layer specifies:
slotframe ID: ID of the slotframe where the cell is allocated.
slotOffset: the slotOffset for that cell.
channelOffset: the channelOffset for that cell.
Wang, et al. Expires April 23, 2014 [Page 13]
Internet-Draft 6tisch-6top October 2013
The reallocated cell will be installed in a different slotOffset,
channelOffset but slotframe and TrackID remain the same. Hard cells
MUST NOT be reallocated.
2.4.2. Slotframe Commands
6top 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 timeslots: the required number of timeslots in the
slotframe.
Fails if the number of required timeslots 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: ID of the slotframe. (SlotFrameHandle)
number of timeslots: the number of timeslots in the slotframe.
Fails if the slotframe ID does not exist.
2.4.2.3. UPDATE.slotframe
Change the number of timeslots in a slotframe. The command requires:
slotframe ID: ID of the slotframe.
number of timeslots: the number of timeslots to be updated.
Fails if the number of required timeslots 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: ID of the slotframe.
Fails if the slotframe ID does not exist.
Wang, et al. Expires April 23, 2014 [Page 14]
Internet-Draft 6tisch-6top October 2013
2.4.3. Monitoring Commands
Monitoring commands provide the means for upper layers to configure
whether 6top must ensure the required bandwidth. This procedure is
achieved through overprovisioning 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.
2.4.3.1. CONFIGURE.monitoring
Configures the level of QoS the Monitoring process MUST enforce. The
command requires:
slotframe ID: ID of the slotframe.
target node address: the target neighbor address.
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 address: the target neighbor address.
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.
Wang, et al. Expires April 23, 2014 [Page 15]
Internet-Draft 6tisch-6top October 2013
Fails if the slotframe ID does not exist.
2.4.4. Statistics Commands
6top keeps track of TSCH statistics for upper layers to adapt
correctly to medium changes. The exact metrics for statistics are
out of scope 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: ID of the slotframe. If empty monitors all
slotframe IDs
slotOffset: specific slotOffset to be monitored. If empty all
timeslots are monitored
channelOffset: specific channelOffset to be monitored. If
empty all channels are monitored.
target node address: the target neighbor address. If empty,
all neighbor 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 timeslot, etc. The CONFIGURE.statistics
enables flexible configuration and supports empty parameters that
will force 6top to conduct statistics on all members of that
dimension. For example, if ChannelOffset is empty and metric is set
as PDR, then, 6top will conduct the statistics of PDR on all of
channels.
Wang, et al. Expires April 23, 2014 [Page 16]
Internet-Draft 6tisch-6top October 2013
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: ID of the slotframe. If empty aggregates
information of all slotframe IDs
slotOffset: the specific slotOffset for which the information
is required. If empty all timeslots are aggregated
channelOffset: the specific channelOffset for which the
information is required. If empty all channels are aggregated.
target node address: the target neighbor address. If empty all
neighbor addresses 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: ID of the slotframe. If empty resets the
information of all slotframe IDs
slotOffset: the specific slotOffset for which the information
wants to be reset. If empty statistics from all timeslots are
reset
channelOffset: the specific channelOffset for which the
information wants to be reset. If empty all statistics for all
channels are reset.
target node address: the target neighbor address. If empty all
neighbor addresses are aggregated.
metric: metric to be reset.
Fails if empty metric or metric does not exits.
2.4.5. Network Formation Commands
Wang, et al. Expires April 23, 2014 [Page 17]
Internet-Draft 6tisch-6top October 2013
EBs need to be configured, including their transmission period, the
slotOffset and channelOffset that they SHOULD be sent on, and the
join priority they contain. The parameters for that command are
optional and enable 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 slotOffset is allocated. The slotOffset enforces the EB
to a specific timeslot. In case slotOffset parameter is not present,
the EB is sent in the first available transmit timeslot. In case
channelOffset 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: ID of the slotframe where the EBs MUST be sent.
Zero if any slotframe can be used.
slotOffset: the slotOffset where the EBs MUST be sent. Zero if
any timeslot can be used.
channelOffset: the channelOffset where the EBs MUST be sent.
Zero if any channelOffset can be used.
period: the EBs period, in seconds.
Expiration: 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 or DAGRANK(rank) as
decribed in in [I-D.vilajosana-6tisch-minimal].
Fails if the tuple (slotframe ID, slotOffset, channelOffset) is
already scheduled.
2.4.5.2. READ.eb
Reads the EBs configuration. No parameters are required.
Returns the current EBs configuration for that slotframe, which
contains:
slotframe ID: the slotframe where the EB is being sent.
slotOffset: the slotOffset where the EBs is being sent.
Wang, et al. Expires April 23, 2014 [Page 18]
Internet-Draft 6tisch-6top October 2013
channelOffset: the channelOffset the EBs is being sent on.
period: the EBs period.
Expiration: 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.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 source
neighbor. 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 source neighbors 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 source neighbor.
statistics: includes for example minimum, maximum, average time
correction for that time source neighbor
policy: the used policy
Fails if the slotframe ID or no time source neighbors exist.
Wang, et al. Expires April 23, 2014 [Page 19]
Internet-Draft 6tisch-6top October 2013
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.
2.4.7.3. READ.neighbor
Returns the information of a specific neighbor 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.
Wang, et al. Expires April 23, 2014 [Page 20]
Internet-Draft 6tisch-6top October 2013
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.8. Queueing Commands
Queues need to be configured. This includes queue length,
retransmission policy, discarding of packets, etc.
2.4.8.1. CREATE.queue
Creates and Configures 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 backoff in number of slotframes. 0
if next available timeslot wants to be used.
statswindow: window of time used to compute stats.
queue priority: the priority of this queue.
TrackIDs: a set of TrackIDs. While it is empty, no specific
track is associated with the queue
Returns the queue ID.
2.4.8.2. READ.queue
Reads the queue configuration. Requires the queue ID.
The command returns:
txqlength: the transmission queue length.
Wang, et al. Expires April 23, 2014 [Page 21]
Internet-Draft 6tisch-6top October 2013
rxqlength: the reception queue length.
numrtx: number of allowed retransmissions.
age: maximum age of a packet before being discarded. 0 if no
discards are allowed.
rtxbackoff: retransmission backoff in number of slotframes. 0
if next available timeslot 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.
TrackIDs: a set of TrackIDs.
2.4.8.4. UPDATE.queue
Update a Queue. The command requires:
queueid: the queue ID.
txqlength: the desired transmission queue length.
rxqlength: the desired reception queue length.
numrtx: number of allowed retransmissions.
Wang, et al. Expires April 23, 2014 [Page 22]
Internet-Draft 6tisch-6top October 2013
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 timeslot wants to be used.
statswindow: window of time used to compute stats.
queue priority: the desired priority of this queue.
TrackIDs: the desired set of TrackIDs.
2.4.8.5. DELETE.queue
Deletes a Queue. The command requires the queue ID. All packets in
the queue are discarded and the queue is deleted.
2.4.9. Security Commands
The following commands are used to manage underlying layer security.
In that case 6top acts as delegating interface to the security
attributes defined in the MAC PIB ([IEEE802154]).
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 table 60 in
[IEEE802154].
macAutoRequestKeyIdMode: the key identifier mode used for
automatic data requests as described by table 60 in
[IEEE802154].
macAutoRequestKeySource: the originator of the key for
automatic data requests as described by table 60 in
[IEEE802154].
macAutoRequestKeyIndex: the index of the key used for automatic
data requests as described by table 60 in [IEEE802154].
macDefaultKeySource: the originator of the default key used for
key identifier mode 0x01 as described by table 60 in
[IEEE802154].
Wang, et al. Expires April 23, 2014 [Page 23]
Internet-Draft 6tisch-6top October 2013
macPANCordinatorExtendedAddress: Address of the PAN coordinator
as described by table 60 in [IEEE802154].
macPANCordinatorShortAddress: Short address of the PAN
coordinator as described by table 60 in [IEEE802154].
2.4.9.2. CONFIGURE.security.macKeyTable
Configures Security Keys. The command requires:
KeyIdLookupList: list of keyIdLookupDescriptor Entries as
defined by table 61 in [IEEE802154].
DeviceDescriptorHandleList: Implementation specific list of
devices that are using this key. As defined by table 61 in
[IEEE802154].
KeyUsageList: List of slotframe types on which this key is
being used as specified by table 61 in [IEEE802154].
Key: 16 octets key. As specified by table 61 in [IEEE802154].
2.4.9.3. CONFIGURE.security.macSecurityLevelTable
Configures the set of security levels. The command requires:
FrameType: Slotframe type as defined by table 63 in
[IEEE802154].
Command Identifier: The command identifier as defined by table
63 in [IEEE802154].
Security Minimum: The minimum required security level as
specified by table 63 in [IEEE802154].
Device Override Security Minimum: whether the minimum security
level can be overridden as specified by table 63 in
[IEEE802154].
Allowed Security Levels: the key identifier field that
identifies the key that is being used as specified by table 63
in [IEEE802154].
Wang, et al. Expires April 23, 2014 [Page 24]
Internet-Draft 6tisch-6top October 2013
2.4.9.4. Security Command Behavior
6top offers the interface to upper layers so underlying MAC layer can
be configured. In that sense, 6top only delegates the
functionalities to the MAC security services. For more details
Section 7 on [IEEE802154] and its amendments on [IEEE802154e] 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 scope. Once a packet is inserted into a queue it waits to be
transmitted by TSCH according to the model defined in Section 2.3.
If the queue is full or destination address is not a L2 neighbor of
the node, failure to enqueue will be indicated to the caller.
The required parameters are:
src address: L2 address
dest address: L2 unicast or broadcast address
priority: packet priority, usually is consistent with queue
priority
message length: the length of the message
message: control message or data message
securityLevel:As defined by [IEEE802154e].
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
terminate this indication.
The function has the following parameters:
src address: L2 source address
dest address: L2 unicast or broadcast destination address
Wang, et al. Expires April 23, 2014 [Page 25]
Internet-Draft 6tisch-6top October 2013
priority: packet priority, usually is consistent with queue
priority
message length: the length of the message.
message: control message or data message
2.4.11. Label Switching Commands
2.4.11.1. LabelSwitching.map
The command used by an upper layer to map an input cell or a bundle
of input cells to an output cell or a bundle of output cells. 6top
stores this mapping and makes sure that the packets are forwarded at
the specific output cell/bundle. Label Switching is enabled by the
specified bundle as soon as the mapping is installed.
The required parameters are:
input cells: list of input cells (one or more cells in a
bundle). Each input cells is described by an unique tuple
(slotOffset, channelOffset, destination address).
output cells: list of output cells (one or more cells in a
bundle). Each output cells is described by an unique tuple
(slotOffset, channelOffset, destination address).
load balancing policy: A policy for load balance cell usage.
The policy is out of scope, however an example can be use ROUND
ROBIN policy within the cells of the same bundle.
2.4.11.2. LabelSwitching.unmap
The command used by upper layers to unmap one input cell or a bundle
of input cells to an output cell or a bundle of output cells. The
mapping is removed from the state kept by 6top.
The required parameters are:
input cells: list of input cells (one or more cells in a
bundle). Each input cells is described by an unique tuple
(slotOffset, channelOffset, destination address).
output cells: list of output cells (one or more cells in a
bundle). Each output cells is described by an unique tuple
(slotOffset, channelOffset, destination address).
Wang, et al. Expires April 23, 2014 [Page 26]
Internet-Draft 6tisch-6top October 2013
2.5. Message Formats
6top has to negotiate the scheduling of soft cells with neighbor
nodes. This negotiation happens through 6top-specific TSCH
Information Elements, the format of which is defined in this section.
For completeness, this section also details the formats of the IEs
already defined in [IEEE802154e] and presented here without
modification.
6top messages can contain one or more IEs. Section 2.5.1 defines the
different IEs used by 6top, both the ones used without modification
from [IEEE802154e], and the new ones defined by this document.
Section 2.5.2 shows how several IEs are assembled to form the
different frames used by 6top.
2.5.1. Information Elements
[IEEE802154e] defines Information elements (IEs). IEs are formatted
data objects consisting of an ID, a length, and a data payload used
to pass data between layers or devices. [IEEE802154e] defines Header
IEs and Payload IEs; 6top only uses Payload IEs. A Payload IE
includes one or more IEs, and ends with a termination IE (ID = 0xf,
see [IEEE802154e]).
6top uses the following Information Elements, some defined in
[IEEE802154e], others introduced in this document.
Defined in [IEEE802154e] and used by 6top without modification:
TSCH Synchronization IE (Section 2.5.1.1)
TSCH Slotframe and Link 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 6top:
6top Opcode IE (Section 2.5.1.5)
6top Bandwidth IE (Section 2.5.1.6)
6top TrackID IE (Section 2.5.1.7)
Wang, et al. Expires April 23, 2014 [Page 27]
Internet-Draft 6tisch-6top October 2013
6top Generic Schedule IE (Section 2.5.1.8)
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.
6top 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 3
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.
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. As
suggested by [I-D.vilajosana-6tisch-minimal], the beaconing device's
join priority is its DAGRank(rank).
2.5.1.2. TSCH Slotframe and Link IE
The Slotframe and Link IE (FrameAndLinkIE) contains one or more
slotframes and their respective cells that a beaconing device
advertises to allow other devices to join the network.
6top re-uses this IE as defined in [IEEE802154e].
Format of a TSCH Slotframe and Link IE (FrameAndLinkIE).
Wang, et al. Expires April 23, 2014 [Page 28]
Internet-Draft 6tisch-6top October 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | SubID |T| NumFrame | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
// Slotframe and cell information //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4
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.
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 5
The FrameID field shall be set to the slotframeHandle that uniquely
identifies the slotframe.
The FrameLen field shall be set to the size of the slotframe in
number of timeslots.
The 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.
Wang, et al. Expires April 23, 2014 [Page 29]
Internet-Draft 6tisch-6top October 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SlotOffset | ChannelOffset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LinkOption |
+-+-+-+-+-+-+-+-+
Figure 6
SlotOffset shall be set to the slotOffset of this cell.
ChannelOffset shall be set to the channelOffset 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.
6top re-uses this IE as defined in [IEEE802154e].
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 7
Length=1
SubID=0x1c
T=0, i.e., short type
TemplateID shall be set to a Timeslot template handle. The full
timeslot template, which contains the macTimeslotTemplate of TSCH
(total 25 octets), MAY be included.(see [IEEE802154e]).
2.5.1.4. TSCH Channel Hopping IE
Channel Hopping IE (ChHoppingIE) defines the Hopping Sequence being
used by the TSCH device.
Wang, et al. Expires April 23, 2014 [Page 30]
Internet-Draft 6tisch-6top October 2013
6top 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 8
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 [IEEE802154e]).
2.5.1.5. 6top Opcode IE
6top Opcode IE (OpcodeIE) defines operation codes of packets in 6top
sublayer.
This IE is not present in [IEEE802154e] and is defined by 6top.
Format of a 6top 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 9
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
Wang, et al. Expires April 23, 2014 [Page 31]
Internet-Draft 6tisch-6top October 2013
0x02: Remove Soft Cell Request
0x03: Reserve Hard Cell Request
0x04: Remove Hard Cell Request
2.5.1.6. 6top 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 6top.
Format of a 6top 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 10
Length=2
SubID=0x42
T=0, i.e., short type
FrameID 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 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. 6top TrackID IE
TrackID IE (TrackIdIE) describes the track which the reserved/removed
cell(s) are associated with.
This IE is not present in [IEEE802154e] and is defined by 6top.
Format of a 6top TrackID IE (TrackIdIE).
Wang, et al. Expires April 23, 2014 [Page 32]
Internet-Draft 6tisch-6top October 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | SubID |T|OwnerInstID|rev| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
// //
| TrackOwnerAddr |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11
Length=3 or 7. When length=3, TrackOwnerAddr is 2 bytes short
address, and when length=7, TrackOwnerAddr is 6 bytes long address.
SubID=0x43
T=0, i.e., short type
The combination of TrackOwnerAddr and OwnerInstId represents a
specific TrackID.
2.5.1.8. 6top Generic Schedule IE
Generic Schedule IE (ScheduleIE) describes cell sets. In different
packets, ScheduleIE represents different information. See
Section 2.5.2 for more detail.
This IE is not present in [IEEE802154e] and is defined by 6top.
Format of a 6top 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 12
Length=variable
SubID=0x44
T=0, i.e., short type
Wang, et al. Expires April 23, 2014 [Page 33]
Internet-Draft 6tisch-6top October 2013
Schedule Body carries one or more schedule object. An object MAY
carry a TLV (Type-Length-Value), 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
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 13
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 6).
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 14
Wang, et al. Expires April 23, 2014 [Page 34]
Internet-Draft 6tisch-6top October 2013
FrameID field MUST be set to the slotframeHandle that uniquely
identifies the slotframe.
StartSlotOffset field (2 octets) MUST be set to the slotOffset in the
specific slotframe identified by the slotframeHandle.
NumSlot field MUST be set to the number of timeslots from
StartSlotOffset in the specific slotframe identified by the
slotframeHandle.
SlotBitMap (per timeslot) indicates for the given timeslot 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 timeslot 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 6top to form a network,
reserve/maintain bandwidth using soft cells, and reserve/remove hard
cells in both the transmitter side and receiver sides. Each of these
packets uses 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 allows new nodes to join. It is an Enhanced Beacon
packet defined in [IEEE802154e] 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 Link IE (Section 2.5.1.2)
Payload IE of TSCH Enhanced Beacon Packet
Wang, et al. Expires April 23, 2014 [Page 35]
Internet-Draft 6tisch-6top October 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |GroupID|T| SyncIE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SyncIE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SyncIE | SlotTemplateIE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SlotTemplateIE | ChHoppingIE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// FrameAndLinkIE //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15
Length=variable
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 FrameAndLinkIE.
2.5.2.2. Soft Cell Reservation Request
A Soft Cell Reservation Request packet is a DATA packet defined in
[IEEE802154e] with the 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 16
Length=variable
Wang, et al. Expires April 23, 2014 [Page 36]
Internet-Draft 6tisch-6top October 2013
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.
In addition, TrackIdIE can be added in the packet to associate the
reserved soft cells to a specific TrackID.
2.5.2.3. Soft Cell Reservation Response
Soft Cell Reservation Response is a DATA packet defined in
[IEEE802154e] with the following payload IE.
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 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 0x01,
indicates Reserve Soft Cell Response operation.
Wang, et al. Expires April 23, 2014 [Page 37]
Internet-Draft 6tisch-6top October 2013
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.
In addition, TrackIdIE can be added in the packet to associate the
reserved soft cells to a specific TrackID.
2.5.2.4. Soft Cell Remove Request
Soft Cell Remove Request is a DATA packet defined in [IEEE802154e]
with the following payload IE.
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 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 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 a DATA packet defined in
[IEEE802154e] with the following payload IE.
Payload IE of Hard Cell Reservation Request
Wang, et al. Expires April 23, 2014 [Page 38]
Internet-Draft 6tisch-6top October 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 0x03,
indicates Reserve Hard Cell Request operation.
The ScheduleIE SHOULD specify all the cell that need to be reserved.
In addition, TrackIdIE can be added in the packet to associate the
reserved hard cells to a specific TrackID.
2.5.2.6. Hard Cell Remove Request
Hard Cell Remove Request is a DATA packet defined in [IEEE802154e]
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 20
Length=variable
GroupID=0x1, i.e., MLME IE
Wang, et al. Expires April 23, 2014 [Page 39]
Internet-Draft 6tisch-6top October 2013
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
6top neighbors exchange 6top-specific packets in the following cases,
each detailed in a subsection.
Network formation (Section 2.6.1)
Creating soft cells (Section 2.6.2)
Deleting soft cells (Section 2.6.3)
Maintaining soft cells (Section 2.6.4)
Creating hard cells (Section 2.6.5)
Deleting hard cells (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 time
source neighbors. 6top does not specify the criteria to choose
time source neighbors from the Enhanced BEACONs.
Wang, et al. Expires April 23, 2014 [Page 40]
Internet-Draft 6tisch-6top October 2013
Select cells for Enhanced Beacons. The joining node selects
one or more cells to indicate in its own Enhanced Beacons,
which MAY be the same as the cells used by its neighbors for
Enhanced Beacon broadcast, and record those cell(s) into the
TSCH schedule with LinkType=ADVERTISING.
Its Enhanced Beacons SHOULD include the cell(s) selected for EB
purposes. The EB cells MUST be configured with LinkOption to
"Receive" and "Timekeeping", telling its neighbors that the
cell is used for broadcast.
Start broadcasting Enhanced Beacon and communicate with
neighbors.
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 LinkType=ADVERTISING has both the "Receive" and
"Timekeeping" LinkOptions set, which means that the cell is shared by
neighbors and itself for broadcasting, then broadcasting Enhanced
Beacon has higher priority.
Whenever a node receives an Enhanced Beacon, it SHOULD update its
schedule if there is a difference regarding to the cells used for
synchronizing with the advertiser of the Enhanced Beacon.
2.6.2. Creating soft cells
The upper layer instructs 6top 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 6top.
When receiving a Create soft cell command, Node A's 6top sublayer
forms a Soft Cell Reservation Request packet which includes the BwIE
and ScheduleIE Information Elements. The BwIE indicates the number
of cells to be reserved (N1); the ScheduleIE indicates set of a
candidate cells 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 sent to the neighbor (Node B)
with whom new cells need to be scheduled. After receiving the Soft
Cell Reservation Request, Node B selects the cells from the candidate
cell set defined by the ScheduleIE in the Soft Cell Reservation
Request, and forms a Soft Cell Reservation Response packet. In the
Cell Reservation Response packet, the BwIE indicates the number of
Wang, et al. Expires April 23, 2014 [Page 41]
Internet-Draft 6tisch-6top October 2013
cells actually being reserved (N2); the 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 when sending
the 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 are out of scope.
The format of Schedule Body is flexible. For example, Node A can use
Cell Set TLV defined in Figure 13 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.
The behavior of the nodes when the soft cells negotiation fails is
out of scope.
2.6.3. Deleting soft cells
The upper layer instructs 6top to delete one or more soft cells by
calling the Delete soft cell command (Section 2.4.1.6). This command
can also be called by the monitoring process internal to 6top
(Section 2.8).
When receiving a Delete soft cell command, Node A's 6top sublayer
selects cells to be removed from its local schedule, and creates a
Soft Cell Remove Request, which includes a ScheduleIE Information
Element. 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 when 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 6top (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 re-allocated
in the TSCH schedule.
Wang, et al. Expires April 23, 2014 [Page 42]
Internet-Draft 6tisch-6top October 2013
When receiving a soft cell Maintenance command, 6top 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 6top to create one or more hard cells by
calling the Create hard cell command.
When receiving a Create hard cell command, Node A's 6top sublayer
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
specified in the ScheduleIE SHOULD be added in the local schedule of
Node B.
2.6.6. Deleting hard cells
The upper layer instructs 6top to delete one or more hard cells by
calling the Delete hard cell command.
When receiving a Delete hard cell command, Node A's 6top sublayer
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 6top Statistics Function (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
6top 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
the node's Rank or for GMPLS to the required bandwidth is met. The
specific algorithm to generate the statistics is out of scope.
Wang, et al. Expires April 23, 2014 [Page 43]
Internet-Draft 6tisch-6top October 2013
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.
The unit is Byte/second.
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 timeslots 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
The Statistics Function SHOULD be configurable. The configuration
parameters SHOULD include:
LinkQualityStatisticsEn
TafficLoadStatisticsEn
DeviceStatisticsEn
6top statistics function is enabled/disabled and configured by the
commands defined in Section 2.4.4
2.8. Monitoring
The 6top Monitoring Function (MF) is responsible for monitoring cell
quality, traffic load, and issuing soft cell Maintenance commands, or
Create/Delete soft cell commands. The data provided by the
Statistics Function MAY be used as an input of MF in taking a
monitoring decision.
2.8.1. Monitor Configuration
Wang, et al. Expires April 23, 2014 [Page 44]
Internet-Draft 6tisch-6top October 2013
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.
The 6top 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 a cell
Maintenance command, which triggers a soft cell Maintenance procedure
(see Section 2.6.4). The traffic load statistics MAY be used to
generate internal Create (resp. Delete) soft cell commands, which
trggiers a soft cell Reservation (resp. Remove) process (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 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 timeslots, Slotframe-2 consists
of 96 timeslots; timeslot duration is 10ms; QosLevel=1.5. If, from
the traffic load statistics, MF determines that 2 packet/second
SHOULD be added, then the MF generates a Create soft cell command,
where FrameID=2, NumCell=3.
2.9. Label Switching
Label Switching Fuction (LS) in 6top is responsible for maintaining
the mapping of input cells and output cells in the same track in a
particular node. By keeping that mapping, layer 3 routing can be
avoided as packets are forwarded by the 6top sublayer according to
the input cells they were received on. The selected output cell is
one of the cells that forward the packet to the subsequent hop in the
track. As cells can be grouped in bundles, 6top can maintain
mappings from input bundles to output bundles and provide a policy to
select the output cell according to the input cell.
Wang, et al. Expires April 23, 2014 [Page 45]
Internet-Draft 6tisch-6top October 2013
3. Using 6top
This part describes how 6top gives support to specific upper layers.
3.1. RPL on 6top
6top 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 6top sublayer.
In order to optimize the combination of RPL and TSCH, 6top 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
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 6top
sublayer 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. 6top 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 Zero Objective function as described in
[I-D.vilajosana-6tisch-minimal]. 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.
6top 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.
Wang, et al. Expires April 23, 2014 [Page 46]
Internet-Draft 6tisch-6top October 2013
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 6top command to set up the desired
policy. The policy is selected by RPL and enforced by the 6top
sublayer.
The rule for 6top to select and maintain time source neighbors is as
follows:
The time source neighbor of a node SHOULD be a member of the
node's neighbor set.
Time source neighbors SHOULD be the neighbors which have a
relatively lower join priority in the neighbor set. A lower
join priority indicates that the neighbor is closer to the TSCH
PAN coordinator.
The link between a node and one of its time source neighbors
SHOULD be a good link quality.
3.1.2. Support of Rank Computation
The RPL objective function is computed using a set of metrics. The
[I-D.vilajosana-6tisch-minimal] defines how Zero Objective Function
is used to configure the rank and metrics used from 6top statistics.
The specific metrics, and how the objective function is calculated
are out of scope. However, 6top builds a set of functionalities to
provide more accurate statistics of the underlying layer so the
objective function can be accommodated to the nature of a TSCH MAC
layer.
6top provides statistics for rank computation as described in
Section 2.4.4 and Section 2.7. The function used to compute the rank
based on those statistics is out of scope. However, the provided
metrics are aligned to the behavior of the TSCH MAC layer.
3.1.3. Support of Control Messages Broadcast
In RPL, some control messages, e.g., DIO in storing mode, need to be
broadcast to all neighbor nodes. The broadcast channel requirement
has to be addressed by 6top by configuring TSCH to provide such a
channel.
In order to decouple the upper (RPL) layer from TSCH, instead of
carrying DIO messages in Enhance Beacons, 6top introduces a mechanism
to establish broadcast cells.
Wang, et al. Expires April 23, 2014 [Page 47]
Internet-Draft 6tisch-6top October 2013
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 FrameAndLinkIE,
and its LinkOption field SHOULD be set to the combination of
"Receive" and "Timekeeping". The receiver of the Enhanced Beacon MAY
be listening at the cell to get the Enhanced Beacon ([IEEE802154e]).
6top 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 broadcasts, 6top 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
FrameAndLinkIE as described above, the data packet with DIO or DAO in
the payload can be received by neighbors, which enforces to the
maintenance of DODAG.
A LinkOption combining "Receive" and "Timekeeping" bits indicates to
the receivers of the Enhanced Beacon that the cell MUST be used as a
broadcast cell. The frequency of sending Enhance Beacon or other
broadcast messages by upper layer is determined by the timers
associated with the messages. For example, the transmission of
Enhance Beacons is triggered by a timer in 6top; transmission of a
DIO message is triggered by the trickle timer of RPL.
3.1.4. Support for QoS
The TSCH MAC layer is decoupled from the upper layer, and the
interaction between the upper layer ad TSCH is asynchronous. This
means that the MAC layer executes a schedule and checks at each
timeslot according to the type of cell whether there is something to
send or receive. If that is the case the packet is transmitted 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 send it in a particular timeslot according to is
destination and priority (Section 2.3). 6top provides a set of queue
management operations which enable upper layers to create different
queues and determine their priorities. This allows different classes
of traffic to be handled by the routing layer, i.e. inserting a
packet to a specific queue according to its priority.
A 6top implement MUST provide 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). The Broadcast Queue is
associated with cells with LinkType=ADVERTISING in sender's schedule,
and LinkOption="Receive" and "Timekeeping" in all neighbors'
Wang, et al. Expires April 23, 2014 [Page 48]
Internet-Draft 6tisch-6top October 2013
schedule. This indicates that the cells can be used as broadcast
cells from the sender to its neighbors. A Transmit Queue is
associated with the dedicated Transmit cells or Shared Cells. RPL
can benefit from having different priority queues to improve latency
or provide integrated services with different priorities, i.e.
different traffic classes.
Data Communication Commands (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. 6top 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. 6top is
responsible for feeding these packets to TSCH at Transmit cells or
Shared Cells.
6top conducts a QoS policy, which is out of scope. Here is an
example. Packets in higher priority queue MUST be sent out before
the packets in lower priority queue. Then, when there is an
available broadcast/unicast cell, 6top checks the broadcast/unicast
queue with higher priority first, if there is a packet, then feeds it
to TSCH at the cell, otherwise it checks broadcast/unicast queue with
lower priority further. 6top repeats the process, until it finds a
broadcast/unicast packet to feed to TSCH or finds that all of
broadcast/unicast queues are empty.
3.2. GMPLS on 6top
GMPLS is a 2.5 layer service that is used to forward packets based on
the concept of generalized labels. 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 written implicitly into a field in
each packet, as is the case in MPLS [RFC3031], the generalized label
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.
Wang, et al. Expires April 23, 2014 [Page 49]
Internet-Draft 6tisch-6top October 2013
In order to optimize the combination of GMPLS and TSCH, 6top provides
specific support to GMPLS in the following aspects:
Cell Reservation Support
QoS
3.2.1. Cell Reservation Support for GMPLS on 6top
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. 6top 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 6top supports different types of
reservations: soft cell and hard cell. How the reservation
requirements are expressed is out of scope, but 6top is able to
handle a reservation done as a specific bandwidth requirement, done
through specifying exact cells.
The [I-D.vilajosana-6tisch-minimal] defines a pre-configured schedule
that can be used to bootstrap the network. Those cells can be seen
as a GMPLS control plane where RPL routes can be formed and Track
reservations issued.
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. 6top provides commands (Section 2.4.8) to manage MAC layer
queues and assign different priorities to them.
3.2.2. Supporting QoS
GMPLS can use 6top statistics to determine whether some QoS
requirement is met. Metrics defined in Section 2.7 and operations
defined in Section 2.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.
Wang, et al. Expires April 23, 2014 [Page 50]
Internet-Draft 6tisch-6top October 2013
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.
[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.
Wang, et al. Expires April 23, 2014 [Page 51]
Internet-Draft 6tisch-6top October 2013
[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.watteyne-6tsch-tsch-lln-context]
Watteyne, T., Palattella, M., and L. Grieco, "Using
IEEE802.15.4e TSCH in an LLN context: Overview, Problem
Statement and Goals", draft-watteyne-6tsch-tsch-lln-
context-02 (work in progress), May 2013.
[I-D.thubert-6tisch-architecture]
Thubert, P., Assimiti, R., and T. Watteyne, "An
Architecture for IPv6 over the TSCH mode of IEEE
IEEE802.15.4e", draft-thubert-6tisch-architecture-00 (work
in progress), October 2013.
[I-D.palattella-6tisch-terminology]
Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
"Terminology in IPv6 over the TSCH mode of IEEE
Wang, et al. Expires April 23, 2014 [Page 52]
Internet-Draft 6tisch-6top October 2013
802.15.4e", draft-palattella-6tisch-terminology-00 (work
in progress), October 2013.
[I-D.vilajosana-6tisch-minimal]
Vilajosana, X. and K. Pister, "Minimal 6TiSCH
Configuration", draft-vilajosana-6tisch-minimal-00 (work
in progress), October 2013.
[I-D.ohba-6tsch-security]
Chasko, S., Das, S., Lopez, R., Ohba, Y., Thubert, P., and
A. Yegin, "Security Framework and Key Management Protocol
Requirements for 6TSCH", draft-ohba-6tsch-security-01
(work in progress), July 2013.
[I-D.thubert-roll-forwarding-frags]
Thubert, P. and J. Hui, "LLN Fragment Forwarding and
Recovery", draft-thubert-roll-forwarding-frags-02 (work in
progress), September 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., "Terms used in Ruting for Low power And Lossy
Networks", draft-ietf-roll-terminology-13 (work in
progress), October 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-05 (work in progress), August 2013.
[I-D.thubert-6lowpan-backbone-router]
Wang, et al. Expires April 23, 2014 [Page 53]
Internet-Draft 6tisch-6top October 2013
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.
[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-18
(work in progress), June 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) Amendment 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/>.
[label-switching-154e]
Wang, et al. Expires April 23, 2014 [Page 54]
Internet-Draft 6tisch-6top October 2013
Morell, A., Vilajosana, X., Lopez-Vicario, J., and T.
Watteyne, "Label Switching over IEEE802.15.4e Networks.
Transactions on Emerging Telecommunications Technologies",
June 2013.
Authors' Addresses
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 April 23, 2014 [Page 55]
