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 that stays roughly at 1 / (2 × 16) regardless of load, instead of degrading the way plain CSMA does when traffic climbs.

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 a node that used its priority slot in one packet cycle cannot use its normal access algorithm in the next one, so back-to-back priority messages from the same node do not work 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 6-byte domain ID gives worldwide uniqueness; a single building can safely use something shorter. A domain is a closed world — source and destination of a packet must be in the same domain, and the stack has no inter-domain routing at all. Crossing domains needs an application-level gateway. 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 type library itself — the standard network variable types, and the configuration properties that go with them — is LonMark territory rather than ISO/IEC 14908. The standard defines the mechanism. LonMark defines the vocabulary and the functional profiles that say which variables a given kind of device must expose.

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 timestamp is 32 bits of milliseconds aligned to SNTP time, and it wraps every 49,7 days.

The consequence is written into the standard plainly: if a device loses its time server and has no way to bound its own clock drift against the rest of the channel, it must stop forwarding packets. Not degrade — stop. So a LonWorks-over-IP installation has a hard 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. UDP payload caps at 548 bytes, which is smaller than some configuration structures. 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. The configuration server is what keeps those lists consistent. Devices register with it, and a network without one drifts out of sync as soon as anything is added.

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 it is not integrity-protected. 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 is different, and stronger. 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 shared secret must carry at least 128 degrees of freedom — a 16-byte array of free bits, or a 22-byte string with 6 usable bits per byte, both qualify.

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. MD5 is also long past being considered strong, so treat this 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