As I see it, the write-group service is an important part of BACnet's lighting control solution. In its absence, there is little to be done to ensure timeliness of lighting control.
But as you have noted, if insufficient forethought is given to its deployment, there will be signficant repercussions.
Instead of using global broadcasts, I think that the use of network directed broadcasts is desirable (did we not make changes to the addenda to make this clear). When engineering lighting installations it would make sense to take into account the needs of lighting and structure the networks such that related lighs are located on the fewest number of BACnet networks as is possible.
For B/IP, it would be best to split the network into multiple B/IP networks for the purpose of constraining broadcasts. Instead of having a monolithic B/IP network, use B/IP to B/IP routers in place of BBMDs and cut down on the propogation of broadcasts.
And don't use ZigBee. It was a mistake to include it as a datalink in BACnet; it should included into BACnet networks via gateways, not as a first class citizen.
Christoph Zeller <christoph.zeller@...
Dear members of LA-WG.
attached you find my thoughts about the proposed write-group service
Issues with Write-Group service.
If I remember correctly, the original use-case for the write-group service was tunneling DMX commands through BACnet.
In this scenario, a large group of lights shall immediately follow a human interaction (e.g. a Fader is moved and the lights should follow the faders position)
The service was then extended with coercion rules to have a wider scope.
If the service is used as a Unicast, there is no real advantage over existing write-property service (assuming that the device internally distributes the command received to its target).
Broadcasting on the other hand is distributed to all nodes withing scope.
The goal has to be that those devices listening to a particular group have to be reached.
This can be achieved using broadcasts but at a potential high cost. All targets are receiving it, so we are flooding the network with such messages.
The amount of flooding is determined by how often the service is used. As buildings grow, so will the number of occurencies.
For example, if a wall-switch triggers such a service once an hour, 1000 wall-switches will do it every 3.6 seconds (on average).
Therefore this can easily reach the networks capabilities.
There are now 2 problems:
1) Some networks are more vulnerable than others
2) If the traffic is too high, messages will finally be dropped by network equipment (e.g. routers)
In a Zigbee network, a Broadcast needs to be repeated by every Node (Mesh Network topology)
In an BACnet-IP Ethernet Based Network, a broadcast is redistributed by BBMDs and every Switch of the underlying Ethernet network.
In both cases, Broadcasts have a significantly higher cost than a unicast message.
In MSTP Networks, the amount of network traffic is independent of whether the message is unicast or broadcast (shared media).
Sauter Head Office
Fr. Sauter AG
Im Surinam 55, CH-4016 Basel
Telefon +41 (0)61 695 55 55
Telefax +41 (0)61 695 56 19
This communication, and the information it contains is for the sole use of
the intended recipient. It is confidential, may be legally privileged and
protected by law. Unauthorized use, copying or disclosure of any part
thereof may be unlawful. If you have received this communication in error,
please destroy all copies and kindly notify the sender.
Before printing out this e-mail or its attachments, please consider whether
it is really necessary to do so.
Using less paper helps the environment.