LonWorks Protocol: LonTalk, ISO/IEC 14908, and How the Network Actually Works

Walk into a plant room and you will see three names on the same equipment. LonWorks on the panel label. LonTalk in the manual. ISO/IEC 14908 in the submittal package. They are not three protocols. LonWorks is the platform — chips, transceivers, tools, devices. LonTalk is the protocol those devices speak. ISO/IEC 14908 is the published standard that defines it, and inside the standard the protocol is called the Control Network Protocol, or CNP.

The technology came out of Echelon in the late 1980s. Echelon’s LonWorks business went to Adesto Technologies in 2018, and Adesto went to Renesas in 2020. Most reference pages online still stop at Echelon. If you are specifying hardware or chasing tool licences today, Renesas is where the trail ends.

The names you will meet

Name	What it actually is
LonWorks	The platform: silicon, transceivers, tools, certified devices
LonTalk	The protocol the devices speak
CNP	The name the ISO standard uses for that same protocol
ISO/IEC 14908-1	Protocol stack, all layers
ISO/IEC 14908-2	Twisted-pair channel
ISO/IEC 14908-3	Power line channel
ISO/IEC 14908-4	Carrying the protocol over IP
ANSI/CEA-709.1	The US ratification of the same protocol
EN 14908	The European ratification
LonMark	The certification body and the interoperability rules on top

The four ISO parts were prepared through CEN/TC 247 and adopted by fast-track. Part 2 published in February 2012, Part 1 in November 2012. Compliance may involve patents held by Echelon, and that patent statement sits in the front matter of every part.

No master on the bus

There is no master. Every node is a peer and any node can start a transmission. That is the first thing to get straight, because it changes how you troubleshoot. There is no polling loop to check and no scan cycle to blame.

Media access is a variant of CSMA the standard calls predictive p-persistent CSMA. A node listens first. If it sees no transmission for one Beta1 period, it treats the channel as idle. It does not then transmit immediately. It picks a random delay of a whole number of randomising slots, each one Beta2 wide, from the range 0 to (BL × 16) − 1. If the channel is still idle when that delay runs out, it transmits.

The 16 is the base randomising window. The BL is the interesting part.

Every node keeps a running estimate of channel backlog. When a node sends a packet that will cause replies — an acknowledged multicast to a group, say — it encodes how many replies to expect into the link layer header. Every node that hears it bumps its own backlog estimate by that amount. The randomising window widens for everyone at the same moment, before the flood of acknowledgements arrives. That is the “predictive” part. The backlog starts at 1, tops out at 63, and decays back down when the channel goes quiet.

The payoff is a collision rate the standard states as approximately 1 / 2Wᵇᵃˢᵉ — so roughly 1 in 32 with the base window of 16 — held constant and independent of load, instead of degrading the way plain CSMA does when traffic climbs. That result holds provided each node’s estimated backlog is at least as large as the real backlog, which is what the predictive mechanism is for.

There is an optional priority mechanism layered on top. A channel can define 0 to 127 priority slots, sitting immediately after the Beta1 period. Slots are normally assigned to specific nodes rather than contended for. A node with a slot decides message by message whether to use it. Two things worth knowing on site: if the channel has been quiet longer than the full randomising period, access is random and priority buys you nothing; and on a channel with priority slots, a node that sent a packet in the previous packet cycle does not use its normal medium access algorithm in the current one — it uses a modified version instead. Queued messages from one node are deliberately not sent in consecutive cycles, so back-to-back priority messages from the same node do not behave the way people expect.

Beta1 and Beta2 are not fixed numbers in Part 1. They are constraints. Beta1 must cover one bit time plus twice the propagation delay plus the turnaround delay. Beta2 must cover twice the propagation delay plus turnaround. Each channel specification then pins down real values. For the twisted-pair channel: Beta2 is 168 µs, Beta1 is 868 µs on transmit and 895 µs on receive, average packet cycle 4 020 µs, preamble 301 µs, four priority slots.

How a device gets addressed

Addressing is a three-level hierarchy plus a serial number, and the field widths explain most of the limits people run into.

Domain. The top level. The domain field is 0, 1, 3, or 6 bytes. A domain identifier uniquely identifies a domain within some context, and the standard provides 48-bit identifiers for worldwide uniqueness; where the context is narrower — a single building, say — shorter identifiers are fine. A domain is a virtual network, and all communication is limited to a single domain. Two reasons: source and destination addresses of a packet must belong to the same domain, and the protocol stack supports no equivalent of an internet protocol. Routers do not route between domains. Where inter-domain communication is needed, the standard says it must be handled by application-level gateways. A node normally belongs to one domain and may belong to at most two.

Subnet. 8 bits, 1 to 255, with 0 reserved to mean unknown. A subnet holds up to 127 nodes and there is no routing inside a subnet. Subnets are a routing abstraction, not a physical thing. A channel is the physical unit of bandwidth; you can map more than one subnet onto one channel.

Node. 7 bits, all-zeros unused, so 1 to 127 within its subnet. That gives 255 × 127 = 32 385 nodes per domain.

Group. 8 bits, so up to 256 groups per domain. A node can hold zero to fifteen group addresses. Group member numbers are 6 bits, range 0 to 63.

Unique_Node_ID. 48 bits, set at manufacture, never changes. This is a name, not an address. It only ever appears as a destination, and it is how you talk to a device that has not been commissioned yet.

Those components combine into five address formats on the wire:

Format	Pair	Used for
#0	domain, source subnet/node, destination subnet	Broadcast — domain-wide or to one subnet
#1	domain, source subnet/node, destination group	Multicast message or reminder
#2a	domain, source subnet/node, destination subnet/node	Unicast message, reminder, or acknowledgement
#2b	as #2a plus group and member	Group acknowledgement
#3	domain, source subnet/node, destination subnet, Unique_Node_ID	Unicast to an uncommissioned device

In format #0, a destination subnet of 0 means every subnet in the domain. Anything from 1 to 255 hits only that subnet. That distinction matters when you are trying to work out why a broadcast is or is not crossing a router.

What a node accepts depends on its state. An unconfigured node accepts broadcasts and anything carrying its own Unique_Node_ID, and nothing else. A configured node accepts its Unique_Node_ID too, plus messages matching its domain — length and value both have to match — that are broadcast, group, or unicast to it. That the serial-number path stays open after commissioning is what lets a tool reach a device whose addressing you have just broken. A node also drops any packet whose source subnet/node matches its own, which quietly kills a class of loop problem.

The commissioning sequence follows directly from this. Format #0 broadcasts a request looking for uncommissioned devices. The ones that answer get configured over format #3, addressed by serial number. After that they have real addresses and normal traffic works.

State is worth checking whenever a device is reachable but useless. A node reports one of four: applicationless (3), unconfigured (2), hard-offline (6), or configured (4). Only a configured node passes messages up to its application — every other state discards them. A device that answers diagnostics but does nothing with its data is usually sitting in the wrong state, and a checksum error in network configuration memory is enough to drop it back to unconfigured on its own.

Choosing a service type

Four services. Picking the wrong one is the most common design mistake on these networks.

Acknowledged. Sender transmits, receiver acknowledges, sender retries until it has all the acknowledgements or runs out of retries. For a multicast, every member acknowledges. Group size is capped at 64 members for this service.

Request/response. Same reliability shape, but the reply carries data instead of just confirming arrival. This is what a network variable poll uses underneath. One quirk worth knowing: the protocol treats any transaction whose response is longer than one byte as idempotent, meaning the server may execute it more than once. A one-byte response is never executed twice. If a request has a side effect, keep the response to a single byte.

Unacknowledged-repeated. Sender transmits the same message several times and never listens for a reply. No acknowledgement traffic at all, which means the 64-member group limit does not apply — a group can be as large as the domain.

Unacknowledged. Sent once. Nothing comes back.

The retry field is 4 bits, so 0 to 15. Total attempts is retries plus one. The standard caps retries at 15 and then says plainly that 2 to 5 covers almost every real case. It also makes a point most integrators learn the hard way: for a large multicast group, the acknowledgements themselves can eat a serious share of channel bandwidth, and unacknowledged-repeated will often deliver more reliably than acknowledged simply because it does not congest the channel it is trying to use.

Three timers run underneath: a retransmission timer on the sender, a repeat-interval timer for the unacknowledged-repeated service, and a receive-record timer on the receiver. The receiver’s pool of transaction records is finite. When it runs dry, a counter increments rather than anything visible failing, so a node that occasionally drops transactions under burst load is worth checking there.

Network variables and explicit messages

The application layer carries one leading byte that says what kind of message this is. The top bit set means a network variable. The next bit is direction. The remaining bits combine with the first data byte into a 14-bit network variable selector. Other codes cover generic application messages, network management, diagnostics, and foreign frames.

A network variable is a typed input or output on a device. A temperature output on a sensor. A setpoint input on a controller. You connect them at commissioning by giving the output and the input matching selector values and binding them through an address table entry. After that, when the application writes the output, the stack propagates it. No register map, no scaling convention agreed by email.

This is the real difference from a register-based protocol. A Modbus holding register is 16 bits and nothing more; what it means lives in a document. A network variable carries a type that fixes encoding, range, resolution, and engineering unit. Two devices that agree on the type exchange a temperature without anyone deciding whether it is tenths of a degree.

The standard defines what a SNVT is — a variable with agreed-upon semantics that every application interprets the same way — and carries a type index for it in network variable queries, encoded as zero when a variable isn’t a SNVT. What it explicitly puts out of scope is the definition of specific SNVTs. That type library, along with configuration property types and the functional profiles that say which variables a given kind of device must expose, comes from LonMark. The standard defines the mechanism and names the concept; LonMark supplies the vocabulary.

A few behaviours that show up in commissioning:

• Polled variables are not pushed. They only move when someone requests them.
• Synchronous outputs propagate every value the application writes. Non-synchronous ones may skip intermediate values.
• Aliases let one variable answer to several selectors. It inherits length, direction, and type from the primary, and exists to get around selector collisions on a crowded device.
• A turnaround connection is an output bound to an input on the same device.
• An offline node sends no network variable updates. Poll it and you get the selector back with no data — which is also exactly what you get if the selector does not exist, or if an authenticated poll failed. Three different faults, one symptom.

Explicit messages are the other path. They carry arbitrary application data instead of a typed value, and they are what you use for events, file transfer, parameter blocks, or tunnelling another protocol. Every compliant device must be able to receive at least 16 bytes of data plus the type byte. That is a floor, not a typical figure.

Underneath, the link layer runs a CRC-16 with polynomial x¹⁶ + x¹² + x⁵ + 1, register initialised to all ones, computed across the whole network PDU. Anything shorter than 8 bytes is counted as a transmission error.

The twisted-pair channel

Part 2 specifies one channel: free-topology twisted pair at 78,125 kbit/s, Differential Manchester encoded. The vendor world calls it TP/FT-10. Note what is not in the standard — the 1,25 Mbit/s backbone channel is a vendor channel, not an ISO/IEC 14908-2 channel. If a spec says “per ISO/IEC 14908-2”, it means the 78 kbit/s channel.

Free topology means bus, star, loop, or any mix of them, with a single termination that can sit anywhere on the segment.

	Free topology	Bus topology
Terminations	One, 52,3 Ω	Two, 105 Ω, one at each end
Max node-to-node	250 m	—
Max total wire	450 m	—
Max bus length	—	600 m
Max stub	—	3 m

Node count is 128 link-powered or 64 locally powered, at a bit error rate no worse than 1 in 100 000. Mix them and the rule is: (link-powered × 1) + (locally powered × 2) ≤ 128.

Link power means DC and data share the same two conductors. The source runs 41,0 to 42,4 V DC, centred at ±21 V with respect to earth. Load budget is defined in Link Power Unit Loads, one LPUL being 285 mW, with 128 LPULs allowed on the network and total steady-state draw capped at 36,5 W per segment. There is a distance-weighted rule too: sum each node’s power times its distance from the source, and keep it under a constant that works out to 1,9 × 10³ Wm, derated for wire temperature. Long runs with hungry devices at the far end are what breaks this.

Nodes are polarity-insensitive for both data and DC, which is the reason field wiring on these systems is more forgiving than RS-485. Devices must survive hot plugging into a powered network. A node stays operational from 26 V up to 42,4 V and shuts its application power off below 24 V.

Repeaters: at most one physical layer repeater in the path between any two nodes, delay through it no more than 36 µs, and never wired to form a loop.

The power line channel

Part 3 puts the signal in the 125 kHz to 140 kHz band defined by EN 50065-1. BPSK on a carrier at 131,579 kHz with 0,02 % tolerance, symbol rate 5 482,45 symbols/s. Nodes must not use the mains frequency for timing. The standard does not specify the medium itself — the reasoning is blunt and worth repeating to anyone who asks for cable specs: the power line already exists, and nobody writing the standard has any control over how it was installed or what else is plugged into it.

Framing costs more than people expect. Every byte from the MAC layer goes out as an 11-bit word — eight data bits NRZ, an even parity bit, then a fixed ’01’. Add a 24-bit sync pattern, a word sync word, and two end-of-packet words per frame. Three bits in every eleven are overhead before you count the frame markers, so payload throughput works out around 4 kbit/s from a 5 482,45 symbol/s channel.

Timing is a different world from twisted pair, and this is the number to carry in your head:

	Twisted pair	Power line
Beta1	868 µs transmit	3,4 ms ± 0,1 ms
Beta2 slot	168 µs	2,0 ms ± 0,1 ms
Priority slots	4	8 recommended

Beta2 is twelve times wider. With the base randomising window of 16 slots, the average wait before a node transmits runs into tens of milliseconds. Add carrier detect at up to 1,7 ms. Design your retry counts and application timeouts around that, not around twisted-pair habits.

Coupling has a hard rule: signalling goes between phase and neutral only, with no functional connection to the protective conductor. That holds for single-phase and multi-phase nodes alike. On multi-phase installations you can couple any or all phases with respect to neutral, and cross-phase coupling uses phase couplers per EN 50065-4-1. Connectors must add less than 0,1 dB of loss in either direction.

Band placement is the whole story for anyone specifying surge protection: filters and frequency-selective protection devices on the same circuit must not substantially attenuate 125 to 140 kHz, or the channel goes away in part or across the whole network. It is a common and frustrating commissioning failure, because the protection device is usually installed by someone who has never heard of the control network.

The receiver requirements tell you what the channel is expected to survive. Compliant transceivers are tested for packet error rate over more than a thousand packets: below 0,1 % on a quiet line, and below 2 % through a 10 dB notch centred near 130 kHz, under interfering tones across 10 kHz to 1 MHz, and against triac dimmer impulse noise firing every half cycle. Dimmers are called out by name in the standard. If a power line segment goes intermittent after a lighting retrofit, that is where to look first.

Carrying it over IP

Part 4 does not change the protocol. It wraps packets so they can cross an IP network, and the ISO text calls the resulting devices CNP/IP devices.

Transport is UDP rather than TCP, chosen for efficiency and for multicast support. IANA has assigned ports 1628 and 1629, both TCP and UDP. Reserve both on any firewall between segments.

The design leans on the fact that the protocol already does end-to-end acknowledgement. So the IP layer adds no acknowledgements of its own and never retransmits a dropped IP packet. What it must do instead is preserve ordering, suppress duplicates, and throw away anything that arrived too late to matter.

Ordering and duplicates. Every sender keeps a session ID and a 32-bit packet sequence number per destination. The receiver tracks the last sequence it forwarded. A packet arriving in sequence goes through. A packet arriving early can be held in escrow waiting for the gap to fill, and the escrow is abandoned once the channel timeout expires — capped at 1,5 s. Anything arriving with a sequence at or below what was already forwarded is discarded as a duplicate. Session IDs change on reboot, which is how a receiver knows to resynchronise rather than discard everything from a device that just restarted.

The NTP dependency. This is the part that surprises people. Stale packet detection works by timestamping every packet on transmission and comparing against a channel timeout. For that to mean anything, every device on the IP channel must have a synchronised clock, and the standard names SNTP per RFC 2030 as the mechanism. The RFC 1305 timestamp format is a 32-bit seconds integer plus a 32-bit picoseconds integer, and the standard rejects it here because no contiguous range of bits in it has both the resolution and the arithmetic properties needed. So CNP/IP defines its own: 32 bits of milliseconds, aligned with current SNTP time, wrapping every 49,7 days.

The consequence is written into the standard carefully: a device may continue forwarding only as long as it can be reasonably sure its clock has not drifted out of range with the rest of the channel, and if it has no way of estimating that margin, it need not forward packets onto the IP channel. Permissive at the final step rather than mandatory — but the practical outcome is a device that goes quiet. So a LonWorks-over-IP installation has a real dependency on a time server that most commissioning checklists never mention. Stale detection can be switched off, and on a single flat Ethernet segment with no routers in between that is a reasonable choice. On anything routed, it is not.

Segmentation. CNP/IP works to a limit of 548 bytes of payload per UDP packet — a limit the specification sets for itself, not a property of UDP, which permits considerably larger datagrams. Some configuration structures exceed it. Those get carried in segment packets, each tagged with a segment ID, a valid bit, and a final bit. Each segment also carries a datetime marking when that data structure became valid — compare it across segments and a mismatch tells you the underlying data changed mid-transfer.

Packet bunching. Several protocol packets can travel in one IP packet, and every device must be able to receive bunched packets.

The configuration server. Each device holds a send list telling it which peers to forward to. That list is configured, not discovered, and it has to be symmetric: if A sends to B, B must have A in its send list, otherwise acknowledged service silently breaks in one direction. A configuration server can distribute and maintain those lists, which reduces the risk of inconsistent configuration — but symmetry is a configuration requirement either way, not something the server guarantees. Devices register with it on power up, on reset, and when their channel parameters change.

Security, honestly

The standard includes authentication. It is worth understanding exactly what it does and does not give you.

Authentication is challenge-response with a shared 48-bit key. The challenger generates a random number. The challengee returns a transformation of that number, the original message, and the key. The challenger computes the same thing and compares. Match means the transaction is authenticated.

The standard is direct about the algorithm: it is a one-way encoding rather than real encryption. It takes the 48-bit key, the message, and a 64-bit random input, and produces a 64-bit output. Any 48-bit number is a valid key.

So: on a native segment, the payload is not encrypted, and the protocol provides no cryptographic integrity protection. The link-layer CRC-16 catches accidental transmission errors, but it does nothing against deliberate modification — anyone altering a packet can recompute it. Authentication tells the receiver the sender knows the key. It does nothing to hide the data or prove it arrived unmodified. Other limits are worth writing on the commissioning sheet:

• Only acknowledged and request/response transactions can be authenticated. The unacknowledged services cannot.
• Messages received on the flexible domain are never authenticated.
• The authentication bit is honoured only in the configured and hard-offline states.
• A node driven back to unconfigured clears its authentication keys.
• Even when authentication fails, the message still reaches the application, with a flag. The application decides whether to act on it. Many do act on it.

The IP side uses a different mechanism. Part 4 defines its own optional scheme, and it is not the 48-bit one. When the security bit is set in the CNP/IP header, the sender appends a shared secret to the packet, runs MD5 over the whole thing, and puts the resulting 128-bit digest in the header. The receiver zeroes the digest field, repeats the calculation with its own copy of the secret, and compares. The standard requires the shared secret to represent a value containing at least 128 degrees of freedom — its phrase, not conventional cryptographic terminology; in practice it means 128 bits of entropy. A 16-byte array of free bits qualifies, as does a 22-byte string with 6 usable bits per byte.

That scheme does give tamper detection: a modified packet fails the comparison. It still does not encrypt anything, and the standard says so directly — the contents remain open to inspection. The secret must never cross the network in the clear, and devices have to provide a secure manual way to set and update it. Don’t read it as modern cryptographic authentication either: MD5 is long past being considered collision-resistant, the construction is not HMAC, and there is no replay protection in the mechanism itself. Treat it as protection against corruption and casual interference rather than against a capable attacker.

Net position: treat a LonWorks segment as a trusted network that needs protecting at its boundary, not as a protocol that protects itself. That is the same conclusion you reach with Modbus, and for the same reasons.

Where it runs besides buildings

Building automation is where the volume is, and it is all most reference pages cover. It is not the whole picture.

In substation protection and control, LonWorks has been used as the station bus in medium and high voltage installations. The fit is specific: control networks are characterised by short messages, low per-node cost, several media options, and low bandwidth — which describes protection and control signalling well. Network variables carry measurements, status, and interlocking and blocking signals. Explicit messages carry the longer items: events, parameter reads and writes, and in ABB systems, tunnelled SPA-bus traffic. Peer-to-peer with no master also means direct device-to-device interlocking without a central controller in the path, and it supports redundant and multi-master arrangements.

The protocol has also been ratified as the base for IEEE 1473-L in train control, AAR electro-pneumatic braking on freight trains, SEMI E54 for semiconductor equipment sensors and actuators, and IFSF for European petrol forecourts.

Getting data out to Modbus and BACnet

Few industrial controllers speak LonWorks natively. Devices historically needed Echelon silicon, which kept it out of general-purpose PLCs. In practice you use a gateway.

The awkward part is not the transport, it is the model. Going from a typed network variable to a Modbus register means throwing away the type and writing down the scaling somewhere. Going the other way means inventing a type. A gateway that handles binding on behalf of the LonWorks side saves real commissioning effort, because otherwise you are managing bindings from a tool that does not understand them.

Plan gateway points early. The count drives the device you buy, and adding points later usually means re-commissioning bindings.

FAQ