The exPL LSG (Low Speed Gateway) creates an xPL message gateway between devices on the xPL IP/Ethernet network and devices on one or more exPL low speed networks. The LSG is both a xPL and exPL application adhering to all the rules for applications in both specifications. On the xPL side the LSG joins and leaves the network using the methods described for applications in the xPL specification. On the exPL side the LSG joins and leaves the network using the exPL methods described for applications in the exPL specification.

Gateway Types

This informational section will provide a bit of context for the description of the Low Speed Gateway. In xPL there are at least two categories of gateways. Low Speed and High Speed; in this specification the distinction is between a gateway defined by this specification (i.e. Low Speed) and a gateway that interconnects Ethernet segments (High Speed). While the Low Speed definition will support several types of low speed network hardware, the high speed is only known to be interesting to Ethernet. This specification will only provide details of the low speed gateway.

exPL Low Speed Gateway

A low speed gateway is capable of forwarding xPL messages between one or more low speed networks and one high speed network. The low speed gateway definition will not cover forwarding between high speed networks.
NOTE: When building a low speed gateway the concept of having a low speed gateway in a PC (Ethernet to P2P) connected to another low speed gateway in an embedded device (P2P to Zigbee/RS485) does not impart any advantage in terms of architecture, implementation cost, or code reuse. In this scenario the most reasonable approach is to place the entire Low Speed Gateway implementation in the PC device and only provide a physical layer interconnection to the low speed network hardware; possibly using RS232 or USB.

xPL High Speed Gateway

A high speed gateway forwards xPL messages between two or more high speed network segments without filtering. This gateway requires logic that prevents looping of messages, but otherwise does not filter messages. xPL high speed gateways are not covered here.

LSG Forwarding Information Base (FIB)

The LSG FIB must be used to determine which messages on the high speed network should be forwarded onto the low speed networks. The LSG design filters messages so that only messages targeted to a device on the low speed side will be transmitted on the low speed side and the FIB must contain all of the rules used by the LSG for making this decision. The FIB may be configured manually by adding static rules and must automatically learn new rules for applications on the low speed networks.

Manual Configuration

The LSG must support manually added rules. These rules must allow specification of the target and schema both of which must support wildcards.

Learning

The Low Speed Gateway must populate a forwarding information base (FIB) of learned targets. The FIB must be populated by recording the source address of heartbeat messages seen on the low speed side of the network. The target and group attributes of each heartbeat message will be used to insert new FIB entries if they do not already exist or update the entry age if the entries already exist. FIB entries are removed using a timer based aging process and upon reception of hbeat.end messages.

xPL and exPL Target Addressing

The xPL standard defines two types of addressing, single instance and group. The instance and group IDs can be reconfigured by the configuration manager. In addition this exPL standard permits the exPL node to have two instance IDs, 64bit GUID and a configured instance ID. In a departure from the xPL standard, even after the instance ID has been explicitly configured, the exPL node can still be addressed by the 64bit GUID. This results in a total of three classes of instance IDs for a single node, explicitly configured instance ID, 64bit GUID, and one or more group IDs. For the FIB to function correctly all of these addressing modes must be dynamically learned. The explicitly configured ID is easy because it will be specified in the source parameter of all heartbeat messages. However the 64bit GUID and group IDs are not routinely transmitted in the xPL standard. The exPL standard extends the heartbeat schemas to add the guid= and zero, one, or more group= attributes to the header. These parameters are mandatory for devices on the low speed network.

Other xPL Low Speed Gateway Requirements

LSG assumes the low speed side is a stub; only one hardware segment is allowed. As such the router should not forward any messages where hop>1.

LSG must not respond to config.* messages for the low speed exPL based nodes. Each exPL node must be responsible for its own configuration information. However the LSG may support its own configuration items (e.g. baud rate), etc. In this case the LSG must support a unique instance ID and must implement the config.* schemas for its self.

Forwarding

High to Low

The router will learn the targets that exists on the low speed side by recording the source of heart beats. Base behavior will only forward messages across the router to the low speed side if the message is explicitly targeted to a destination learned on the low speed side. A statically configured white list filter can define specific schema types and/or sources that will be forwarded to the low speed side; by default this white list is empty. The LSG MUST not forward messages where target=* to the low speed side.

Low to High Forwarding

The LSG will forward any message received on the low speed side to the high speed side.

Low Speed Application Heartbeats

The LSG is key to the eApp network join procedure. The xPL specification indicates that an xPL application should not enter normal operation until the application hears its own heartbeats. The exPL specification retains this functionality but moves the message echo function from the local network implementation on the device into the LSG. Once an exPL eApp hears its own heartbeat the eApp can be sure that it is not only part of the exPL network but also part of the Ethernet based xPL network. To support this feature the LSG must echo all heartbeats received from the low speed side back to the originator by setting the target attribute equal to the source attribute and sending the packet back to the low speed Network Layer. This is in addition to sending the heartbeat onto the high speed side. Note that the high speed side will echo the heartbeat back to the LSG but the LSG will discard that message because that message has target=*.

Loop Prevention

Any message transmitted by the LSG to the high speed side will be immediately retransmitted back to the LSG by the local xPL hub. To prevent looping the messages, the LSG will insert a via path header with its own source attribute and interface. When forwarding messages, the LSG will check for the presence of the via path header and drop messages whose via path header indicate an interface on the local node.

LSG Required Schema

Send:hbeat.basic
Receive:hbeat.request
Send:hbeat.end

Send:config.basic
Send/Receive:config.list
Receive:config.response
Receive:config.current
Send config.end

xPL Gateways and the Rebroadcasting Dilemma

In general, network gateways for xPL have a dilemma so solve. Because of the way xPL specifies the use of IP/Broadcast and the hub behavior, each xPL application receives a copy of its own messages from the hub. This makes the hub specification very simple while still allowing multiple, unrelated xPL applications on the same PC to freely communicate with each other and with xPL applications on other network hosts. However, this behavior represents a problem when creating a network gateway. When receiving messages from the Hub, the network gateway can not positively identify messages the network gateway just sent to the IP network from messages from other sources on the IP network. This can cause the same message just received from an outside network to be retransmitted back to that network again.

One solution for this dilemma would be to provide a different IP network implementation for network gateways. This would also require special support for network gateways in the Hub implementations or moving the hub functionality into the gateway. xPL specifies that an application like a network gateway must not be part of the xPL hub and the specification only provides one method of accessing the network; described above. The result is that an xPL network gateway must interface with the Hub and IP network using the same interface and behaviors as provided for the xPL applications. However with modification to the Hub specification, the network gateway could be directed to use the Hub to both send and receive IP network based xPL messages. In this way the Hub would know that a packet came from the xPL network gateway and know not to send that message back to the network gateway. In addition to changing the philosophy of the Hub (and some might argue the philosophy of xPL), the solution presented above would require modifications to all existing Hub implementations, or at least the hub implementation on the host running the gateway. Building the network gateway into the Hub might be the best way to implement this solution.

Another solution to this problem would be for the network gateway to add a "path tag" to the header of each message traversing the gateway before broadcasting to the IP network. When the Hub delvers a copy of the same message back to the network gateway, the network gateway would drop the message based on the presence of the path tag. If the network gateway needed to send xPL messages as a standard xPL client (e.g. heartbeats and configuration), the network gateway would simply send the self originated message on one of the high speed network segments without the "path tag". The Hub on that host would return the message to the network gateway which would then forward the message to other network segments after adding the path tag. The approach can be problematic in that some method must be devised to ensure that no two network gateways use the same path tag, otherwise messages that traversed an earlier network gateway might be dropped by the next network gateway.

Currently there is one known xPL network gateway that solves the problem by recording packet check sums for packets that traverse the gateway. Received packets that match a stored check sum are dropped. The check sums are aged out using a fixed aging timer. This method has at least one drawback in that xPL packets are not guaranteed to be different. It is possible that two packets might legitimately arrive at the network gateway in rapid succession with the exact same contents. For example this could happen if xPL was used to communicate IR commands from a remote control where the user pressed volume+ multiple times in rapid succession. Since the check sums are the same for these two messages, subsequent messages are dropped until the packet check sum is aged out. This does not generally seem to be a good solution.

Topology

The loop prevention logic assumes a flat topology where any two networks MUST only be interconnected at one point. If networks are connected using multiple paths, then xPL messages will be retransmitted infinitely. As such the requirement is that low speed networks connected using this specification MUST not be interconnected at more that one point to another network. Low speed networks can be chained together but MUST not loop back on each other. To detect topologies that violate this requirement, the Low Speed Gateway MUST generate an obvious warning message to the user when receiving a packet where a local interface is found in the via path header, but not in the top most entry. This arrangement of the via path header indicates that the message previously passed this LSG and was then forwarded by another LSG before returning to this LSG; (i.e. a topology loop).