Back to Home

Network infrastructure of RTLS systems

IEEE 802.15.4 · Zigbee · sensor network · mesh network · mesh network · protocol stack · routing algorithm · Smart Energy 2.0

Network infrastructure of RTLS systems

    Before continuing the discussion of the main features of ZigBee networks, I want to insert a small remark.
    What I wrote about in the previous topic and intend to continue on this refers to the ZigBee Pro Feature Set 2006 standard approved in 2007. This specification already contains all the basic features that make ZigBee networks the most preferred option for creating sensor networks for various purposes, and namely:
    1) self-organization and self-healing,
    2) structural flexibility - the ability to create networks of different topologies - star, tree, mesh network,
    3) the choice of routing algorithms, depending on the requirements of the application,
    4) the mechanism m application standardization - application profiles, clusters, endpoints, bindings,
    5) a flexible security mechanism,
    6) low power consumption,
    7) ease of deployment, maintenance and modernization.

    But this does not mean that life has stopped.
    Back in 2008, in order to ensure the operation of the Home Area Network (HAN) based on IP, the ZigBee alliance began work on expanding its standard - the Smart Energy 2.0 profile. The profile includes support for any transport layer based on IP-compatible standards, including ZigBee IP and other transmission technologies - both radio frequency and power wiring - Power Line Carier (PLC).


    The profile provides interoperability between ZigBee and other network technologies. The ZigBee Alliance is developing a network layer of the Internet Protocol (IP), called ZigBee IP, and is based on 6LoWPAN technology (IPv6 over low-energy wireless personal area networks). The public discussion of the latest working version (draft 0.9) of the Smart Energy 2.0 profile ended on August 25, 2012. The final version is expected in the near future.
    But now there are many network devices that support ZigBee IP, for example:


    ZigBee Gateway - Ethernet


    ZigBee Gateway - WiFi - Ethernet


    ZigBee - USB Adapter /




    ZigBee Gateway - Ethernet + CSS RTLS interface
    The relatively large dimensions of the device are explained by the fact that it is made in dust and a waterproof housing and has a built-in uninterruptible power supply for 8 hours of operation. The Ethernet interface can be either electrical or optical — optional. More details here: www.rtlsnet.ru/products/product/4 .

    By the way, Smart Energy is by no means the only extension of this rapidly evolving standard, you can still find many interesting topics related to ZigBee networks, but for now “back to our sheep.” We continue the discussion of the fundamental features of ZigBee from where we left off - from the protocol stack. Figure repeat:



    ZigBee protocol stack

    ZigBee Protocol Stack


    The ZigBee protocol stack has four layers: APL — the application layer, NWK — the network layer, MAC — the medium access layer, and PHY — the physical layer. As usual, higher protocols use the services of lower ones.
    The application layer and the network layer are regulated by the ZigBee specification, the lower layers - MAC and PHY are regulated by IEEE 802.15.4.

    The APL application layer includes the Application Framework, the ZigBee Device Object (ZDO), and the Application Support Sublayer (APS).
    The application farm describes the procedure for creating profiles and defines standard data types, descriptors, frame formats and key pair values, and also includes application objects (there can be up to 240 of them in the device).
    Application objects- software modules that control ZigBee devices at endpoints. We’ll talk more about this when we look at application profiles, endpoints, clusters, and bindings.
    A ZigBee Device Object (ZDO) determines what role a device plays in a ZigBee network: a coordinator, router, or end device. ZDO
    initiates and responds to join requests, and establishes secure communication between devices.
    Management Plan ZDO (ZDO Management Plane) communicates with sublevels ZDO APS and NWK, ZDO enables applications to handle requests for access to the network and provides security.
    Application Support Sublayer(Application Support Sublayer - APS). He is responsible for providing data to applications, manages network connections and stores data about connections in a table.
    The Security Service Provider (SSP) is configured by the device object and provides security mechanisms for encrypted layers - NWK and APS.

    The Network Layer (NWK) processes network addresses and routing for MAC layer calls. In addition, the NWK starts the network if the device is the coordinator; Assigns network addresses Adds and removes network devices routes messages; applies security policy; searches for routes.

    Medium access control layer(Medium Access Control Layer - MAC) provides reliable communication with neighbors, helps resolve conflicts and increase efficiency. The layer is responsible for assembling and decomposing data packets.

    The Physical Layer (PHY) provides a radio interface. The physical layer includes two layers operating in different frequency ranges. One level covers the ranges of 868 MHz for Europe and 915 MHz for the USA and Australia. The second operates at a frequency of 2.4 GHz and is used almost throughout the world.

    Access Points
    Communication between the elements of the ZigBee protocol stack is through service access points (SAPs), as shown in the figure.

    Stack profile


    The stack profile sets the network parameters - its type (topology), sizes, supported routing algorithms, application services, sizes of routing tables and application bindings, security settings, etc. The stack profile of a particular ZigBee network is programmed by the network designer (administrator) based on the specifics of the application.
    For example, the network topology is determined by three parameters: the maximum network depth (nwkMaxDepth), the maximum number of router child connections (nwkMaxChildren), and the maximum number of child router connections (nwkMaxRouters). The exact structure of the ZigBee network depends on the location of the devices and the propagation of radio waves at the time of formation of the network and therefore cannot be unambiguously predetermined. But the mentioned parameters of the stack profile impose certain restrictions on the network structure.
    For example, if in a particular application the devices must be physically located in a line (along the conveyor or power line poles), it is enough to assign the parameters nwkMaxChildren = 1 and nwkMaxRouters = 1 to get the linear structure. Values ​​nwkMaxDepth> 1, and nwkMaxRouters> 0 will give a tree structure, and nwkMaxDepth = 1 and nwkMaxRouters = 0 will give a star.


    Wire mesh


    In a mesh network, each router is connected to at least two others and can broadcast messages of immediate neighbors along a given route. Figure 3 shows an example of a mesh network consisting of a coordinator, five routers, and three end devices.
    In a mesh network, each of the devices can communicate with any other device either directly or through intermediate devices, that is, using multi-hop communication.
    Multi-step transmission helps maintain network survivability (self-healing). If a device fails, becomes unavailable due to interference, or simply reboots, packets are routed through the remaining devices.



    ZigBee Mesh


    Routing on ZigBee Networks


    ZigBee networks use several routing algorithms. The selection of allowed algorithms is programmed in the stack profile, depending on the purpose of the network. The selection of a specific algorithm from the number of allowed occurs automatically, depending on the state of the network and current conditions.
    The Ad hoc On Demand Distance Vector (AODV) algorithm is the main algorithm in ZigBee networks. The search for the route from “source” (I) to “destination” (A) in this case occurs as follows (illustrated by the figures):
    Step 1 - the source sends a broadcast “route request to A”.


    Step 2- each device that received a route request makes an entry in its routing table and broadcasts the request, including its record in the payload. The record indicates the "logical distance" from the sender of the request to its recipient. The "logical distance" (LR) takes into account the quality of communication between the sender and the recipient of the request. The following devices, having received the relayed request, add their record to the packet and broadcast it further. The "logical distance" increases with each step. This continues until the request reaches destination A. In a mesh network, the request reaches the destination in many ways. Obviously, the “logical distances” recorded in the queries turn out to be different.




    Step 3- Destination A sends a response to the device from which the packet with the minimum “logical distance” came. This device does the same with the packet, and so on, until the answer reaches source I. The answer will be returned along the optimal (with the minimum “logical distance”) path previously passed by the request.



    Step 4 - the answer, returning along the optimal path, forms a table of the direct route of packet transmission from source AND to destination A.



    The described algorithm is universal and allows you to choose the optimal routes. However, its implementation requires a significant amount of device memory to store route tables. In addition, significant network traffic is required to search for routes in branched networks.
    Therefore, in ZigBee networks an alternative algorithm is implemented that allows saving memory. The algorithm is based on the fact that network addresses in ZigBee are distributed hierarchically. Devices that are not endowed with the ability to route using the AODV algorithm, and devices with exhausted routing capabilities, can use hierarchical routing - less efficient, but quite practical.

    Hierarchical routing
    When forming a ZigBee network, the coordinator and then the attached routers assign address ranges to the child devices in a hierarchical order. As a result, each device can determine whether the recipient address of the forwarded packet belongs to any of its “child” branches or is located in another part of the network. Accordingly, the device can transfer the packet to the child device, the address range of which includes the recipient address, or up.
    For the example in the figure below, the packet is sent by source AND to A. However, unlike the case considered above, device 4 does not have enough memory for the route table. Not knowing the optimal route to destination A, device 4 uses hierarchical routing and sends the packet “up” to device 2. Next, the packet is transmitted to coordinator K, which sends it to address A.
    Hierarchical routing is simple and does not require memory for the routing table. This allows low-cost devices that do not have routing tables to participate in the ZigBee network. The disadvantage of this algorithm is that it extends the packet path even if there is a direct connection between the source and destination.




    Hierarchical routing

    Routing to the aggregator (Many to one)
    In many wireless applications, there is an aggregator device that collects data from other network devices. To save traffic, the ZigBee PRO specification provides a special broadcast route request. Directed by the aggregator, this query allows you to create records in the routing tables of all routers in the network with the aggregator as the recipient.

    Explicit routing.
    With explicit routing, the entire path of the packet is indicated by the sender directly in the packet. To save money, the route in the package can be partially indicated.
    Explicit routing allows you to forward packets through a number of inexpensive devices that do not store routing tables, but reduces the payload, so the route length with explicit routing is limited to five nodes.

    I will stop here for now. In the next topic, I’ll talk more about application profiles, clusters, endpoints, bindings, and also a little about security mechanisms.

    Read Next