6 05319r01ZB AFG-IEEE802.15.4 Protocol Implementation Conformance Statement (PICS)

7/29/2019 6 05319r01ZB AFG-IEEE802.15.4 Protocol Implementation Conformance Statement (PICS)

1/31

October 18, 2004 ZigBee-04319r1

Submission Page 1 Phil Jamieson, Philips

Project ZigBee Alliance

Title ZigBee IEEE 802.15.4 PHY & MAC Layer Test Specification

DateSubmitted

[October 22, 2004]

Source[Phil Jamieson][Philips][Cross Oak Lane, Redhill, Surrey,RH1 5HA, UK]

Voice: [+44 1293 815265]Fax: [+44 1293 815050]E-mail: [[email protected]]

Re: ZigBee PICS Proforma for IEEE 802.15.4-2003.

Abstract As a part of formal conformance testing, developers will be asked to submit astatement of protocol conformance with respect to the ZigBee stack profilerequired by the Application Profile under test. This document is intended toprovide the form of that statement of conformance.

Purpose This document, after review by the relevant working groups, should provide aform whereby developers can proffer a statement of protocol conformance to betested under platform and profile testing.

Notice This document has been prepared to assist the ZigBee Alliance. It is offered as abasis for discussion and is not binding on the contributing individual(s) ororganization(s). The material in this document is subject to change in form andcontent after further study. The contributor(s) reserve(s) the right to add, amend orwithdraw material contained herein.

Release The contributor acknowledges and accepts that this contribution will be posted inthe member area of the ZigBee web site.


2/31



LegalNotice

Copyright ZigBee Alliance, Inc. (2003 - 2007). All rights Reserved. This information within thisdocument is the property of the ZigBee Alliance and its use and disclosure are restricted.

Elements of ZigBee Alliance specifications may be subject to third party intellectual propertyrights, including without limitation, patent, copyright or trademark rights (such a third party mayor may not be a member of ZigBee). ZigBee is not responsible and shall not be held responsible inany manner for identifying or failing to identify any or all such third party intellectual propertyrights.

This document and the information contained herein are provided on an AS IS basis and ZigBeeDISCLAIMS ALL WARRANTIES EXPRESS OR IMPLIED, INCLUDING BUT NOTLIMITED TO (A) ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN

WILL NOT INFRINGE ANY RIGHTS OF THIRD PARTIES (INCLUDING WITHOUTLIMITATION ANY INTELLECTUAL PROPERTY RIGHTS INCLUDING PATENT,COPYRIGHT OR TRADEMARK RIGHTS) OR (B) ANY IMPLIED WARRANTIES OFMERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE OR NON-INFRINGEMENT. IN NO EVENT WILL ZIGBEE BE LIABLE FOR ANY LOSS OF PROFITS,LOSS OF BUSINESS, LOSS OF USE OF DATA, INTERRUPTION OF BUSINESS, OR FORANY OTHER DIRECT, INDIRECT, SPECIAL OR EXEMPLARY, INCIDENTIAL, PUNITIVEOR CONSEQUENTIAL DAMAGES OF ANY KIND, IN CONTRACT OR IN TORT, IN

CONNECTION WITH THIS DOCUMENT OR THE INFORMATION CONTAINED HEREIN,EVEN IF ADVISED OF THE POSSIBILITY OF SUCH LOSS OR DAMAGE. All Company,brand and product names may be trademarks that are the sole property of their respective owners.

The above notice and this paragraph must be included on all copies of this document that aremade.

ZigBee Alliance, Inc.

2694 Bishop Drive, Suite 275

San Ramon, CA 94583


3/31



References

The following standards contain provisions, which, through reference in this document, constitute provisions of this

standard. All the standards listed are normative references. At the time of publication, the editions indicated werevalid. All standards are subject to revision, and parties to agreements based on this standard are encouraged to

investigate the possibility of applying the most recent editions of the standards indicated below.

1.1 ZigBee alliance documents

[R1] Document 03526r0: ZigBee Glossary of Terms, March 2004.

[R2] Document 04140r5: ZigBee Protocol Stack Settable Values (knobs), July 2004.

[R3] Document 04219r2: ZigBee V1.0 Stack Profiles, August 2004.

1.2 IEEE documents

[R4] IEEE Standard for Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY)specifications for Low Rate Wireless Personal Area Networks (LR-WPANs), 2003.

1.3 ISO documents

[R5] ISO/IEC 9646-1:1991, Information technology - Open Systems Interconnection - Conformance testingmethodology and framework - Part 1: General concepts.

[R6] ISO/IEC 9646-7:1995, Information technology - Open Systems Interconnection - Conformance testingmethodology and framework - Part 7. Implementation conformance statements.


4/31



Change history

The following table shows the change history for this specification.

Revision 1 (October 18, 2004)

Table 1 Revision change history for revision 1

Revision Version Description

0 - Initial draft.

1 -Thinned out the ZigBee stack profiles proforma for only active stackprofiles. Added test case outline section. Re-organized documentstructure. Improved PICS.


5/31



1 Introduction

To evaluate conformance of a particular implementation, it is necessary to have a statement ofwhich capabilities and options have been implemented for a given standard. Such a statement iscalled a protocol implementation conformance statement (PICS).

1.1 Scope

This document provides the protocol implementation conformance statement (PICS) proformafor IEEE 802.15.4 [R4], as interpreted by ZigBee, in compliance with the relevant requirements,and in accordance with the relevant guidance, given in ISO/IEC 9646-7.

1.2 Purpose

The supplier of a protocol implementation claiming to conform to the ZigBee standard shall

complete the following PICS proforma and accompany it with the information necessary toidentify fully both the supplier and the implementation.

The protocol implementation conformance statement (PICS) of a protocol implementation is astatement of which capabilities and options of the protocol have been implemented. Thestatement is in the form of answers to a set of questions in the PICS proforma. The questions in aproforma consist of a systematic list of protocol capabilities and options as well as theirimplementation requirements. The implementation requirement indicates whetherimplementation of a capability is mandatory, optional, or conditional depending on optionsselected. When a protocol implementer answers questions in a PICS proforma, they wouldindicate whether an item is implemented or not, and provide explanations if an item is notimplemented.

1.3 Abbreviations and special symbols

Notations for requirement status:

M MandatoryO OptionalO.n Optional, but support of at least one of the group of options labeled O.n is required.N/A Not applicableX Prohibited

item: Conditional, status dependent upon the support marked for the item.

For example, FD1: O.1 indicates that the status is optional but at least one of the featuresdescribed in FD1 and FD2 is required to be implemented, if this implementation is to follow thestandard of which this PICS Proforma is a part.


6/31



Primitives are listed in the PICS in square brackets ([]) for completeness but demonstration ofthe primitive is not required.

1.4 Instructions for completing the PICS proforma

If a given implementation is claimed to conform to this standard, the actual PICS proforma to befilled in by a supplier shall be technically equivalent to the text of the PICS proforma in thisannex, and shall preserve the numbering and naming and the ordering of the PICS proforma.

A PICS which conforms to this document shall be a conforming PICS proforma completed inaccordance with the instructions for completion given in this annex.

The main part of the PICS is a fixed-format questionnaire, divided into five tables. Answers tothe questionnaire are to be provided in the rightmost column, either by simply marking ananswer to indicate a restricted choice (such as Yes or No), or by entering a value or a set or rangeof values.

ZigBee has the notion of a stack profile (see also [R3]). A stack profile is a collection ofsettings for the operational parameters of IEEE 802.15.4 (see [R2]). Stack profiles existprimarily to address concerns about interoperability of devices implementing a specification withmany optional features and tunable parameters in a multi-vendor, multi-application environment.The operative restriction is that devices implementing the same stack profile are required tointeroperate. It is expected that a large number of application profiles will each select a singlestack profile and that the universe of stack profiles advanced and supported by the ZigBeeAlliance will be kept as small as possible.

In light of this and of the fact that embedded stack implementers can ill afford to implementmore than the minimum set of features required to support their application, protocolconformance will generally be tested with respect to a specific stack profile or at most a small setof stack profiles. This document is organized such that the general PICS outlined in clause 2 maybe further constrained using the tables in clause 3 to reflect a particular stack profile. Items notincluded in the constrained set need not be answered. Items that have optional status in thegeneral PICS may be made mandatory or disallowed under a given stack profile.


7/31



2 PICS proforma

2.1 Identification of the implementation

Implementation under test (IUT) identification

IUT name:_____________________________________________________________________

IUT version:____________________________________________________________________

______________________________________________________________________________

System under test (SUT) identification

SUT name:_____________________________________________________________________

Hardware configuration:___________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

Operating system:________________________________________________________________

Product supplier

Name: ________________________________________________________________________

Address: ______________________________________________________________________

_____________________________________________________________________________

Telephone number: _____________________________________________________________

Facsimile number: ______________________________________________________________


8/31



Email address: _________________________________________________________________

Additional information: __________________________________________________________

Client

Name: ________________________________________________________________________

Address: ______________________________________________________________________

_____________________________________________________________________________

Telephone number: _____________________________________________________________

Facsimile number: ______________________________________________________________

Email address: ________________________________________________________________

Additional information: __________________________________________________________

PICS contact person

Name: ________________________________________________________________________

Address: ______________________________________________________________________

_____________________________________________________________________________

Telephone number:______________________________________________________________

Facsimile number:_______________________________________________________________

Email address: _________________________________________________________________

Additional information:___________________________________________________________


9/31



PICS/System conformance statement

Provide the relationship of the PICS with the system conformance statement for the system:

______________________________________________________________________________

______________________________________________________________________________

______________________________________________________________________________

2.2 Identification of the protocol

This PICS proforma applies to the IEEE 802.15.4 ([R4]) PHY layer and MAC sub-layer, asinterpreted by ZigBee.

2.3 Global statement of conformance

The implementation described in this PICS proforma meets all of the mandatory requirements ofthe referenced standard with the restrictions specified in clause 3 for the following stack profiles:

Stack profile(s):______________________________________________________________

Yes

No

Note -- Answering No indicates non-conformance to the specified protocol standard. Non-supported mandatory capabilities are to be identified in the following tables, with an explanationby the implementer explaining why the implementation is non-conforming.

The supplier will have fully complied with the requirements for a statement of conformance bycompleting the statement contained in this sub-clause. That means, by clicking the above, thestatement of conformance is complete. However, the supplier may find it incumbent on theirclaim to continue to complete the detailed tabulations in the sub-clauses that follow.

Not specifying a stack profile here means that the entire PICS proforma is being addressedwithout restriction.


10/31



2.4 IEEE 802.15.4 logical device

2.4.1 Roles

Table 2 PICS for functional device types

Itemnumber

Item description Reference Status Support

FD1 The device is a full function device ZigBee

coordinator.

O1

FD2 The device is a full function device ZigBeerouter.

O1

FD3 The device is a reduced function device ZigBeeend device.

O1

O1: at least one option must be selected.

2.4.2 FD2 and FD3 network join options

Table 3 PICS for network join options

Itemnumber


JN1 The device joins a network by scanning and thenassociating.

O2

JN2 The device joins a network by using an orphanscan.

O2

O2: for FD2 or FD3 at least one option must be selected.


11/31



2.5 IEEE 802.15.4 PHY

2.5.1 Radio frequency of operation

Table 4 PICS for radio frequencies

Itemnumber


RF1 The device operates at a frequency of 868 MHz. [R4] 6.1.1, 6.1.2,

6.6

O3

RF2 The device operates at a frequency of 915 MHz. [R4] 6.1.1, 6.1.2,6.6

O3

RF3 The device operates at a frequency of 2.4 GHz. [R4] 6.1.1, 6.1.2,6.5

O3


2.5.2 Clear channel assessment

Table 5 PICS for clear channel assessment

Itemnumber


CCA1 Mode 1: Energy above threshold is supported. [R4] 6.7.9 O4

CCA2 Mode 2: Carrier sense only is supported. [R4] 6.7.9 O4

CCA3 Mode 3: Carrier sense with energy above

threshold is supported.

[R4] 6.7.9 O4



12/31



2.6 IEEE 802.15.4 MAC

2.6.1 Channel access

Table 6 PICS for channel access

Itemnumber


CA1 A super-frame structure is supported. [R4] 7.5.1.1 O

CA2 Un-slotted CSMA-CA is supported. [R4] 7.5.1.1 M

CA3 Slotted CSMA-CA is supported. [R4] 7.5.1.1 CA1: M

CA4 Super-frame timing is supported. [R4] 7.5.1.1 CA1: M


13/31



2.6.2 Guaranteed time slots

Table 7 PICS for guaranteed time slots

Itemnumber


GTS1 Guaranteed time slots are supported (server). [R4] 7.5.7 FD1: O

GTS2 Guaranteed time slots are supported (client). [R4] 7.5.7 FD2: OFD3: O

GTS3 The client device has the ability to request a GTS.Operations include:

Allocation requests

De-allocation requests

[MLME-GTS.request primitive]

[MLME-GTS.confirm primitive]

Transmission of the GTS requestcommand.

[R4] 7.1.7.1,7.1.7.2, 7.3.3.1,7.5.7.2, 7.5.7.4

GTS2: M

GTS4 The server has the ability to process GTSrequests. Operations include:

Allocation requests

De-allocation requests

Re-allocation requests

[MLME-GTS.indication primitive]

Reception and processing of the GTSrequest command.

[R4] 7.1.7.3,7.3.3.1, 7.5.7.2,7.5.7.4, 7.5.7.5

GTS1: M

GTS5 The server can manage the GTSs. [R4] 7.5.7 GTS1: M

GTS6 The server can perform CAP maintenance. [R4] 7.5.7.1 GTS1: M

GTS7 The device can transmit and/or receive datawithin a GTS.

[R4] 7.5.7.3 GTS1: MGTS2: M


14/31



2.6.3 Scanning

Table 8 PICS for channel scanning

Itemnumber


S1 The device can perform some form of channelscan. Operations include:

Scanning mechanism

[MLME-SCAN.request primitive]

[MLME-SCAN.confirm primitive]

[R4] 7.1.11.1,7.1.11.2, 7.5.2.1

M

S2 The device can perform an energy detection scan. [R4] 7.5.2.1.1 FD1: M

S3 The device can perform an active scan.Operations include:

Transmission of the beacon requestcommand.

[R4] 7.3.2.4,7.5.2.1.2 FD1: MJN1: M

S4 The device can perform a passive scan. [R4] 7.5.2.1.3 O

S5 The client can perform an orphan scan.Operations include:

Orphan device realignment.

Transmission of the orphan notifycommand.

Reception and processing of thecoordinator realignment command.

[R4] 7.3.2.3,7.3.2.5, 7.5.2.1.4

JN2: M

S6 The server can perform orphan scan processing.Operations include:

[MLME-ORPHAN.indicate primitive]

[MLME-ORPHAN.response primitive]

Reception and processing of the orphannotify command.

Transmission of the coordinator

realignment command.

[R4] 7.1.8.1,

7.1.8.2, 7.3.2.3,7.3.2.5, 7.5.2.1.4

FD1: O

S7 The server can receive and process a beacon

request command.

[R4] 7.3.2.4 S3 & FD1: M


15/31



2.6.4 PAN identifier conflict resolution

Table 9 PICS for PAN identifier conflict resolution

Itemnumber


PICR1 PAN identifier conflict resolution is supported(server). Operations include:

Reception and processing of the PANidentifier conflict notification command.

Transmission of the coordinatorrealignment command.

[R4] 7.3.2.2,7.3.2.5, 7.5.2.2

FD1: O

PICR2 PAN identifier conflict resolution is supported(client). Operations include:

Transmission of the PAN identifierconflict notification command.

Reception and processing of thecoordinator realignment command.

[R4] 7.3.2.2,7.3.2.5, 7.5.2.2

FD2: OFD3: O

2.6.5 PAN start

Table 10 PICS for starting a PAN

Itemnumber


PS1 Starting a PAN is supported. Operations include:

[MLME-START.request primitive]

[MLME-START.confirm primitive]

[R4] 7.1.14.1,7.1.14.2, 7.5.2.3

FD1: MFD2: MFD3: O


16/31



2.6.6 Association

Table 11 PICS for association

Itemnumber


A1 Association is supported (server). [R4] 7.5.3.1 FD1: OFD2: O

A2 Association is supported (client). [R4] 7.5.3.1 FD2: OFD3: O

A3 The server can process association requests.Operations include:

[MLME-ASSOCIATE.indicateprimitive]

[MLME-ASSOCIATE.responseprimitive]

Reception and processing of theassociation request command.

Transmission of the associationresponse command.

[R4] 7.1.3.2,7.1.3.3, 7.3.1.1,

7.3.1.2

A1: M

A4 The client can perform association. Operationsinclude:

[MLME-ASSOCIATE.requestprimitive]

[MLME-ASSOCIATE.confirmprimitive]

Transmission of the association requestcommand.

Reception and processing of theassociation response command.

[R4] 7.1.3.1,7.1.3.4, 7.3.1.1,

7.3.1.2

A2: M


17/31



2.6.7 Disassociation

Table 12 PICS for disassociation

Itemnumber


D1 The device can request a disassociation.Operations include:

[MLME-DISASSOCIATE.requestprimitive]

[MLME-DISASSOCIATE.confirmprimitive]

Transmission of the disassociationnotify command.

[R4] 7.1.4.1,7.1.4.3, 7.3.1.3

O

D2 The client can react to a disassociation from theserver. Operations include:

[MLME-DISASSOCIATE.indicateprimitive]

Reception and processing of thedisassociation notify command.

[R4] 7.1.4.2,7.3.1.3

O

D3 The server can react to a disassociation from aclient device. Operations include:

[MLME-DISASSOCIATE.indicateprimitive]

Reception and processing of thedisassociation notify command.

[R4] 7.1.4.2,7.3.1.3

O


18/31



2.6.8 Beacon synchronization

Table 13 PICS for beacon synchronization

Itemnumber


BS1 Beacon notification is supported. Operationsinclude:

[MLME-BEACON-NOTIFY.indicationprimitive]

[R4] 7.1.5.1 O

BS2 The client can synchronize to a beacon.Operations include:

(Tracking only for beacon networks)

[MLME-SYNC.request primitive]

[MLME-SYNC-LOSS.indicationprimitive]

[R4] 7.1.15.1,7.1.15.2, 7.5.4

O

2.6.9 Transmission

Table 14 PICS for transmission

Itemnumber


T1 Frame transmission is supported. Operationsinclude:

Frame construction

[MCPS-DATA.request primitive]

[MCPS-DATA.confirm primitive]

Transmission of data frames.

[R4] 7.1.1.1,7.1.1.2, 7.2.1,

7.2.2.2, 7.5.6.1

M

T2 Implicit (command frame) transmissionconfirmation is supported. Operations include:

[MLME-COMM-STATUS.indicationprimitive]

[R4] 7.1.12.1 M


19/31



2.6.10 Reception

Table 15 PICS for reception

Itemnumber


R1 Frame reception is supported. Operationsinclude:

Data frame de-construction

[MCPS-DATA.indication primitive]

Reception of data frames.

[R4] 7.1.1.3,7.2.1, 7.2.2.2

M

R2 Receiver control is supported. Operations

include:

[MLME-RX-ENABLE.requestprimitive]

[MLME-RX-ENABLE.confirmprimitive]

[R4] 7.1.10.1,

7.1.10.2

O

R3 Filtering and rejection is supported. [R4] 7.5.6.2 M

R4 Promiscuous mode is supported. [R4] 7.5.6.6 O


20/31



2.6.11 Transaction handling

Table 16 PICS for transaction handling

Itemnumber


TH1 Transaction handling is supported (server). [R4] 7.5.5 FD1: OFD2: O

TH2 Transaction handling is supported (client). [R4] 7.5.5 FD2: OFD3: O

TH3 The server can manage transactions to its devices.Operations include:

Transaction queuing

[MCPS-PURGE.request primitive]

[MCPS-PURGE.confirm primitive]

Reception and processing of the datarequest command.

[R4] 7.5.5,7.1.1.4, 7.1.1.5,

7.3.2.1

TH1: M

TH4 The client can extract data from the coordinator

following an indication of data in a beacon.

[R4] 7.5.6.3 TH2: O5

TH5 The client can poll for data. Operations include:

[MLME-POLL.request primitive]

[MLME-POLL.confirm primitive]

Transmission of the data requestcommand.

[R4] 7.1.16.1,7.1.16.2, 7.3.2.1

TH2: O5

O5: At least one of these options must be supported.


21/31



2.6.12 Acknowledgement service

Table 17 PICS for acknowledgement service

Itemnumber


AS1 The acknowledgement service is supported. [R4] 7.5.6.4 O

AS2 The device can transmit, receive and process

acknowledgement frames.

[R4] 7.2.2.3 AS1: M

AS3 Duplicate detection is supported. Operationsinclude:

(Minimal support)

[R4] 7.5.6.4.2,7.5.6.5

AS1: M

AS4 Retransmissions are supported. [R4] 7.5.6.5 AS1: M

2.6.13 MIB management

Table 18 PICS for MIB management

Itemnumber


MM1 MIB management is supported. Operations

include:

MIB attribute storage

[R4] 7.4.2 O

MM2 The device supports the reading of MIBattributes. Operations include:

[MLME-GET.request primitive]

[MLME-GET.confirm primitive]

[R4] 7.1.6.1,7.1.6.2, 7.4.2

MM1: O

MM3 The device supports the writing of MIBattributes. Operations include:

MIB attribute verification

[MLME-SET.request primitive]

[MLME-SET.confirm primitive]

[R4] 7.1.13.1,7.1.13.2, 7.4.2

MM1: O


22/31



2.6.14 MAC security

Table 19 PICS for MAC security

Itemnumber


MS1 The device supports ACL mode. Operationsinclude:

ACL storage

ACL mode usage

[R4] 7.4.2,7.5.8.1, 7.5.8.3

O

MS2 The device supports secured mode. [R4] 7.5.8.4 O

2.6.15 Device reset

Table 20 PICS for device reset

Itemnumber


DR1 The device is able to reset. Operations include:

[MLME-RESET.request primitive]

[MLME-RESET.confirm primitive]

[R4] 7.1.9.1,7.1.9.2

O


23/31



3 ZigBee stack profiles proforma

Each of the tables in this sub-clause contains additional restrictions and constraints imposed byone of the supported ZigBee stack profiles. For a comprehensive list of ZigBee stack profiles see[R3].

Only those PICS proforma relevant to the specific stack profile will be tested. Any PICS notlisted under a specific stack profile is considered optional.


24/31



3.1 Home controls stack profile

Table 21 PICS for home controls stack profile

Itemnumber

Status Additional Constraints Support

CA2 M All devices shall set their MIB values as follows:macBeaconOrder=0x0f, macSuperframeOrder=0x0f.

S1 M All devices shall be able to perform at least an active scan.

S2 FD1: M The coordinator shall perform an energy detection scan on eachavailable channel before starting a network.

S3 M All devices shall perform an active scan on each availablechannel.

S5 JN2: M An orphan scan shall be performed on each available channel.If a match is found, the scan shall terminate.

S6 FD1: MFD2: M

S7 FD1: MFD2: M

PS1 FD1: MFD2: M

A1 FD1: MFD2: M

A2 JN1: M

A3 FD1: MFD2: M

A4 JN1: M

D2 FD2: MFD3: M

D3 FD1: MFD2: M

T1 M

T2 M

R1 M

R3 M

TH1 FD1: M

FD2: M

The server shall be able to handle at least one transaction.

TH2 FD2: MFD3: M

TH3 FD1: MFD2: M

TH5 FD3: M


25/31



Itemnumber

Status Additional Constraints Support

AS1 M

AS2 M

AS3 M

AS4 M

MM1 M

MM2 M

MM3 M

DR1 M


26/31



4 Test case outlineThe test cases outlined here will be run under the aegis of a particular stack profile which may

change, for example, the character of the observables arising from each test. These differencesshould be detailed in the final test plan document, which should spell out such differences on acase-by-case basis.

4.1 Observables

The test profile is designed to run above the APS layer and so no IEEE 802.15.4 interfaces aredirectly accessible. However, device manufacturers providing devices for testing may berequired to provide access to a number of observables, each of which shall be accessible.

4.1.1 Internal stack observables

Observable Description

Association permit flag The association permit flag (ZigBee coordinators and routers only).

Beacon order The beacon order of the network on which the device is operating.

Data sequence number The data sequence number placed in a transmitted frame to ensureuniqueness.

Device list A list of device addresses currently associated to the network.

PAN ID The PAN ID of the network on which a device is operating.

Short address A devices logical address, as provided by the NWK.

Super-frame order The super-frame order of the network on which the device is operating.

4.1.2 Over-the-air observables

The transmission of packets must be observable during testing and it must be possible to readand confirm the contents of the PHY and MAC headers for those packets. The detailed test planshould specify the exact format of the packets involved as well as the command argumentsrequired to produce those packets.


27/31



4.2 Test cases for all devices

Test PICS item Description ObservablesGD1 CA2 The test harness shall emulate

an intermittent interferer on thechannel and the DUT shallinitiate the transmission of adata frame.

DUT shall not transmit on

the channel in the presenceof an interferer.

The DUT shall transmit onthe channel when nointerferer exists.

GD2 T1 The DUT shall initiate thetransmission of a data frame.

The DUT shall constructand transmit the data frameaccording to the specifiedframe structure.

GD3 R1, R3 The test harness shall emulatethe transmission of a valid data

frame, an invalid data frameand a frame intended foranother device to the DUT.

The DUT shall accept thevalid frame and pass it up

the stack. The DUT shall reject the

invalid frame.

The DUT shall reject theframe intended for anotherdevice.

GD4 AS1, AS2 The test harness shall emulatethe transmission of a data frameto the DUT, which requests anacknowledgement.

The DUT shall transmit anacknowledgement framecontaining the same datasequence number as thatreceived in the data frame.

The DUT shall pass thereceived data frame up thestack.

GD5 AS3 The test harness shall emulatethe transmission of twoidentical data frames (i.e. withidentical data sequencenumbers), both requesting anacknowledgement.

The DUT shall transmit anacknowledgement frame forthe both received dataframes.

The DUT shall only pass upthe first received dataframe, rejecting the second.

GD6 AS4 The DUT shall initiate the

transmission of a data,requesting anacknowledgement. The testharness shall not respond withan acknowledgement to the firstframe but only to the second.

The DUT shall re-transmit

the data frame, i.e. twoidentical transmissions shallbe observed.


28/31



Test PICS item Description ObservablesGD7 MM1,

MM2,

MM3

The DUT shall initiate a MIBread of the data sequence

number attribute and theninitiate a MIB write to adifferent value.

The data sequence numbershall change.

GD8 DR1 The DUT shall initiate a devicereset.

The short address and PANID of the DUT shall both beset to their default values of0xffff.


29/31



4.3 Test cases for the ZigBee coordinator and routers

Table 22 - Tests for the ZigBee coordinator and routers

Test PICS item Description ObservablesZCR1 CA2, S1,

S2, S3, PS1The DUT shall initiate anetwork start and the testharness shall emulate acollection of existing networks.

The DUT shall perform anenergy detection scan andan active scan.

The DUT shall transmitbeacon request commandson each channel to bescanned.

The DUT shall have a shortaddress equal to 0x0000.

The DUT shall have a PAN

ID. The DUT shall have a

beacon order and super-frame order appropriate tothe stack profile.

ZCR2 A1, A3 The test harness shall emulate agroup of devices attempting toassociate. The DUT shallassociate devices under certainconditions.

If the DUT has not started anetwork, it shall notrespond.

If the DUT has not set itsassociation permit flag, itshall not respond.

Otherwise, the DUT shallaccept association requestsand respond to each bytransmitting an associationresponse commandcontaining an allocatedaddress.

ZCR3 D1 The DUT shall initiate a requestto disassociate a device fromthe network.

The DUT shall transmit adisassociation notifycommand to the device tobe removed.

ZCR4 D3 The test harness shall emulate adevice associated to the DUTthat has requested adisassociation.

The DUT shall remove thedevice from its device list.


30/31



Test PICS item Description ObservablesZCR5 S1, S6 The test harness shall emulate a

number of devices associating

to the network. Following this,the test harness shall emulateone device performing anorphan scan.

The DUT shall transmit acoordinator realignment

command to the device thattransmitted the originalorphan notificationcommand.

ZCR6 S7 The DUT shall have started anetwork. The test harness shallemulate a device attempting toassociate to the DUT.

The DUT shall transmit abeacon frame following thereception of a beaconrequest command frame.

ZCR7 TH1, TH3 The DUT shall initiate thetransmission of a data frame fora sleeping device. The test

harness shall emulate a sleepingdevice.

The DUT shall transmit thedata frame only in responseto a data request command.


31/31


S b i i P 31 Phil J i Phili

4.4 Test cases for all other devices

Test PICS item Description ObservablesAD1 S1, S3, A2,

A4

The test harness shall emulate a

collection of existing networksand the DUT shall attempt toassociate with one of them.

The DUT shall perform an

active scan. The DUT shall transmit

beacon request commands oneach channel to be scanned.

The DUT shall transmit anassociation request commandto one of the existingnetworks.

The DUT shall receive anassociation responsecommand.

AD2 S1, S5 The test harness shall emulate acollection of existing networks,one of which, will know of theexistence of the DUT and theDUT shall attempt to join one ofthem using orphaning.

The DUT shall perform anorphan scan.

The DUT shall transmit theorphan notify command.

The DUT shall receive acoordinator realignmentcommand from a network.

AD3 A2, A4 The test harness shall emulate acoordinator that is not allowingassociations. The DUT shallinitiate an association with the

coordinator.

The DUT shall not attempt toassociate with thecoordinator.

AD4 TH2, TH5 The test harness shall emulate apending message intended forthe DUT. The DUT shall pollfor the message.

The DUT transmits a datarequest command.

AD5 D2 The DUT shall be configured tobe associated to a network. Thetest harness shall emulate adisassociation request to theDUT.

The DUT shall acknowledgethe disassociation notifycommand.

The DUT shall cease activityon the network.

The short address shall be

reset to its default of 0xffff. The PAN ID shall be reset to

its default of 0xffff.

End of document.

Documents

6 05319r01ZB AFG-IEEE802.15.4 Protocol Implementation Conformance Statement (PICS)