Issue
How much ethernet bandwidth do lonworks systems consume using Loytec L-IPs, iLons, etc.?
Environment
-
TCP/IP ethernet network
-
LNS System
Cause
IT professionals will sometimes hesitate to allow the control system to use the same TCP/IP network as the internet, phones, etc. They may ask what the expected bandwidth usage will be before granting access.
Resolution
It is impossible to explicitly state how much bandwidth a LonWorks system will consume on the ethernet. It depends heavily on the amount of LON traffic being sent by the controllers. The routers themselves do not produce traffic, they only pass the traffic onto and off of the ethernet. The traffic is created by the LON devices, Xenta controllers, Vista and LonMaker or other HMIs.
Vista can create a maximum of 15 LON telegrams/second. This is very little traffic with respect to IP bandwidth. Unless you have made bindings into the LNS NI (which we never do in a Vista-scenario, since Vista cannot read these) there is basically nothing at all going out from LonMaker/LNS unless you are commissioning devices. Starting the LonMaker Browser also generates traffic. But this is also normally just in the design phase of the network, not in "operating mode".
SNVT bindings or TAC network variables from one LON network to another over the IP channel also generate traffic. A typical Xenta can produce 2 SNVTs propagation/second and/or maybe 10 TACNV. This is not much (as IP-traffic), but if there are hundreds of nodes communicating simultaneously all passing through L-IP gateways, the amount of IP traffic will grow.
If you are using a Loytec L-IP, it uses a protocol feature called "packet bunching". Before it sends out a packet on the IP side, it waits for an adjustable time (Aggregation Time, default = 16ms) if some packets are following, which have to be sent to the same IP addresses. If some packets are following, it puts the packets in the same IP frame and sends it all together in a single IP packet. The receiving node unpacks it and makes multiple EIA-709 (Lonworks) packets again.