April 2011
Article
AutomatedBuildings.com

[an error occurred while processing this directive]
(Click Message to Learn More)



852 Lon over IP
The goal of this article is to explain some of the beneficial features of 852 for LON/IP tunneling and how it can be applied to BAS integration.
 
Samuel M. Smith, Ph. D.
President and founder
Adept Systems Inc. (ASI)

1.  Introduction

Articles
Interviews
Releases
New Products
Reviews
[an error occurred while processing this directive]
Editorial
Events
Sponsors
Site Search
Newsletters
[an error occurred while processing this directive]
Archives
Past Issues
Home
Editors
eDucation
[an error occurred while processing this directive]
Training
Links
Software
Subscribe
[an error occurred while processing this directive]

1.1.  Why 852

As building automation networks continue to expand in size and complexity the ability to employ building information technology (IT), internet protocol (IP), based infrastructure becomes an important part of a successful integration task. Whether the building automation system (BAS) leverages existing infrastructure or has a dedicated side-by-side system, IT components provide scalability, remote accessibility, and portals into building management systems.

Several different terms are used to refer to non-IP based automation networks such as fieldbus. In this article we will use the term component network (CN) as a generic description for a network channel whose primary purpose is to connect sensor, actuator, and control endpoint devices. The first requirement for a CN to be able to leverage IP, is a means for tunneling the CN over IP. The technique of using another protocol to transport a message over an alternate media is often referred to as tunneling.

Many of the popular CN protocols such as BacNet etc. have a standard IP tunneling approach. Typically the tunneling approach is very basic, consisting of nothing more than direct unicast TCP or UDP socket connections between endpoint gateways. There is no provision for managing the CN specific requirements that may be deleteriously affected by or incompatible with IP networks. Nor is there any kind of routing capability for bandwidth partitioning. Thus the systems integrator is forced into haphazard or site specific setups that are not scalable or robust to changes in the IT infrastructure. Any traffic management must be done with dedicated LAN or VLAN which requires extensive work on the part of the IT staff. As a result the only viable approach is more costly side-by-side implementation.

In this respect, systems based on the ANSI/EIA 709.1 protocol (trademarked name LonTalkŪ ) uniquely benefit because 709.1 over IP tunneling is based on a tunneling standard called ANSI/EIA 852, that is designed specifically to overcome IP specific limitations with respect to CN network behavior.  In other words, 852 makes IP tunneling highly transparent to the attached CN protocol. ANSI/EIA 852 also includes support for a virtual CN channel that makes it easier to integrate into existing IT infrastructure.

A 709.1 network is also commonly referred to as a Local Operating Network or LON. This document will use 709.1 network and LON interchangeably. Both the ANSI/EIA 709.1 and ANSI/EIA 852 are defined by the Consumer Electronics Association Technology & Standards R7.1 HCS1 Subcommittee. For more details see http://ce.org/. The current revision of 852 is 852-B but for the sake of brevity, we will use 852. Also for the sake of brevity the remainder of the document will refer to the standards as 709.1 and 852. When we say LON/IP tunneling we mean tunneling 709.1 over IP using 852. Although 852 is most commonly used for 709.1, it is a generic protocol that could be adapted to other CN protocols besides 709.1.

The important features of 852 that support CN over IP tunneling are as follows:

•    Out of order packet detection and reordering
•    Duplicate packet detection and filtering
•    Packet aggregation
•    Stale packet detection and filtering
•    IP packet authentication
•    Virtual IP/CN channels
•    Multiple devices on a single virtual CN/IP channel
•    Selective forwarding for optimized unicast
•    Multicast CN/IP channels
•    Combined unicast and multicast virtual CN/IP channels
•    Packet segmentation for low latency UDP channel management packets
•    Sever based and manual mode configuration

The goal of this article is to explain some of the beneficial features of 852 for LON/IP tunneling and how it can be applied to BAS integration.

1.2.  IP Tunneling

The 852 protocol acts as the transport service to convey (i.e. tunnel) 709.1 messages over Internet Protocol (IP) networks. As previously mentioned, in 852 parlance the tunneled protocol is a Component Network (CN) protocol. The 852 protocol is a generic tunneling protocol and is not limited to 709.1. However, a particular implementation of the 852 protocol may only support the tunneling of a single CN protocol. The tunneled CN messages have no information or awareness of the tunneling process. Although some of the figures in this document use CN or CN/IP to represent a component network or component network to internet protocol connection, the CN   in this case is 709.1

852 not only provides the vehicle to transport 709.1 messages across IP, but it also provides management of these connections or routes. A logical grouping of 852 devices that exchange packets is called an 852 channel. One may think of an 852 channel as a kind of virtual LAN on an IP network. An 852 device may be a node, router, gateway, bridge, monitor, or some combination of one or more of these devices. The typical use of 852 is that the devices are 709.1 routers that tunnel over IP using 852. These are often called LON/IP or LON/IP-852 routers. Adept SystemsTM, manufactures a LON/IP (709.1/852) router called the GRouter4TM. Additionally other types of devices such as (endpoint sensor, actuator, control) nodes and multi-protocol gateways are starting too appear. Indeed one could potentially build a complete 709.1 system using an IP-852 based channel such as Ethernet or WiFi as the only channel.

Network connection devices can operate at different layers of particular network's protocol stack. 709.1 is an OSI 7 Layer type protocol. Whereas the Internet Protocol has only 4 layers. (See below for a diagram of the different layers of the two protocols.)

Figure 1.1

Fig.1.1:  Network Layers

A network connector is a device that joins different parts of a network. Connectors have a specific name that is dependent on the layer at which the connector operates. For example a router operates at the network layer and a gateway operates at the application layer. Because higher layers of the protocol do not have access to some of the information stripped away by lower layers, network connectors operating at different layers have different capabilities. There is also some abuse of terminology so that the descriptions of network connectors from different manufacturers may be confusing. For example, a repeating router may be called a repeater. Although a repeating router acts similarly to a physical layer repeater, it operates at the network layer and is not equivalent. Getting the terminology right, requires knowing which layer a network connector operates.

Network Connector Types
Fig.1.2:  Network Connector Types and Associated Layers

1.3.  CN/IP Device Architecture

The CN/IP device is a more complex connector because is connects two different protocols and may also connect the protocols at different layers. On the IP side, a CN/IP (LON/IP) router operates at the application layer and so is appropriately called an IP Gateway. On the 709.1 side the CN/IP router device operates at the network layer and is appropriately called a 709.1 router. So depending on the user’s perspective a CN/IP device could be called a gateway or router or a router/gateway. The typical approach is to name the device from the standpoint of its behavior on the CN side, that is a CN/IP router. This is the convention used to to name Adept's GRouter4. In the past we named the device from the standpoint of its IP behavior, hence the GadgetGateway I. A block diagram of two CN router / IP gateways connected via IP Ethernet is shown below.

Network Tunneling
Fig.1.3:  CN to IP Router/Gateway Architecture 

A CN/IP router forwards 709.1 packets to or from an IP channel (using an Ethernet or WiFi transceiver) and a CN channel (using twisted pair FT-10 or other transceiver). The CN/IP router has a presence on, or physical connection to, both channels. The router takes 709.1 messages from the component network, wraps them in an 852 packet and sends them over the IP network. The device also receives 852 packets on its IP interface, unwraps them, and puts the 709.1 messages on the CN channel. The virtual 852 channel looks like a CN channel to CN nodes. The IP element is transparent. This enables a "flat" (single protocol for endpoints) network and is more easily managed and scaled than using CN to IP interfaces that do not hide the IP element from the CN nodes. The important thing to the systems integrator is not so much what the CN/IP device is called but how transparent it makes the IP network appear to the CN nodes. Typically a CN/IP router also also employs a web server for configuration purposes. The block diagram is shown below.

GRouter 3 Architecture

Fig.1.4:  GRouter 3 Architecture

1.4.  852 Protocol Packets

Two types of packets are used by the 852 protocol. These are CN Data packets and Channel Management packets. Both packets use a common packet header. The payload of a CN Data packet is the 709.1 LPDU (Link Layer Protocol Data Unit) (See diagram below). The payload of a Channel Management packet is configuration information for the 852 devices. There is some important terminology needed to understand how to deploy an 852 based system which we cover in the next section.

852 Protocol Packets

Figure 1.5 852 Packet Header 


1.5.  852 Configuration

852 management packets provide both device parameters and channel parameters. Device parameters include information such as: IP address, IP port, name, and address of configuration server. A channel is a logical grouping of 852 devices that all can send information to each other. The lines of communication are open in both directions and to all members—a complete mesh of connections.

Typically, channels are managed through the use of a configuration server. This is called "normal " mode. The configuration server informs all members in the channel about the channel information, which includes the adding and removing of channel members. Configuration servers are capable of managing multiple channels, while 852 devices, such as routers, belong to only one channel at a time.

The other management mode for 852 channels is called "manual" mode which does not use a configuration server.  In a manual configuration, the channel members IP address information is manually entered into each device. Typically devices must have mutual membership in each other’s channel lists. That is if Device A is in Device B’s channel list, then Device B must be in Device A’s channel list.

An 852 device may support one or both management methods. There are advantages and disadvantages to each management method. Normal mode is more automatic and typically the configuration server can provide channel diagnostics. Manual mode has the advantage of being stand alone and can be useful for handing some difficult channel setups or for making a totally transparent CN bridge over IP. Currently the Adept GR4 is the only router that supports both normal and manual modes.

[an error occurred while processing this directive] 2.  Applications of the CN/IP Routers

There are two primary applications enabled by 852 CN/IP routers. These are remote connection s of multi-site or multi-building CN networks over a WAN and using an IP network LAN as a high speed backbone for a CN network.

2.1.  Multi-site building automation networks over an IP WAN

Once of the complications when tunneling CN protocols over an IP WAN is that there is no guarantee that packets won't take more than one router through multiple IP switches and routers endemic to IP WANS. When this happens packets can get out of order. This can be problematic for an automation network depending on the type of messages being sent. 852 provides a solution for this problem by sequentially numbering CNData packets between 852 devices. This way an 852 router can detect and reorder CNData packets before forwarding them onto the CN channel. The escrow time used to hold out of order packets is tunable for the WAN delays. Stale packet detection also helps in the rare case that a packet is delayed but not out of order. In addition, because 852 provides channel management of virtual channels, one can mix and match devices from different IP subnets all on the same channel. This makes it convenient to integrate devices from remote locations in multi-building or multi-site automation networks. Having remote IP WAN support also means that one can do remote protocol analysis of a CN channel. Adept's free download GadgetAnalyzer software is a Windows based protocol analyzer that works with Adept's GRouter4.

Although the 852 standard does not have a standard approach to handing NAT, all the commercially available CN/IP routers have a NAT solution. This has become standardized in the next generation 852.1 protocol.

In addition some WAN channels have limited bandwidth, so the packet aggregation feature of 852 enables packing many CN packets into on larger IP packet to reduce traffic. The Adept GR4 router even has an optional low bandwidth serial transaction mode to limit the bandwidth consumed by management packets. Moreover, the 852 md5 authentication provides security over open WAN networks to prevent spoofing or reception of fake sensor data or actuator commands. These are all features that other CN tunneling approaches have to add on a vendor by vendor basis. Because IP WiFi is an inexpensive and ubiquitous technology, 709.1 networks can leverage this through 852 in applications where no extant wiring is available. There is a also a compact WiFi enabled version of the Adept router, but any of the LON/IP routers can be used over a WiFi channel with the addition of an inexpensive WiFi to Ethernet router access point. One advantage of using 852 on an IP WiFi network is that one can now have roaming connections which can be advantageous when doing network setup and debugging tasks.

Multi-site building automation network
Fig.2.1:  Multi-site building automation network with internet connectivity 

2.2.  IP LAN for high speed CN backbones

Since IP Ethernet LAN channels, such as 100/1000 Base-T, can support much higher traffic speeds than CN channels, they are well suited as a backbone for large CN installations. This also makes it easy to attach monitoring and management tools. They just need an 852 interface. An example is show in the figure below.

IP Lan for CN/IP Backbone
Fig.2.2:  IP LAN for CN/IP Backbone 

When building 852 channels with a large number of devices there is a potential problem with using IP. The typical IP packet is sent unicast. This does not match how CN channels work very well. Most CN channels are multi-drop shared channels where any packet on the channel can  be seen by any of the devices. This is not true with IP Unicast. The IP stack will drop any  unicast packets not addressed to the receiving host. This means, that in order to replicate the multi-drop nature of the CN channel, multiple unicast messages must be sent, potentially one for every device in the 852 channel. This causes an exponential explosion in traffic. Say for example, you have 64 devices in the IP-852 channel, every CN packet on the CN side could become 63 IP packets on the 852 side. This is an exponential increase in the traffic that can quickly overwhelm the IP stack on the CN/IP routers. The 852 protocol manages this problem in several ways.

The first method is through selective forwarding. When selective forwarding is supported, each of the CN/IP routers in an 852 channel gets a copy of the routing tables for all the other routers on the 852 channel. Each router, when forwarding a packet, checks the destination address of a packet received on its CN side against the routing table of each of the other 852 routers to see if a particular router would forward the packet across to its CN side. If not, then the originating router does not send the IP packet. This minimizes IP side traffic on 852 channels with configured routers. Only broadcast CN packets get sent to all the 852 routers.
The second method that 852 can use to manage IP traffic is by using IP multicast. With IP multicast addresses, all the devices can share a common IP address that the IP stack will propagate up to the application. Thus if an 852 channel needs to support CN networks with a lot of peer-to-peer traffic between CN channels or a lot of broadcast messages, the 852 channel could  use IP multicast instead of, or in addition to, unicast. The following figures illustrate the differences between multicast and unicast.

Unicast
Fig.2.3:  Unicast 


 Multicast
Fig.2.4:  Multicast

The third method 852 can use to manage IP traffic is the aforementioned packet aggregation. The maximum un-fragmented UDP packet size is 548 for a typical IP header. This is much larger than the typical CN packet. Since 852 can aggregate multiple CN Data packets into one IP packet,  the exponential increase in unicast traffic can be significantly reduced. 

For CN Data packets 852 uses UDP which is a low latency protocol much better suited to the low latency typically expected on CN channels. For channel management packets, 852 can use either TCP or UDP packets. Because TCP is more complicated, UDP is the usual. But UDP has one drawback for large numbers of 852 devices on a single channel, that is, the size of a management packet can get bigger than 548 bytes. For this reason, 852 supports segmenting of 852 management packets when using UDP. This provides a lightweight facility similar to TCP.

2.3.  852 to 852 Bridging Router

Because 852 is a full featured tunneling protocol, it can be repurposed to solve some uncommonly difficult integration problems. The 852 protocol is not limited merely for routing from a CN channel over IP to another CN channel. But can be used to build multi-tier backbones on IP with routers that route from one IP-852 channel to another IP-852 channel. This can be used to support backbones with more than the maximum number of 852 devices on a single 852 channel. The maximum number of 852 devices on a channel is 256 but practical bandwidth limitations of the individual devices means the practical limit is much lower. The block diagram of an 852 to 852 bridging router is shown below.

Bridging Router
Fig.2.5:  852 Bridging Router Architecture 

If both 852 channels share the same IP channel then this is called an 852 to 852 bridging router.  In this mode one 852 bridging router is an IP bridge between two logical 852 channels. So it looks like a CN router to any CN devices. When acting in bridging router mode, the router is a member of two logical 852 channels sharing one ethernet interface. The router bridges traffic between the two 852 IP channels. This allows one to overcomes limitations on the number of 852 devices per channel and provides for enhanced scalability by partitioning the 852 traffic seen by any given router. Moreover on a WAN where some IP channels are very low bandwidth such as a cellular network and some high bandwidth, this allows partitioning of the high bandwidth 852 devices from the  low bandwidth 852 devices. The Adept GR4 uniquely supports 852 bridging router mode.

2.4.  CN over IP Bridging

Another difficult integration problem is for legacy LON network management devices that do not support LON routers. This prevents connecting remote LON channels using CN/IP routers since there is no way to configure the router. Another application is where the remote CN channels want to share the same subnet, have low traffic, and it is advantageous to have the quickest and easiest setup possible.

There are two solutions to the former problem. One solution is to use a manual mode CN/IP router that supports manual configuration of the router as a repeater. The other solution which solves both the former and the latter problems is to bridge the CN networks over IP, that is, use 852 as a physical layer CN Bridge over IP. This provides a totally transparent way to  connect remote CN channels over IP. Since a bridge operates at the physical layer there is nothing to configure on the CN sides. The IP side can be simply configured using the 852 manual mode. Used this way all the CN traffic is automatically forwarded or "flooded" to all the other 852 devices. This has the drawback that it is not scalable to large installations with lots of 852 devices. For applications, however, where only a handful of CN channels need to bridged, bandwidth is not a problem. The Adept GR4 router also provides a "flood" or CN over IP bridge mode.

3.  Conclusion

As this article has outlined, the open 852 standard protocol provides many beneficial features for tunneling CN protocols over IP. Because tunneling 709.1 over IP-852 is supported by multiple choices for commercially available routers, the LON systems integrator has the capability to leverage building IT infrastructure much more conveniently and potentially more cost effectively than other BAS CN protocols.

Moreover, a next generation 852 protocol has been developed called 852.1. Although as of yet no devices support 852.1, it provides a roadmap to enable more enhanced features. The primary enhancements in 852.1 include:

•    Better support for dynamic IP addressing
•    Standard NAT router support
•    Better scalability and tunable performance for large networks
•    More optimal selective forwarding
•    Better use of multicast including support for hybrid multicast/ unicast channels
•    SHA2 Authentication with support for more advanced authentication as needed
•    More flexible  configuration services
•    Improved transaction system
•    Completely modular design that simplifies the process of supporting new CN protocols or new features.
•    Eventual support for IPV6

About the Author

Samuel M. Smith, Ph. D. Is the President and founder of Adept Systems Inc. (ASI). Adept is a technology manufacturing, research and development company focused on  networked intelligent automation systems. Adept specializes in standards based automation technology including but not limited to Internet, ANSI 709.1 and ANSI 852. ASI manufactures LON over IP routers. Dr. Smith currently serves as chairman of the 852.1 working group on the EIA committee for the EIA/ANSI 709.1 and 852 networking protocols.

footer

[an error occurred while processing this directive]
[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]

Events

Want Ads

Our Sponsors

Resources