AN1066 - MiWi App Note

AN1066Microchip MiWi™ Wireless Networking Protocol Stack

INTRODUCTIONImplementing applications with wireless networking isnow common. From consumer devices to industrialapplications, there is a growing expectation thatdevices will have built-in the ability to communicatewith each other without a hard-wired connection. Thechallenge is to select the right wireless networkingprotocol and implement it in a cost-effective manner.

The Microchip MiWi™ Wireless Networking ProtocolStack is a simple protocol designed for low data rate,short distance, low-cost networks. Fundamentallybased on IEEE 802.15.4™ for Wireless Personal AreaNetworks (WPANs) later expanded to supportMicrochip proprietary RF transceivers, the MiWiprotocol provides an easy-to-use alternative forwireless communication. In particular, it targets smallerapplications that have relatively small network sizes,with few hops between. MiWi protocol now is one of thewireless communication protocols that are supported inMiWi™ Development Environment (DE). It usesMiMAC interface to communicate with Microchip RFtransceivers and uses MiApp interface to interact withapplication layer.

For more information, please refer to the Microchipapplication note AN1283 “Microchip Wireless MediaAccess Controller - MiMAC” (DS01283) and AN1284“Microchip Wireless Application ProgrammingInterface - MiApp” (DS01284).

This application note covers the definition of the MiWiWireless Networking Protocol Stack and how it works.For completeness, this document also introducesseveral aspects of wireless networking, as well as keyfeatures of IEEE 802.15.4. However, it is assumed thatthe user is already familiar with the C programminglanguage and IEEE 802.15.4. You are strongly advisedto read the IEEE 802.15.4 specification and MiMAC/MiApp application notes in detail prior to using theMicrochip MiWi Wireless Networking Protocol Stack.

FEATURESThe current implementation of the MiWi protocol hasthese features:

• Support all Microchip RF transceivers on different frequency bands.

• Portable between various Microchip MCU families.

• RTOS and application independent• Out-of-box support for the MPLAB® C18, C30 and

C32 compilers• Easy-to-use API

CONSIDERATIONSA network using the MiWi protocol is capable of havinga maximum of 1024 nodes on a network. Eachcoordinator is only capable of having 127 children, witha maximum of 8 coordinators in a network. Packets cantravel a maximum of 4 hops in the network and 2 hopsmaximum from the PAN coordinator.

If, after reading this application note, you determinethat you require a standardized wireless platform,larger network sizes or common marketing logos,please refer to the application notes AN1232“Microchip ZigBee-2006 Residential Stack Protocol”(DS01232) and AN1255 “Microchip ZigBee PROFeature Set Protocol Stack” (DS01255). Alternatively,users may consider using the basic MiWi protocol andmodifying it to suit their own applications.

For more information on the most up-to-date list oflimitations of the Stack, refer to the Readme file locatedwith the Stack download at http://www.microchip.com/miwi.

TERMINOLOGYIn describing the MiWi protocol, two specific terms areused throughout that are borrowed from the IEEEstandard.

The first term is cluster, which refers to a grouping ofnodes that form a network. A MiWi protocol cluster canbe up to 3 nodes deep and is controlled by a cluster-head. In the current implementation of the MiWi protocol,the cluster-head is always the PAN coordinator. (Formore information, see Table 2.)

The second term is socket, also referred as “IndirectMessage” in MiApp interface. It refers to a virtualconnection between two devices. Rather than have anexclusive hard-wired connection between devices,many devices with many types of sockets share acommon communications medium and use somecommon method to associate applications anddevices. When a new device or application is added tothe network, it requires configuration to communicate

Author: David Flowers and Yifeng YangMicrochip Technology Inc.

© 2010 Microchip Technology Inc. DS01066B-page 1

http://www.microchip.com/MiWi

AN1066
to other devices or applications. By using sockets,nodes in the network can find communication partnersdynamically without having to know any informationabout them.
MiWi PROTOCOL OVERVIEWThe MiWi protocol is based on the MAC and PHYlayers of the IEEE 802.15.4 specification, and istailored for simple network development in the 2.4 GHzand subGHz ISM frequency bands. The protocolprovides the features to find, form and join a network,as well as discovering nodes on the network and routeto them. It does not cover any application-specificissues, such as how to select which network to join to,how to decided when a link is broken or how oftendevices should communicate.

IEEE 802.15.4 MACThe MiWi protocol uses IEEE Standard 802.15.4 asreference to develop its MAC layer.

Similar to IEEE 802.15.4, MiWi protocol uses anAcknowledged data transfer mechanism in the MAC.This method uses a special ACK flag in the packetheader. When this flag is set, Acknowledgement to thetransmitter by its receiver is required; this ensures that aframe is, in fact, delivered. If the frame is transmitted withan ACK flag set and the Acknowledgement is not

received within a certain time-out period, the transmitterwill retry the transmission for a fixed number of timesbefore declaring an error.

It is important to note that the reception of anAcknowledgement simply indicates that a frame wasproperly received by the MAC layer. However, it does notindicate that the frame was processed correctly. It ispossible that the MAC layer of the receiving nodereceived and Acknowledged a frame correctly, but dueto the lack of processing resources, a frame might bediscarded by upper layers. As a result, the upper layersof the application may require additionalAcknowledgement response.

Device TypesIEEE 802.15.4 defines devices based on their overallfunctionality. There are basically two device types asshown in Table 1.

The MiWi protocol defines three types of MiWi protocoldevices, based on their functions in the network: PANCoordinator, Coordinator and End Device. The MiWiWireless Networking Protocol Stack functionality helpsto determine the type of IEEE functionality that thedevice requires. The MiWi protocol device types andtheir relationship to IEEE device types are shown inTable 2.

TABLE 1: IEEE 802.15.4™ FUNCTIONAL DEVICE TYPES

TABLE 2: MiWi™ PROTOCOL DEVICE TYPES

Device Type Services Offered Typical Power Source Typical Receiver Idle Configuration

Full Function Device (FFD) All or Most Mains OnReduced Function Device (RFD)

Limited Battery Off

Device Type IEEE Device Type Typical Function

PAN Coordinator FFD One per network. Forms the network, allocates network addresses, holds binding table.

Coordinator FFD Optional. Extends the physical range of the network. Allows more nodes to join the network. May also perform monitoring and/or control functions.

End Device FFD or RFD Performs monitoring and/or control functions.

DS01066B-page 2 © 2010 Microchip Technology Inc.

AN1066

MiWi PROTOCOL NETWORK CONFIGURATIONSOf the three device types defined in the MiWi protocol,the most essential type to networking is the PANcoordinator. The PAN coordinator is the device thatstarts the network, and selects the channel and thePAN ID of the network. All other devices joining ontothe PAN have to obey the instructions of the PANcoordinator.

Star Network ConfigurationA star network configuration (Figure 1) consists of onePAN coordinator node and one or more end devices. Ina star network, all end devices communicate only withthe PAN coordinator. If an end device needs to transfer

data to another end device, it sends its data to the PANcoordinator, which in turn, forwards the data to theintended recipient.

Cluster Tree Network ConfigurationIn a cluster tree network (Figure 2) there is still only onePAN coordinator; however, other coordinators areallowed to join on to the network. This forms a tree-likestructure, where the PAN coordinator is the root of thetree, the coordinators are the branches of the tree andthe end devices are the leaves of the tree. In a clustertree network, all of the messages sent through thenetwork follow the path of the tree structure. Sincemessages may be routed through more than one nodeto reach their eventual destination, cluster tree networksare sometimes also referred to as multi-hop networks.

FIGURE 1: STAR NETWORK CONFIGURATION

FIGURE 2: CLUSTER TREE TOPOLOGY

PAN Coordinator

FFD End Device

RFD End Device

Legend

PAN Coordinator

FFD End Device

RFD End Device

Coordinator

Legend


AN1066
Mesh Network ConfigurationA mesh network (Figure 3) is similar to a cluster treeconfiguration, except that Full Function Device (FFDs)can route messages directly to other FFDs instead offollowing the tree structure. Messages to ReducedFunction Device (RFDs) must still go through theRFD’s parent node. The advantages of this topologyare that message latency can be reduced and reliabilityis increased. Like cluster tree networks, mesh networksare multi-hop.
Multi-Access NetworksAn IEEE 802.15.4 network is a multi-access network,meaning that all nodes in a network have equal accessto the medium of communication. There are two typesof multi-access mechanisms: beacon and non-beacon.

In a beacon enabled network, nodes are allowed totransmit in predefined time slots only. The PANcoordinator periodically begins with a superframe,identified as a beacon frame, and all nodes in thenetwork are expected to synchronize to this frame. Eachnode is assigned a specific slot in the superframe, duringwhich, it is allowed to transmit and receive its data. Asuperframe may also contain a common slot duringwhich all nodes compete to access the channel.

In a non-beacon enabled network, all nodes in anetwork are allowed to transmit at any time as long asthe channel is Idle. The current version of the MicrochipMiWi Wireless Networking Protocol Stack supportsonly non-beacon networks.

FIGURE 3: MESH NETWORK

PAN Coordinator

FFD End Device

RFD End Device

Coordinator

Legend


AN1066

ADDRESS ASSIGNMENTThe MiWi protocol uses the addresses provided byIEEE 802.15.4. There are three different addressesdefined by the specification:

1. Extended Organizationally Unique Identifier(EUI): This is an 8-byte number that is globallyunique. Every device shipped using the IEEE802.15.4 specification, should have a unique EUIaddress. The upper 3 bytes of the EUI arepurchased from IEEE (see link for the site in theSection “References” to buy them). The lower5 bytes of the EUI are available for the user, asthey see fit, as long as they are globally unique.For SubGHz proprietary RF transceivers, the EUIaddress length is in the range of two to eightbytes, defined by the application.

2. PAN Identifier (PANID): The PANID is a 16-bitaddress that defines a group of nodes. Allnodes in the PAN share a common PANID. Adevice assumes the PANID for a network whenit selects to join that PAN.

3. Short Address: Also known as the deviceaddress, this is a 16-bit (2-byte) address that isassigned to a device by its parent. This shortaddress is unique within a PAN and is used foraddressing and messaging within the network.IEEE specifies that the PAN coordinator alwayshas an address of 0000h. The addressallocation is up to the PAN coordinator from thatpoint forward.

The MiWi protocol uses the 16 available bits in theshort address to help with routing and exchanging nodeinformation. The bit fields within the address are shownin Figure 4.

The Parent’s Number field (bits 10-8) is unique for eachcoordinator on the network, including the PANcoordinator. As the Parent’s Number field is only 3-bitslong, this limits the number of coordinators in a networkto 8.

The Child’s Number field (bits 6-0) of any coordinatoron the network will be 00h. This indicates that they areoperating as a coordinator. Other values for this fieldare determined by the type of device (FFD or RFD), aswell its function within the PAN. Figure 5 gives ageneral idea of how short addresses are determined.

The RxOffWhenIdle field (bit 7) is the inverse of theIEEE 802.15.4 defined property of RxOnWhenIdle.When this bit is set, it indicates that this device will turnoff its transceiver when it is Idle and will be unable toreceive packets. Any device, other than this device’sparent, should route any packets that have this bit setto the device’s parent. The target device’s parent willbuffer the message for the child until it wakes up andrequests the data. If this bit is not set in the device’saddress, then this device is always capable of receivingpackets.

Bits 15 through 11 are always ‘0’ in this implementation.

FIGURE 4: BIT FIELD ARRANGEMENT FOR THE MiWi™ PROTOCOL SHORT ADDRESS

Reserved Parent’s Number Child’s Number

0 0 0 0 0 x x x x x x x x x x x

RxOffWhenIdle

bit 15 bit 0


AN1066
FIGURE 5: ASSIGNING SHORT ADDRESSES WITHIN A TYPICAL MiWi™ PROTOCOL NETWORK
MiWi PROTOCOL MESSAGINGOnce a network has been formed, the next majorconcern is how to send messages through the network.Any device that is a member of a MiWi protocol networkwill use its short address to communicate through thenetwork. This short address helps other devices in thenetwork to determine the location of the node and howto route to that device.

Packet FormatFor a IEEE 802.15.4 compliant RF transceiver, MiWiprotocol uses 16-bit short address to transmit andreceive messages whenever possible. The packetsshould be constructed according to Section 7.2 of theIEEE 802.15.4 specification. Proprietary SubGHz RFtransceiver, however, use EUI address in MAC layer.For more information on the packet format in MAClayer for Microchip proprietary RF transceiver, refer tothe Microchip application note AN1283 “MicrochipWireless Media Access Controller - MiMAC”(DS01283).

Above this layer resides the MiWi protocol header thatcontains information needed for routing and packetprocessing. This header format is shown in Figure 6.It is comprised of the following components:

• Hops: The number of hops that the packet is allowed to be retransmitted (00h means don’t retransmit this packet – 1 byte).

• Frame Control: The Frame Control field is a bitmap that defines the behavior of this packet. The individual bits are defined in Table 3 (1 byte).

• Dest PANID: The PANID of the final destination node (2 bytes in the MiWi protocol).

• Dest Short Address: The final destination’s short address (2 bytes).

• Source PANID: The PANID of the node that originally sent the packet (2 bytes).

• Source Short Address: The short address of the node that originally sent the packet (2 bytes).

• Sequence Number: A sequence number that can be used to track the status of packets as they travel through the network (1 byte).

FIGURE 6: MiWi™ PROTOCOL PACKET HEADER FORMAT

B A C F

G

D E

A

PAN Coordinator

FFD End Device

RFD End Device

Coordinator

Legend

0000h0100h 0200h 0282h

0300h 0201h

0381h xxxxh Short Address

Hops

Frame C

ontro

l

Dest P

ANID

Dest S

hort A

ddres

s

Source

PANID

Source

Sho

rt Add

ress

Seque

nce N

umbe

r

Report

Type

Report

ID

1 1 1 12 2 2 2 1

Legend: Numbers indicate packet component size in bytes.


AN1066

RoutingRouting in wireless networks can be a very difficult andresource intensive task. The MiWi protocol solves thisproblem by using the address allocation to indicate theparent of the device you want to send the packet to,and by using the already provided IEEE services tohelp exchange and relay routing information in thenetwork.

LEARNING ABOUT NEIGHBORING COORDINATORSOne of the tasks of a routing algorithm is determiningthe next hop for any outgoing packet. The MiWiprotocol uses the IEEE network join mechanism, inaddition to regular network traffic, to discover thesepaths. When any device is joining onto the network, itfirst sends out a beacon request packet. All of thecoordinators that hear the beacon request packetsends out a beacon packet informing neighboringdevices of their network information.

In the MiWi protocol, three bytes of additionalinformation are attached to the beacon payload toassist with routing:

• Protocol ID (1 byte): This helps distinguish MiWi protocol networks from other IEEE 802.15.4 net-works that may be operating in the same radio range. Protocol ID should always be 4Dh.

• Version Number (1 byte): The version number of the specification.

• Local Coordinators (1 byte): This field is a bitmap that indicates which coordinators are currently visible by the coordinator that is sending the beacon. Each bit position directly represents one of 8 possible coordinators. Bit 0 is 0000h (the PAN coordinator). Bit 1 indicates that this coordinator can talk directly to 0100h, and so on.

For example: Coordinator 0x200 is capable of talking to0x500 and the PAN coordinator. The LocalCoordinators field would be ‘b00100101.

Through the Local Coordinators field of the beaconpayload, all of the coordinators on the network will learnabout various possible routes to all of those nodeswithout having to send out unique requests.

ROUTING TO OTHER DEVICESRouting in MiWi protocol networks becomes easy oncewe have knowledge of the neighboring coordinators, aswell as what those coordinators can see. Sending apacket to another node follows the logic, as shown inFigure 7.

TABLE 3: FRAME CONTROL BIT FIELD

0 0 0 0 0 x 1 0r r r r r ACKREQ INTRCLST ENCRYPT

bit 7 bit 0

bit 7-3 Reserved: Maintain as ‘0’ in this implementationbit 2 ACKREQ: Acknowledge Request bit

When set, the source device requests an upper layer Acknowledgement of receipt from the destination device.bit 1 INTRCLST: Intra Cluster bit

Reserved in this implementation, maintain as ‘1’.bit 0 ENCRYPT: Encrypt bit

When set, data packet is encrypted at the application level.

Note: Abbreviated bit names are for convenience of display only; they are not an official part of IEEE 802.15.4™.


AN1066
FIGURE 7: DECISION TREE FOR
PACKET FORWARDING

Broadcast MessagesWhen a MiWi protocol network coordinator receives abroadcast packet, it will rebroadcast the packet as longas the Hops counter (the first byte of the header) is notequal to zero.

Broadcast packets should always have their ACKrequest bits (in both the MiWi protocol header and theMAC header) set to ‘0’. Coordinators that receivebroadcast packets should then process the packet afterretransmitting it.

Know the

Know the node’s

Send it

Send it

Send itHave a next hop

Send it

YES

NO

NO

NO

YES

YES

node directly?

parent directly?

for them (if coord)

to Them Directly

to Their Parent

to the Next Hop

to My Parent

or parent?


AN1066
MiWi Protocol ReportsThe MiWi protocol transports packets between devicesby using special packets called reports. The protocolallows for the implementation of up to 256 ReportTypes, and up to 256 separate Report IDs for eachReport Type. The Report ID is the specification functionof the packet.
Report Type 00h is reserved for MiWi WirelessNetworking Protocol Stack packets, which have packetpayload that is directed to the Stack. For example, aMiWi protocol ACK has a Report Type of 00h (becauseit is a Stack packet) and a Report ID of 30h. All otherReport Types are available for the user.

The Report Type and Report ID are defined in the packetheader, as previously described in the Section “PacketFormat”. The size and contents of the payload of areport depends on the particular Report ID. In thisimplementation of the MiWi protocol, the payload sizevaries from 0 bytes (i.e., sending a packet with a specificReport Type/ID is essentially the entire message) to 10bytes, with multi-byte payloads being delivered LeastSignificant Byte (LSB) first. A list of the implementedreports in the current version of the protocol is providedin Table 4, with detailed descriptions immediatelyfollowing.

TABLE 4: REPORTS IMPLEMENTED IN THE MiWi™ PROTOCOL

OPEN_CLUSTER_SOCKET_REQUEST

The destination address of the MiWi protocol headershould be the PAN coordinator (0000h). The sourceaddress of the MiWi protocol header should be the

address of the device that is initiating the request. TheRequesting EUI Address field specifies the EUI of thedevice initiating the request, LSB first.

OPEN_CLUSTER_SOCKET_RESPONSE

The destination address of the MiWi protocol headershould be the original requesting device. The sourceaddress should be the PAN coordinator (as this packetwill only originate from the PAN coordinator). TheResulting EUI Address field specifies the EUI of thedevice that responded to the request (LSB first). Notethat this is a different address than the MiWi protocoldestination address.

The Resulting Short Address field is the short addressof the device that responded to the request. With thecombination of EUI and short address sent to bothrequesting nodes, they should be able to communicateon the network and find each other if either of themhappens to move in the network. Once theOPEN_CLUSTER_SOCKET_RESPONSE is sent out,the PAN coordinator will no longer maintain any of thesocket information.

Report Type Report ID Name

00h

10h OPEN_CLUSTER_SOCKET_REQUEST11h OPEN_CLUSTER_SOCKET_RESPONSE12h OPEN_P2P_SOCKET_REQUEST13h OPEN_P2P_SOCKET_RESPONSE20h EUI_ADDRESS_SEARCH_REQUEST21h EUI_ADDRESS_SEARCH_RESPONSE30h ACK_REPORT_TYPE 40h CHANNEL_HOPPING_REQUEST41h RESYNCHRONIZATION_REQUEST42h RESYNCHRONIZATION_RESPONSE

01h-FFh 00h-FFh Available for use

Report Type (1 byte) Report ID (1 byte) Requesting EUI Address (8 bytes)

00h 10h The EUI of the initiating device.

Report Type (1 byte)

Report ID (1 byte)

Resulting EUI Address (8 bytes)

Resulting Short Address (2 bytes)

00h 11h The EUI of the resulting device. The short address of the resulting device.


AN1066
OPEN_P2P_SOCKET_REQUEST
Both the source and destination information in the MiWiprotocol header should be FFFFh. The Hops field of theMiWi protocol header should be 00h in order to preventrebroadcast of the packet. The MAC level source and

destination PANID should be FFFFh. The MACdestination short address should be FFFFh. The MAClevel source address should be Long Address mode.

OPEN_P2P_SOCKET_RESPONSE

Both the source and destination information in the MiWiprotocol header should be FFFFh. The Hops field of theMiWi protocol header should be 00h. The MAC level

source and destination PANID should be FFFFh. TheMAC destination and source addresses should be bothlong addresses (EUIs).

EUI_ADDRESS_SEARCH_REQUEST

The destination short address and PANID of the MiWiprotocol header should be the broadcast address,FFFFh. The source address and PANID of the MiWiprotocol header should be the address information thatis requesting the search. On reception of this packet, acoordinator in the network will rebroadcast this packet if

the number of hops is more than 00h. The coordinatorwill decrement the Hops counter before rebroadcastingthe packet. The coordinator will not change the value ofthe MiWi protocol sequence number when broadcastingthe packet.

EUI_ADDRESS_SEARCH_RESPONSE

The EUI_ADDRESS_SEARCH_RESPONSE shouldbe unicast back to the address of the device thatoriginally sent the request (the device mentioned in theMiWi protocol source fields of the request packet).

ACK_REPORT_TYPE

The MiWi protocol source address of the MiWi protocolACK packet should equal the MiWi protocol destinationaddress of the packet that requires Acknowledgement.The MiWi protocol destination address of the MiWi

protocol ACK packet should equal the MiWi protocolsource address of the packet that requiresAcknowledgement.

Report Type (1 byte) Report ID (1 byte)

00h 12h


00h 13h


Report ID (1 byte)

Search EUI Address (8 bytes)

00h 20h The EUI of the device that is being searched for.


Report ID (1 byte)

Search EUI Address (8 bytes)

Search Results PANID (2 bytes)

Search Results Short Address (2 bytes)

00h 21h The EUI of the device that is being searched for.

The resulting device’s PANID.

The resulting device’s short address.


00h 30h


AN1066
CHANNEL_HOPPING_REQUEST
CHANNEL_HOPPING_REQUEST is the commandthat PAN Coordinator broadcast to every node on thenetwork to move to a different channel. This is the startof frequency agility process.

RESYNCHRONIZATION_REQUEST

When a sleeping device wakes up but cannotcommunicate with its parent continuously, it may bedue to the fact that its parent has hopped to a differentchannel due to frequency agility capability.

RESYNCHRONIZATION_REQUEST is the requestsent from the sleeping device and requestrecommunicate with its parent within all possiblechannels.

RESYNCHRONIZATION_RESPONSE

When a sleeping device wakes up but cannotcommunicate with its parent continuously, it may bedue to the fact that its parent has hopped to a differentchannel due to frequency agility capability.RESYNCHRONIZATION_RESPONSE is the responseto the RESYNCHRONIZATION_REQUEST commandfrom the parent to its child.

Report Type (1 byte) Report ID (1 byte) Current Channel (1 byte) Channel to hop (1 byte)

00h 40h Current operating channel Channel to hop to

Report Type (1 byte) Report ID (1 byte) Current Channel (1 byte)

00h 41h Current operating channel


00h 42h


AN1066

STACK MESSAGES AND SERVICESProviding address allocation and routing services arejust the beginning of a wireless network solution. Inaddition to these basic features, the MiWi protocolprovides other optional services that assist developersto more rapidly reach a solution. These servicesinclude dynamically creating connections between twodevices without having to know any information aboutthe device ahead of time (i.e., sockets), and the abilityto search the network for a specific device’s longaddress.

Discovering Nodes in the Network by EUIWhen two nodes communicate over a MiWi protocolnetwork, they use their short addresses. If the networktopology ever changes, it is useful to be able to find thatdevice again. Because the short address of a device isassigned to it by its parent, the short address of thedestination device may have changed. If this is the case,then the new short address must be discovered beforecommunication can be re-established. Unlike the shortaddress, the EUI of a device never changes and isglobally unique. If one device knows another device’sEUI, it will be able to distinguish that device from anyother device. Searching the network for a specific EUIthen becomes important in reestablishingcommunication with nodes that have moved. The MiWiprotocol provides such a feature to search the networkfor a specific EUI.

There are two Stack packets that are defined in orderto assist with searching for a specific EUI on thenetwork: EUI_ADDRESS_SEARCH_REQUEST andEUI_ADDRESS_SEARCH_RESPONSE. The SearchRequest is unicast to the first coordinator (Figure 8,sequence 1) and then broadcast among thecoordinators into the network with the EUI of the devicethat needs to be located (sequence 2). It is repeated byall of the coordinators until the Hops counter dies(sequence 3).

If one of the coordinators currently has this device as achild, it returns a EUI_ADDRESS_SEARCH_RESPONSEpacket with the device’s EUI and its short address. TheEUI_ADDRESS_SEARCH_RESPONSE is sent unicast,node by node, back to the MiWi protocol sourceaddress of the packet that originally sent the packet(sequence 4).

Opening a Socket to a DeviceAnother feature that may be important to somenetworks is the ability to dynamically formcommunication links on the network. This is useful innetworks where preconfiguration of nodes needs to beminimal.

As an example, a user may wish to add a new lightswitch to a lighting control system. How does that lightswitch know which light to send its packets to? One

way would be to have some type of interface where thedevice installer manually programs controller andtarget addresses into the devices.

CLUSTER SOCKETA more dynamic method would be to have a push buttonon both the light and the light switch. You first press thebutton on the light, and then the light switch, within aspecified time interval. This lets these two devices knowthat they need to communicate with each other. Thisallows for dynamic run-time changes in the behavior ofthe network in a simple, user-friendly method.

The MiWi protocol defines this dynamically formedcommunication link as a cluster socket. A clustersocket exists between two nodes that are members ofthe network and is formed based on the short address.Cluster Socket is also known as “Indirect Connection”in MiApp interface. For more information, refer to theMicrochip application Note AN1284 “MicrochipWireless Application Programming Interface – MiApp”(DS01284).

In the previous example, pushing the button on the lightswitch sends an OPEN_CLUSTER_SOCKET_REQUESTto the PAN coordinator with that device’s information(Figure 9, sequence 1). This notifies the PANcoordinator that the device is looking for someone tocommunicate to. The PAN coordinator keeps thatrequest open for an amount of time that is specified bythe application. If a similar request comes from the light(sequence 2), the PAN coordinator combines the shortaddress information from both devices into oneOPEN_CLUSTER_SOCKET_RESPONSE and sendsit back to the switch and the light (sequence 3). Finally,the PAN coordinator removes the open socket request. Ifthe PAN coordinator doesn’t hear a second open socketrequest within the specified amount of time, then it willterminate the open socket request without sending aresponse to the requesting node.

When the devices at F and G receive theOPEN_CLUSTER_SOCKET_RESPONSE report, theycan examine the payload of that packet and determine ifthat device is, in fact, the device that they wish to talk to.This is an application layer decision; it is not provided bythe Stack.


AN1066
FIGURE 8: SEQUENCE FOR EUI ADDRESS SEARCH REQUEST AND RESPONSE
EUI_ADDRESS_SEARCH_REQUEST From G

B A C F

G

D E

A

B A C F

G

D E

A

B A C F

G

D E

PAN Coordinator

FFD End Device

RFD End Device

Coordinator

Legend

Broadcast Message

A C F

G

D E

B

EUI_ADDRESS_SEARCH_REQUEST is Broadcast

EUI_ADDRESS_SEARCH_REQUEST is Rebroadcast From All Coordinators

EUI_ADDRESS_SEARCH_RESPONSE

Unicast

1

2

3

4

Returns by Hops From C to G


AN1066
FIGURE 9: SEQUENCE FOR OPEN SOCKET REQUEST AND RESPONSE
PROGRAMMING INTERFACESThe programming interfaces from MiWi protocol to RFtransceivers have been documented in detail inMicrochip application note AN1283 “MicrochipWireless Media Access Controller - MiMAC”. Theapplication programming interface from applicationlayer to MiWi protocol has been documented in detail inMicrochip application note AN1284 “MicrochipWireless Application Programming Interface - MiApp”(DS01284). Please refer to above two application notesfor configurations as well as prototype of function calls.

A C F

G

D E

PAN Coordinator

FFD End Device

RFD End Device

Coordinator

Legend

Unicast

B

OPEN_CLUSTER_SOCKET_REQUEST Sent From G

A C

G

D E

B F

OPEN_CLUSTER_SOCKET_REQUEST Sent From F

A C

G

D E

B F

OPEN_CLUSTER_SOCKET_RESPONSE Returned From A to F and G

1

2

3


AN1066

USER CONSIDERATIONSThere are several different network situations andcircumstances that are not inherently covered by theStack. Each of these situations should be considered.Some of the situations must be implemented. Otherscan be implemented if the system requires it.

Which Network to Join?The network discovery feature built into the MiWiprotocol searches the available channels for networks.It does not, however, choose which network to join.This is left as an application decision. Someapplications will want to pick one network over another,or a certain coordinator over another coordinator, withinthe same network. After the network discovery iscomplete, each device will then need to search throughthe list and determine to which coordinator it will join.

Failure RecoveryFailure recovery is an interesting issue in wirelesscommunications. Some developers require theirnetworks to dynamically heal when parts of the networkfail. Other developers need the network to stay asunchanged as possible, even when failures do occur.Because of this variation in requirements, the MiWiprotocol Stack doesn’t default to either implementation.

The MiWi protocol provides ACKs on both the MACand MiWi protocol layers. This allows users to knowthat their packet reached the destination correctly or todetermine that the packet did not make it to thedestination successfully. These ACKs can be used todetermine when there is a network failure.

Determining when to communicate to a node is also nota feature of this implementation. Determining a node isno longer available could be a failed packet ratio, anumber of consecutive packets failed, a low RSSI, a lowdata throughput, and so on. The current Stack does notimplement any of these requirements. If an applicationhas such requirements, then it should be added in at theapplication level (or change the Stack functionality, ifrequired).

One possible mode of failure is if the parent of a devicefails. In some networks, it is preferred that theorphaned device find a new parent, while in othernetworks, the device is left off of the network until theparent returns online. Some implementations mayprefer to rejoin the same network in a different location,while others may prefer to search for a new network.

Another problem that is not covered in the Stack is howto promote a node from a coordinator (or end device) toa PAN coordinator if the PAN coordinator fails. Becausethe Stack does not determine when a device is offline,it also cannot initiate this process. Promoting acoordinator to a PAN coordinator can create issues inthat the coordinator’s old children must all be droppedoff of the network. Remember that the PAN coordinatoralways has the address, 0000h. This means that thecoordinator that is taking over the role must change itsaddress, and thus, all of it previous children’saddresses much change as well.

Which coordinator should take control of the network isalso a decision that is better suited for the applicationto decide. Many networks can exist just fine without thePAN coordinator present. Both routing and end devicejoining works without the PAN coordinator. However, nonew coordinators will be allowed to join the networkwhile the PAN coordinator is offline.

Exchanging EUIs to Protect Against Node MigrationNodes in a wireless network may change their parentfor various reasons, including failure and mobility. Inthis situation, the device’s short address will change.Nodes that were communicating with the node thatmoved will no longer be able to communicate with thenode. It is because of this reason that devices that careabout maintaining connectivity, despite node mobility,may find it useful to request a node’s EUI afterestablishing communications with that device.

Accepting an Open Socket ResponseThe Stack provides a means of forming dynamic bondsbetween two devices through the request to establishindirect connection (also called socket in MiWi protocolterm). When the request returns a result, this merelyindicates that another device was looking for acommunication partner in the same time frame. Thisdoes not imply that the devices are meant tocommunicate to one another. Deciding if the returnednode is acceptable or not is an application leveldecision and may require implementation if required.


AN1066
Network IslandsThe coordinators and PAN coordinator in the MiWiprotocol don’t have much difference in terms offunctionality. Because of this, it is possible to create acoordinator that will take on the role of a PANcoordinator if it can’t find a suitable network. This posesan interesting problem if the entire network is powercycled. For example, a network with a PAN coordinator,two coordinators located outside of each others’ radiorange and various end devices. If the entire networkpower cycles, and the two coordinators come onlinefirst, they will both search for a PAN coordinator. Neitherwill see a PAN coordinator and each of them will form anetwork of their own, possibly on different channels.Some time later, the original PAN coordinator will power
on and attempt to find a network. It will find the networkformed by each of the PAN coordinators and join one ofthe networks. This forms two distinct networks that canno longer communicate, instead of one large network.

As an example, consider the network in Figure 10.Sequence 1 illustrates how the network operates whenit is functioning correctly. After a power failure,coordinators B and C come back online first (sequence2). They are unable to see each other and unable tofind node A so they both start their own network. Aftersome time, the other nodes in the network join. Whennode A comes back online, it will see two networks itcan join to and pick one. The two networks will remaindisjointed unless this is either prevented or corrected.

FIGURE 10: FORMATION OF MiWi™ PROTOCOL NETWORK ISLANDS

PAN Coordinator

FFD End Device

RFD End Device

Coordinator

Legend

B A C F

G

D E

A

B

G

D E

A F

After power restored:B and C come up first and

MiWi™ protocol network beforepower failure

begin re-establishing networkbefore A becomes available

B A C F

G

D E

All nodes restored:B and C are now PAN coordinatorsof two separate networks

1

2

3

B C

DisconnectedFrom Network


AN1066
To solve this problem, the best solution is to enable thenetwork freeze feature, which is defined in MiAppinterface. Network freeze feature stores critical networkinformation into the Non Volatile Memory (NVM). Whenpower cycle happens, it can read the critical networkinformation from the NVM and recovers to the statebefore the power cycle.
SecurityThere may be instances where it is necessary totransmit the key. For example: in some applications,devices may join the network without a preconfiguredkey and get assigned a key once on the network.Another example: some networks update their keyperiodically.

Users are encouraged to implement some form of keyhandling procedure in the application layer with aseparate Report Type and Report ID. One method ofdoing it is to transfer the security key and key sequencenumber every time a node joins the network, and storethe keys and key sequence number in RAM. Thisapproach only meets the minimum requirement of asecured network, since the security key is transmittedevery time a node joins the network.

An alternative approach is to set a default key for everydevice and use the default key to secure thetransferred key. This approach provides minimumprotection for the keys. A third safe approach is to adda new function to store data to the NVM during run time.This way, the security key and key sequence numberonly need to be transferred once when the deviceinitially joins the network. Once obtained, the securityinformation is retained in program memory, and doesnot have to be retransmitted if the device leaves andrejoins the network.

These key handling methods are suggestions only. Ifthis functionality is required by an application, it is leftto the user to implement a suitable method.

RESOURCE REQUIREMENTSThe size of the final application is determined by itsdevice type, as defined by both IEEE 802.15.4 and theMiWi protocol, its configuration and the use of securityfeatures. The footprint of the stack varies from releaseto release. A Coordinator capable device may be fit into32KB flash easily, while an end device can be fit into16KB flash without any problem.

Note: The memory requirements provided herereflect those of the initial release of theMiWi Wireless Networking Protocol Stackat the time of the initial publication of thisdocument. Subsequent code revisionsmay increase or decrease theserequirements.


AN1066

CONCLUSIONFor developers looking for an entry point into wirelessnetworking, the MiWi protocol provides a low-costplatform to ease the development of short-range,wireless, networked applications. MiWi protocolprovides features that help implementing a simplewireless network easier. It is not intended to address allof the scenarios and decisions required in creating awireless solution.

The MiWi protocol is the entry point for Microchip’swireless solution based on IEEE 802.15.4. Usersneeding a more complex networking solution may wantto consider the Microchip implementation of the ZigBeeprotocol or expanding the MiWi protocol to suit theirneeds.

REFERENCESIEEE Std 802.15.4-2003, Wireless Medium AccessControl (MAC) and Physical Layer (PHY)Specifications for Low Rate Wireless Personal AreaNetworks (WPANs). New York: IEEE, 2006.

“ZENA™ Wireless Network Analyzer User’s Guide”(DS51506) http://www.microchip.com

Microchip Application Note AN1283, “MicrochipWireless Media Access Controller – MiMAC” http://www.microchip.com/miwi

Microchip Application Note AN1284, “MicrochipWireless Application Programming Interface – MiApp”http://www.microchip.com/miwi


http://www.microchip.com

http://www.microchip.com





AN1066

APPENDIX A: SOURCE CODE FOR MiWi™ WIRELESS NETWORKING PROTOCOL STACK

Because of its size, a complete source code listing ofthe MiWi Wireless Networking Protocol Stack is notprovided here. The complete source code, includingthe ZENA analyzer demo software and MiWi protocoldemo applications, is available for download from theMicrochip corporate web site at: http://www.microchip.com/miwi.

REVISION HISTORY

Revision A This is the initial release of the document.

Revision B (July 2010)This revision incorporates the following updates:

• Updated the technical changes in the following sections:- Introduction- Features- Terminology- User Consideration- MiWi protocol overview- MiWi Protocol messaging- Address assignment protocol- Stack messages and services- User considerations- Resource requirements- Conclusion- References

• Added the following sections:- “CHANNEL_HOPPING_REQUEST”- “RESYNCHRONIZATION_REQUEST”- “RESYNCHRONIZATION_RESPONSE”- “Programming Interfaces”

• Tables- Updated TABLE 4: “Reports Implemented

in the MiWi™ Protocol”• Removed the following sections:

- MiWi protocol security- Setting up a MiWi protocol project- Using the Zena™ analyser as a configuration

tool- Using the stack- Data structures- MiWi protocol stack operations- MiWi Protocol stack functions

• Additional minor corrections such as language and formatting updates are incorporated throughout the document.


www.microchip.com/miwi



AN1066
NOTES:

Note the following details of the code protection feature on Microchip devices:• Microchip products meet the specification contained in their particular Microchip Data Sheet.

• Microchip believes that its family of products is one of the most secure families of its kind on the market today, when used in the intended manner and under normal conditions.

• There are dishonest and possibly illegal methods used to breach the code protection feature. All of these methods, to our knowledge, require using the Microchip products in a manner outside the operating specifications contained in Microchip’s Data Sheets. Most likely, the person doing so is engaged in theft of intellectual property.

• Microchip is willing to work with the customer who is concerned about the integrity of their code.

• Neither Microchip nor any other semiconductor manufacturer can guarantee the security of their code. Code protection does not mean that we are guaranteeing the product as “unbreakable.”

Code protection is constantly evolving. We at Microchip are committed to continuously improving the code protection features of ourproducts. Attempts to break Microchip’s code protection feature may be a violation of the Digital Millennium Copyright Act. If such actsallow unauthorized access to your software or other copyrighted work, you may have a right to sue for relief under that Act.

Information contained in this publication regarding deviceapplications and the like is provided only for your convenienceand may be superseded by updates. It is your responsibility toensure that your application meets with your specifications.MICROCHIP MAKES NO REPRESENTATIONS ORWARRANTIES OF ANY KIND WHETHER EXPRESS ORIMPLIED, WRITTEN OR ORAL, STATUTORY OROTHERWISE, RELATED TO THE INFORMATION,INCLUDING BUT NOT LIMITED TO ITS CONDITION,QUALITY, PERFORMANCE, MERCHANTABILITY ORFITNESS FOR PURPOSE. Microchip disclaims all liabilityarising from this information and its use. Use of Microchipdevices in life support and/or safety applications is entirely atthe buyer’s risk, and the buyer agrees to defend, indemnify andhold harmless Microchip from any and all damages, claims,suits, or expenses resulting from such use. No licenses areconveyed, implicitly or otherwise, under any Microchipintellectual property rights.

© 2010 Microchip Technology Inc.

Trademarks

The Microchip name and logo, the Microchip logo, dsPIC, KEELOQ, KEELOQ logo, MPLAB, PIC, PICmicro, PICSTART, PIC32 logo, rfPIC and UNI/O are registered trademarks of Microchip Technology Incorporated in the U.S.A. and other countries.

FilterLab, Hampshire, HI-TECH C, Linear Active Thermistor, MXDEV, MXLAB, SEEVAL and The Embedded Control Solutions Company are registered trademarks of Microchip Technology Incorporated in the U.S.A.

Analog-for-the-Digital Age, Application Maestro, CodeGuard, dsPICDEM, dsPICDEM.net, dsPICworks, dsSPEAK, ECAN, ECONOMONITOR, FanSense, HI-TIDE, In-Circuit Serial Programming, ICSP, Mindi, MiWi, MPASM, MPLAB Certified logo, MPLIB, MPLINK, mTouch, Octopus, Omniscient Code Generation, PICC, PICC-18, PICDEM, PICDEM.net, PICkit, PICtail, REAL ICE, rfLAB, Select Mode, Total Endurance, TSHARC, UniWinDriver, WiperLock and ZENA are trademarks of Microchip Technology Incorporated in the U.S.A. and other countries.

SQTP is a service mark of Microchip Technology Incorporated in the U.S.A.

All other trademarks mentioned herein are property of their respective companies.

© 2010, Microchip Technology Incorporated, Printed in the U.S.A., All Rights Reserved.

Printed on recycled paper.

ISBN: 978-1-60932-346-2

DS01066B-page 21

Microchip received ISO/TS-16949:2002 certification for its worldwide headquarters, design and wafer fabrication facilities in Chandler and Tempe, Arizona; Gresham, Oregon and design centers in California and India. The Company’s quality system processes and procedures are for its PIC® MCUs and dsPIC® DSCs, KEELOQ® code hopping devices, Serial EEPROMs, microperipherals, nonvolatile memory and analog products. In addition, Microchip’s quality system for the design and manufacture of development systems is ISO 9001:2000 certified.


AMERICASCorporate Office2355 West Chandler Blvd.Chandler, AZ 85224-6199Tel: 480-792-7200 Fax: 480-792-7277Technical Support: http://support.microchip.comWeb Address: www.microchip.comAtlantaDuluth, GA Tel: 678-957-9614 Fax: 678-957-1455BostonWestborough, MA Tel: 774-760-0087 Fax: 774-760-0088ChicagoItasca, IL Tel: 630-285-0071 Fax: 630-285-0075ClevelandIndependence, OH Tel: 216-447-0464 Fax: 216-447-0643DallasAddison, TX Tel: 972-818-7423 Fax: 972-818-2924DetroitFarmington Hills, MI Tel: 248-538-2250Fax: 248-538-2260KokomoKokomo, IN Tel: 765-864-8360Fax: 765-864-8387Los AngelesMission Viejo, CA Tel: 949-462-9523 Fax: 949-462-9608Santa ClaraSanta Clara, CA Tel: 408-961-6444Fax: 408-961-6445TorontoMississauga, Ontario, CanadaTel: 905-673-0699 Fax: 905-673-6509

ASIA/PACIFICAsia Pacific OfficeSuites 3707-14, 37th FloorTower 6, The GatewayHarbour City, KowloonHong KongTel: 852-2401-1200Fax: 852-2401-3431Australia - SydneyTel: 61-2-9868-6733Fax: 61-2-9868-6755China - BeijingTel: 86-10-8528-2100 Fax: 86-10-8528-2104China - ChengduTel: 86-28-8665-5511Fax: 86-28-8665-7889China - ChongqingTel: 86-23-8980-9588Fax: 86-23-8980-9500China - Hong Kong SARTel: 852-2401-1200 Fax: 852-2401-3431China - NanjingTel: 86-25-8473-2460Fax: 86-25-8473-2470China - QingdaoTel: 86-532-8502-7355Fax: 86-532-8502-7205China - ShanghaiTel: 86-21-5407-5533 Fax: 86-21-5407-5066China - ShenyangTel: 86-24-2334-2829Fax: 86-24-2334-2393China - ShenzhenTel: 86-755-8203-2660 Fax: 86-755-8203-1760China - WuhanTel: 86-27-5980-5300Fax: 86-27-5980-5118China - XianTel: 86-29-8833-7252Fax: 86-29-8833-7256China - XiamenTel: 86-592-2388138 Fax: 86-592-2388130China - ZhuhaiTel: 86-756-3210040 Fax: 86-756-3210049

ASIA/PACIFICIndia - BangaloreTel: 91-80-3090-4444 Fax: 91-80-3090-4123India - New DelhiTel: 91-11-4160-8631Fax: 91-11-4160-8632India - PuneTel: 91-20-2566-1512Fax: 91-20-2566-1513Japan - YokohamaTel: 81-45-471- 6166 Fax: 81-45-471-6122Korea - DaeguTel: 82-53-744-4301Fax: 82-53-744-4302Korea - SeoulTel: 82-2-554-7200Fax: 82-2-558-5932 or 82-2-558-5934Malaysia - Kuala LumpurTel: 60-3-6201-9857Fax: 60-3-6201-9859Malaysia - PenangTel: 60-4-227-8870Fax: 60-4-227-4068Philippines - ManilaTel: 63-2-634-9065Fax: 63-2-634-9069SingaporeTel: 65-6334-8870Fax: 65-6334-8850Taiwan - Hsin ChuTel: 886-3-6578-300Fax: 886-3-6578-370Taiwan - KaohsiungTel: 886-7-536-4818Fax: 886-7-536-4803Taiwan - TaipeiTel: 886-2-2500-6610 Fax: 886-2-2508-0102Thailand - BangkokTel: 66-2-694-1351Fax: 66-2-694-1350

EUROPEAustria - WelsTel: 43-7242-2244-39Fax: 43-7242-2244-393Denmark - CopenhagenTel: 45-4450-2828 Fax: 45-4485-2829France - ParisTel: 33-1-69-53-63-20 Fax: 33-1-69-30-90-79Germany - MunichTel: 49-89-627-144-0 Fax: 49-89-627-144-44Italy - Milan Tel: 39-0331-742611 Fax: 39-0331-466781Netherlands - DrunenTel: 31-416-690399 Fax: 31-416-690340Spain - MadridTel: 34-91-708-08-90Fax: 34-91-708-08-91UK - WokinghamTel: 44-118-921-5869Fax: 44-118-921-5820

WORLDWIDE SALES AND SERVICE

01/05/10

AN1066 - MiWi App Note

Documents

Transcript of AN1066 - MiWi App Note