This section contains the low speed network layer definition for xPL. The xPL message schema and application behaviors are the same as for xPL but the network access is inherently different since broadcast messaging is both difficult to implement and highly inefficient for low speed networks. Using unicast messaging for xPL violates some of the assumed tenants of the xPL specification, however a strict implementation of the xPL network layer is incompatible with most low speed networks. As an example only a few broadcast messages / second will bring a Zigbee network to a crawl.

The network layer is responsible for and defines:

• Mapping xPL targets to Network Layer addressing
• Routing of messages between exPL network layers
• Routing of messages between exPL application layers (eHub)

The network layer is, by design, completely independent from the underlying transport network types.

Network Layer Addressing

Each network layer has specific addressing requirements so that nodes can be uniquely identified on the network segment. For xPL the network layer addressing was handled by IP and Ethernet; xPL had no knowledge of those addresses because every message was a network layer broadcast. The exPL specification adds unicast messaging directly between two exPL nodes, replacing broadcasts. Unicast messaging requires that the exPL network layer have knowledge of the network layer addressing. Network layer address resolution is also required. This primarily affects the Network Layer which must maintain the network address of all devices on the low speed network. Each low speed network device will be required to store the network address for the default next hop toward the Low Speed Gateway as well as learn the network addresses of applications connected to the network layer. The specifics of network layer address assignment is covered in the MAC Layer specification for each network transport defined.

Network Layer Entity Definitions

The exPL network layer is responsible for translating the xPL application behaviors to network transport independent behaviors. A new network layer is needed because the xPL network layer (primarily the Hub and application socket bindings) assumes Ethernet. Ideally the xPL network layer and the exPL network layer could be combined, but this would require slight modifications to the existing xPL specification which in turn would require slight modifications to ALL existing xPL applications. Given this undesirable option, exPL will define a new network layer and exPL applications will behave slightly different from xPL applications when accessing the network layer.

The exPL Hub (eHub) is fundamentally part of the network layer and its behavior is specified here

NLME: Network Layer Management Entity

The NLME is responsible for managing the client registration process. At start up each MAC layer and each application must call the registration function and provide a pointer to the client's data reception callback function. In addition exactly one network client may call the gateway registration function providing a pointer to the client's data reception callback function and the next hop network address for default forwarded messages. The NLME must support the following NLME-SAP primitives:

• Client registration requests
• Client deregistration requests
• Gateway client registration requests
• Gateway client deregistration requests

Forwarding Information Base Maintenance

The NLME must permit exactly one client to register as the gateway client. In addition to its message reception call back function, the gateway client must supply the default nexthop network address to use when sending messages. When the gateway client registers, the FIB must be populated with a default target entry that matches all messages. The entry must be removed when the deregistration function is called.

NLDE: Network Layer Data Entity

Forwarding Information Base Maintenance

In addition to the static FIB entries maintained by the NLME, the NLDE must populate the FIB automatically by adding entries when forwarding heartbeats received from clients. The source and group attributes in the received heartbeat messages must be added to the FIB if not already present; if an entry is already present the age must be reset to zero. Finally there must be a mechanism to age out old entries.

Message Forwarding Logic

The NLDE is responsible for routing messages between the registered clients. For the exPL low speed networks the message routing topology is a branched tree where end nodes only transmit toward the LSG node (root).

When forwarding messages the NLDE must identify the network address or addresses of each matching target by looking in the FIB. A message must be forwarded, separately to each unique network address; there may be more than one match especially for group addresses. Matches must always be exact matches. Implicitly a message with target=* will always match only the gateway client entry in the FIB. In addition a copy of the message must be forwarded to the gateway client using the gateway client entry unless the message was received from the gateway client or is already destined for the gateway client. This last requirement ensures that all xPL messages are sent out to the high speed (Ethernet) side even if the source and target are both on the low speed side of the network.

NOTE: The NLDE will NOT echo messages back to the caller like in xPL! This choice was made to reduce the processing overhead for resource constrained devices. This affects Application start up since xPL applications listen for their own heartbeat from the hub before starting normal operation. The LSG will provide the necessary echo for heartbeats.

Message Transmission

The NLDE receives messages from applications and the MAC layers and transmits those to a registered client based on the forwarding table. Each MAC layer and application must call the NLDE transmit function when sending an xPL message. When the transmit function is called the NLDE must look for matches in the FIB based on the xPL target and call the client's callback function for each matching entry found. To prevent blocking the callback functions should not take long and should only store a copy of the message parameters before returning if more time is needed to act on the message.

Implied Behavior

A Network Layer may have multiple MAC layer clients especially in the LSG node. The NLME behavior described above gives rise to the ability to transit xPL messages through multiple Network Layers as needed to reach the intended target.

NLIB: Network Layer Information Base

The NLIB must store the client registration table and the Forwarding Information Base (FIB). The client registration table must contain a client ID and the client's callback function. The FIB must contain a unique entry for each xPL target, client ID, and nexthop network address.