rongli
502c6ca5d6
* [mac filter] add rssfilter support and integrate whitelist/blacklist - provide RssIn filter function to fix the received signal strength for test purpose. - provide Address filter function which integrates whitelist and blacklist, save (~300B) RAM. - update cli and spinel-cli to reflect new otLinkFilterX() APIs. - keep whitelist/blacklist spinel properties the same as before while implemented with new otLinkFilterX() APIs. - THCI: add setOutBoundLinkQuality() API for DEV-1530 - THCI: update Allow/Block relative APIs - update some test scripts due to new OT_ERROR_ALEADY when adding duplicate address to whitelist * update for comments * add MAC_FIXED_RSS spinel property * rebase and apply new OutboundFrameBegin(aHeader) * update OpenThread.py
OpenThread on Windows
These components are the building blocks to get OpenThread integrated into the Windows networking stack and provide an interface for applications to control it.
Architecture
This design allows for support of both simple radio devices and devices running the complete OpenThread stack.
otApi.dll
This is the dynamic libray for applications to control the OpenThread stack from user mode. It
exposes all the control path APIs from openthread.h. It interfaces with the driver by the use
of IOCTLs. The IOCTLs allow otApi.dll to serialize and send commands, and poll for notifications,
which can then be returned back to the client.
otLwf.sys
This is where most of the real logic lives. otLwf.sys is an NDIS Light Weight Filter (LWF) driver.
It plugs into the networking stack, binding to a protocol driver (TCPIP) at the top, and an NDIS Miniport
at the bottom. It's job is to take IPv6 packets from TCPIP and pass the necessary data down to the Miniport
in order to send the packets out over the network.
otLwf.sys supports operating in two modes: Full Stack and Tunnel. Full Stack mode is where OpenThread is
running on the host (in Windows) and a simple radio device is connected externally. Tunnel mode is where
OpenThread is running on the external device and Windows is merely a pass through for commands and packets.
In both cases, otLwf.sys uses the Spinel command interface for interacting with the connected device. When operating
in Full Stack mode, otLwf.sys uses only the low level PHY/MAC commands. In Tunnel mode, it uses the higher layer
Spinel commands and lets the device manage the actual Thread stack.
ottmp.sys
This is the component responsible passing the Spinel commands from otLwf.sys down to the device. It is responsible
for abstracting the actual mechanism (USB, Serial, SPI) used for communicating with the device. It handles the device
arrival/removal and the encoding/decoding of data when communicating with it. The current implementation only handles
Serial devices.
Device
Windows supports OpenThread devices that implement the Spinel protocol. It supports devices that support either the raw link-layer PHY/MAC commands and devices that support the Thread commands (and devices that support both). By default, Windows will operate in Full Stack mode, only sending raw link-layer commands.