1、IEEE Std 802.15.5-2009-IEEE Recommended Practice for Information technologyTelecommunications and information exchange between systemsLocal and metropolitan area networks Specific requirementsPart 15.5: Mesh Topology Capability in Wireless Personal Area Networks (WPANs) IEEE3 Park Avenue New York, N
2、Y 10016-5997, USA8 May 2009IEEE Computer SocietySponsored by theLAN/MAN Standards Committee802.15.5TMIEEE Std 802.15.5-2009 IEEE Recommended Practice for Information technology Telecommunications and information exchange between systems Local and metropolitan area networks Specific requirements Part
3、 15.5: Mesh Topology Capability in Wireless Personal Area Networks (WPANs) Sponsor LAN/MAN Standards Committee of the IEEE Computer Society Approved 19 March 2009 IEEE-SA Standards Board Abstract: This IEEE recommended practice defines the architectural framework that enables WPAN devices to promote
4、 interoperable, stable, and scaleable wireless mesh topologies and, if needed, to provide the amendment text to the current WPAN standards that is required to implement this recommended practice. Keywords: address assignment, block addressing, broadcast, carrier sense multiple access/collision avoid
5、ance, high-rate WPAN mesh, HR-WPAN mesh, multicast, low-rate WPAN mesh, LR-WPAN mesh, mesh, mesh coordinator, server routing, wakeup interval, multiple hop, multi-hop, local link state, logical tree, portable, portability, power saving, reliable broadcast, sensor network, traceroute, unicast, wirele
6、ss PAN, WPAN The Institute of Electrical and Electronics Engineers, Inc. 3 Park Avenue, New York, NY 10016-5997, USA Copyright 2009 by the Institute of Electrical and Electronics Engineers, Inc. All rights reserved. Published 8 May 2009. Printed in the United States of America. IEEE and 802 are regi
7、stered trademarks in the U.S. Patent +1 978 750 8400. Permission to photocopy portions of any individual standard for educational classroom use can also be obtained through the Copyright Clearance Center. iv Copyright 2009 IEEE. All rights reserved. Introduction This introduction is not part of IEEE
8、 Std 802.15.5-2009, IEEE Recommended Practice for Information technology Telecommunications and information exchange between systems Local and metropolitan area networks Specific requirements. This recommended practice provides the architectural framework enabling WPAN devices to promote interoperab
9、le, stable, and scalable wireless mesh topologies. This recommended practice is composed of two parts: low-rate WPAN mesh and high-rate WPAN mesh networks. The low-rate mesh is built on IEEE 802.15.4 MAC, while high rate mesh utilizes IEEE 802.15.3/3b MAC. Common features of both meshes include netw
10、ork initialization, addressing, and multihop unicasting. In addition, low-rate mesh supports multicasting, reliable broadcasting, portability support, trace route and energy saving function, and high-rate mesh supports multihop time-guaranteed service. Notice to users Laws and regulations Users of t
11、hese documents should consult all applicable laws and regulations. Compliance with the provisions of this standard does not imply compliance to any applicable regulatory requirements. Implementers of the standard are responsible for observing or referring to the applicable regulatory requirements. I
12、EEE does not, by the publication of its standards, intend to urge action that is not in compliance with applicable laws, and these documents may not be construed as doing so. Copyrights This document is copyrighted by the IEEE. It is made available for a wide variety of both public and private uses.
13、 These include both use, by reference, in laws and regulations, and use in private self-regulation, standardization, and the promotion of engineering practices and methods. By making this document available for use and adoption by public authorities and private users, the IEEE does not waive any rig
14、hts in copyright to this document. Updating of IEEE documents Users of IEEE standards should be aware that these documents may be superseded at any time by the issuance of new editions or may be amended from time to time through the issuance of amendments, corrigenda, or errata. An official IEEE doc
15、ument at any point in time consists of the current edition of the document together with any amendments, corrigenda, or errata then in effect. In order to determine whether a given document is the current edition and whether it has been amended through the issuance of amendments, corrigenda, or erra
16、ta, visit the IEEE Standards Association web site at http:/ieeexplore.ieee.org/xpl/standards.jsp, or contact the IEEE at the address listed previously. For more information about the IEEE Standards Association or the IEEE standards development process, visit the IEEE-SA web site at http:/standards.i
17、eee.org. v Copyright 2009 IEEE. All rights reserved. Errata Errata, if any, for this and all other standards can be accessed at the following URL: http:/standards.ieee.org/reading/ieee/updates/errata/index.html. Users are encouraged to check this URL for errata periodically. Interpretations Current
18、interpretations can be accessed at the following URL: http:/standards.ieee.org/reading/ieee/interp/ index.html. Patents Attention is called to the possibility that implementation of this recommended practice may require use of subject matter covered by patent rights. By publication of this recommend
19、ed practice, no position is taken with respect to the existence or validity of any patent rights in connection therewith. The IEEE is not responsible for identifying Essential Patent Claims for which a license may be required, for conducting inquiries into the legal validity or scope of Patents Clai
20、ms or determining whether any licensing terms or conditions provided in connection with submission of a Letter of Assurance, if any, or in any licensing agreements are reasonable or non-discriminatory. Users of this recommended practice are expressly advised that determination of the validity of any
21、 patent rights, and the risk of infringement of such rights, is entirely their own responsibility. Further information may be obtained from the IEEE Standards Association. Participants At the time this recommended practice was completed, the IEEE P802.15 Working Group had the following officers: Dr.
22、 Robert F. Heile, Working Group Chair Rick Alfvin, Working Group Vice Chair Patrick Kinney, Working Group Vice Chair including but not limited to, home and industrial automation and control, security and environmental monitoring, situational awareness and asset 3Information on references can be foun
23、d in Clause 2. IEEE Std 802.15.5-2008 Part 15.5: Mesh Topology Capability in Wireless Personal Area Networks (WPANs) 8 Copyright 2009 IEEE. All rights reserved. tracking, automatic meter reading, personal health monitoring, and etc. Example use cases could be as follows: a) A RF remote control that
24、can control all AV devices in all rooms of a residential house without line of sight requirement b) Wireless light switches in a commercial building, e.g. a department store, control lights of the entire floor, with the capability of grouping lights in different ways in a dynamic manner and turn the
25、m on/off with one push of the button c) Smart utility meters form a mesh network, collect meter reading data and send the data to utility companies through gateways In Clause 5 of this document, the terms mesh network and PAN are used alternatively to refer to the mesh network since all devices in a
26、 mesh network share the same PAN ID. In other words, inter-PAN communication is not supported in the current version of the standard. The reference model of low rate WPAN mesh is illustrated in Figure 2. In the data plane, the WPAN Mesh Sublayer resides between the Service Specific Convergence Subla
27、yer (SSCS) of IEEE Std 802.2-1998 Logical Link Control (LLC) and the IEEE Std 802.15.4-2006 Media Access Control (MAC) Sublayer. Mesh Sublayer provides services to the next higher layer via Mesh Service Access Point (Mesh SAP). For implementers to add mesh function to the existing low rate WPAN appl
28、ications with the least effort, the Mesh SAP is made almost identical to the MCPS SAP. In the management plane, the mesh sublayer management entity (MHME) resides between the application management entity (AME) and the MAC layer management entity (MLME). MHME also interfaces with the mesh sublayer a
29、t the same level. As a reference, the device management entity (DME) that has access and control to all layers is also shown in the figure. However, the specifications of both AME and DME are beyond the scope of this document. 802.2 LLC(SSCS)MESH SAPMESH SublayerMCPS SAPMAC CommonPart SublayerPD SAP
30、PHY LayerApplicationManagementEntity (AME)MHME SAPMHMEMLME SAPMLMEPLME SAPPLMEDeviceManagementEntity(DME)Figure 2 The reference model for low-rate WPAN mesh IEEE Std 802.15.5-2008 Part 15.5: Mesh Topology Capability in Wireless Personal Area Networks (WPANs) 9 Copyright 2009 IEEE. All rights reserve
31、d. 5.2 Mesh service description The mesh sublayer provides two types of services, the mesh data service and the mesh management service, to the next higher layer via two corresponding service access points, the mesh SAP and MHME SAP. There is also an internal interface between the mesh sublayer and
32、the MHME allowing MHME to utilize the mesh sublayer data service. On the other hand, the mesh sublayer may also need to get information from MHME through this internal interface to compose mesh sublayer data frames. 5.2.1 Mesh data service The function of the mesh sublayer data service is to support
33、 the transport of application protocol data units (APDUs) between peer application entities residing at different devices that can be multiple hops away from each other. As described in 5.1, the mesh data service primitives are very similar to the MCPS SAP primitives. The implementers should pay car
34、eful attention to the differences between them. Table 1 lists the primitives supported by the mesh SAP. Table 1 Mesh SAP primitives MESH SAP primitives Request Confirm Indication MESH-DATA 5.2.1.1 5.2.1.2 5.2.1.3 MESH-PURGE 5.2.1.4 5.2.1.5 5.2.1.1 MESH-DATA.request The MESH-DATA.request primitive re
35、quests the transfer of an SPDU (SSCS protocol data unit), from a local SSCS entity to one or more peer SSCS entities. It is very similar to the MCPS-DATA.request primitive at MAC layer. The semantics of the MESH-DATA.request primitive is as follows: MESH-DATA.request ( SrcAddrMode, DstAddrMode, DstA
36、ddr, mhsduLength, mhsdu, mhsduHandle, AckTransmission, McstTransmission, BcstTransimission, ReliableBcst ) Table 2 specifies the parameters for the MESH-DATA.request primitive. IEEE Std 802.15.5-2008 Part 15.5: Mesh Topology Capability in Wireless Personal Area Networks (WPANs) 10 Copyright 2009 IEE
37、E. All rights reserved. Table 2 MESH-DATA.request parameters Name Type Valid range Description SrcAddrMode Integer 0x000x03 The source addressing mode for this primitive and subsequent MHPDU. This value can take one of the following values: 0x00 = no address (addressing fields omitted). 0x01 = reser
38、ved. 0x02 = 16-bit short address. 0x03 = 64-bit extended address. DstAddrMode Integer 0x000x03 The destination addressing mode for this primitive and subsequent MHPDU. This value can take one of the following values: 0x00 = no address (addressing fields omitted). 0x01 = reserved. 0x02 = 16-bit short
39、 address. 0x03 = 64-bit extended address. DstAddr Device address As specified by the DstAddrMode parameter The device address of the entity, or entities in the case of multicast and broadcast, to which the MHSDU is being transferred. mhsduLength Integer (aMaxMACSafePayloadSize - meshcMaxMeshHeaderLe
40、ngth ) The number of octets contained in the MHSDU to be transmitted by the mesh sublayer entity. mhsdu Set of octets The set of octets forming the MHSDU to be transmitted by the mesh sublayer entity. mhsduHandle Integer 0x000xff The handle associated with the MHSDU to be transmitted by the mesh sub
41、layer entity. AckTransmission Boolean TRUE, FALSE This field is set to TRUE if an acknowledgement is required from the receiver; otherwise, it is set to FALSE. McstTransmission Boolean TRUE, FALSE This field is set to TRUE if the data is to be multicast; otherwise, it is set to FALSE. BcstTransimiss
42、ion Boolean TRUE, FALSE This field is set to TRUE if the data is to be broadcast; otherwise, it is set to FALSE. ReliableBcst Boolean TRUE, FALSE This field is set to TRUE if reliable broadcast is required; otherwise, it is set to FALSE. It is meaningful only when BcstTransmission is set to TRUE. IE
43、EE Std 802.15.5-2008 Part 15.5: Mesh Topology Capability in Wireless Personal Area Networks (WPANs) 11 Copyright 2009 IEEE. All rights reserved. The MESH-DATA.request primitive is generated by a local SSCS entity when an SPDU is to be transferred to a peer SSCS entity. On receipt of the MESH-DATA.re
44、quest primitive, the mesh sublayer of a device first looks at the value of the DstAddrMode field. If the value indicates a 64-bit extended address is used (0x03), the data may be sent to its one-hop neighbors only. Therefore, the mesh sublayer should compose an MCPS-DATA.request and send it to the M
45、AC layer. In this case, the mesh sublayer simply passes the request from the higher layer without calling the mesh sublayer functions. b0 of the TxOptions field of the MCPS-DATA.request primitive should reflect the value of AckTransmission; it is set to one when the AckTransmission field is set to T
46、RUE and set to zero when the AckTransmission field is set to FALSE. Fields b1 and b2 of the TxOptions of the MCPS-DATA.request primitive should always be set to zero. The rest of the transmit option fields, McstTransmission, BcstTransmission, and ReliableBcst, are created to indicate to the mesh sub
47、layer the transmission mode of the data. Therefore they are only meaningful to the mesh sublayer and should not be reflected in the MCPS-DATA.request primitive. If the value of the DstAddrMode field indicates a 16-bit short address is used (0x02) the destination could be either a one-hop neighbor or
48、 a device multiple hops away. Therefore, the device should first determine whether the destination is one of its one-hop neighbors by looking at the DstAddr and searching the destination address in its neighbor list as illustrated in Table 46. If it is, the mesh sublayer should compose an MCPS-DATA.
49、request and send it to the MAC layer as described above. If the destination is not a one-hop neighbor, the mesh sublayer should determine the next hop in the mesh network to route the data message to its final destination. The mesh sublayer should first compose an MHPDU to transmit the SPDU received from SSCS as described in 5.3.2.1. The mesh sublayer should then look up the next hop toward the destination using the method described in 5.5.5 and compose an MCPS-DATA.request with the MAC layer destination address set to the address of the next hop. The M
