Low power, wide area network technology (LPWA; also referred to as LPWAN) enables connected devices to communicate over large geographical areas at a low bit rate. It is a broad term for the variety of technologies used to connect sensors and controllers to the internet without the use of traditional WiFi or cellular.
LPWA formally got its start through a French company called Sigfox. (Though there were precursors to this development, which you can read about here.) Sigfox developed an alternative telecommunication system after realizing that the needs of low-power, low-data rate Internet of Things (IoT) devices were being poorly met by cellular networks. Traditional cellular technology, used for things like smartphones, covers a broad area and consumes an excessive amount of energy; IoT devices require less power for smaller transmission packets. To better address the requirements of M2M and IoT devices, Sigfox created a new type of network technology with the following characteristics:
- Inexpensive chipsets and networks.
- Long battery life.
- Limited data communication.
Sigfox technology sends very small amounts of data (12 bytes) very slowly (300 baud) using standard radio transmission methods (phase-shift keying, DBPSK, going up and frequency-shift keying, GFSK, coming down). The long range is accomplished as a result of very long and very slow messages. Sigfox commercialized its proprietary IoT solution and now owns and operates a network—primarily in Europe—that uses its technology.
Today, Sigfox isn’t the only organization creating LPWA technology. The LoRa Alliance developed LoRa, another radio frequency technology that uses unlicensed radio spectrum to enable low power, wide area communication between devices. LoRa is supported exclusively by chips manufactured by Semtech; it’s different from Sigfox in that it uses chirp spread spectrum where Sigfox uses narrowband (or ultra-narrowband) technology. LoRa itself is not an LPWA solution, but LoRaWAN—a protocol specification built on top of LoRa technology—is.
Many companies, Link Labs included, have capitalized on the rapid growth of the LPWA market by building larger technologies on top of the LoRa chip, finding alternate ways to connect IoT devices. All are finding their own niche within the LPWA space. LoRaWAN and Symphony Link are two of the primary technologies under active development and deployment.
- LoRaWAN is an open protocol built using LoRa’s modulation scheme, which was developed for use by wireless carriers who want to use unlicensed spectrum to communicate with IOT devices in their network. It is designed for large-scale public networks with a single operator.
- Symphony Link is also built on LoRa’s chirped spread spectrum physical layer technology; it is an alternative specification to LoRaWAN developed by Link Labs. Link Labs serves customers who are trying to sell third-party connected devices in an enterprise or industrial setting.
Below we’ll go into the technical differences between Link Labs wireless technology and LoRaWAN and cover the advanced features of Symphony Link.
Watch our webinar to learn more about which type of LPWAN technology is right for your use case.
Symphony Link vs. LoRaWAN
Symphony Link® is a wireless system developed by Link Labs. It is primarily used by industrial and enterprise customers who love the range of LoRa but need high reliability and advanced features in their LPWA system.
LoRaWAN is a media access control (MAC) layer protocol designed for mobile networks, primarily in Europe.
LoRa symbol encoding
Both Symphony Link and LoRaWAN use Semtech’s LoRa modulation scheme. Essentially, LoRa is a waveform. It uses a chirped spread spectrum technology which encodes multiple bits per symbol, has integrated packetization and error correcting, and works with a great integrated baseband digital signal processor, called the SX1301. LoRa® is a trademark of Semtech. The role LoRa plays in both LoRaWAN® and Symphony Link® is at layer 1, or the physical layer. It is analogous to Frequency Shift Keying or another PHY technology in a different system.
OSI data model
LoRaWAN technology is useful, with a large and growing ecosystem of vendors, but it has several limitations that make it unsuitable for private network solutions:
- Packet error rates over 50% are common since LoRaWAN is an asynchronous, ALOHA-based protocol with very limited acknowledgements. LoRaWAN, Sigfox, and others utilize a “spray and pray” method of message delivery that is not appropriate for most industrial use cases. 100% message acknowledgement is critical for most organizations, who use the data gathered for business analytics.
- Only one network can operate in an area without interference. In LoRaWAN, all gateways, no matter who owns or operates them, use the same frequency channels. That means your LoRaWAN network sees all my traffic and vice versa. My server can’t decrypt your messages, but it eats into the capacity all the same. This type of layer 2 interference could be very problematic as LoRaWAN networks scale.
- It is nearly impossible to update device firmware over the air using LoRaWAN. LoRaWAN claims to be able to do firmware upgrades, but it does not seem plausible when you add up the time (which could be multiple days or even weeks), the complexity (since you have to manage the firmware upgrade completely at the application layer), and the effect on network performance (sending lots of downlink in a LoRaWAN network causes packet error rate to skyrocket since the gateway is transmitting often—but the nodes don’t know that when they are trying to send messages). All our large OEM customers would be unable or unhappy to go to market with firmware they would have to physically touch to upgrade.
- It has no real multicast solution. Because LoRaWAN encrypts all traffic both up and down on a one-to-one basis, implementing multicast for control systems, like a lighting system, for example, is very difficult.
- LoRaWAN is designed around a 1% duty cycle limit driven by the European ETSI requirements, which prevents LoRaWAN from being used in systems that need the ability to send lots of data at a time. Since this limit also applies to the LoRaWAN base station, its ability to control the network, send commands, or send acknowledgements is very limited.
- Duty cycle limits of the LoRaWAN architecture prevent repeaters from operating with that system. But repeaters are a necessity for some companies because they help reduce network infrastructure requirements and are a cost-effective way to expand radio frequency performance and scale.
- LoRa is incapable of real-time power and data rate control. Its in-channel dynamic range is limited to about 20 dB; due to dynamic range issues a transmitter that is close to the base station will prevent the node further away from being heard. And since there are few acknowledgements in LoRaWAN, these messages would be lost. (In the future, if large LoRaWAN public networks with many base stations in range are built, this effect would be somewhat mitigated.) LoRaWAN has Adaptive Data Rate (ADR) as well, but since it is driven by the server, if a node’s link suddenly fades, the server has no way of telling it to change spreading factors to compensate.
- LoRaWAN security flaws do not pose a significant risk for most users, but the use of pre-shared keys and identities does create vulnerabilities.
- Anyone operating a public LoRaWAN network needs to be granted a NetID by the LoRa Alliance. Since these are only available to Contributor members and above, budget $20,000 per year to use LoRaWAN.
The LoRa Alliance is working hard to enhance the technology, but as of now, LoRaWAN is best for customers who want to develop solutions to connect to LoRaWAN public networks. For private networks we strongly recommend our customers use Symphony Link.
Reasons Customers Choose Symphony Link® Instead Of LoRaWAN®
Guaranteed message receipt.
Some percentage of unacknowledged messages is fine for some meter reading applications, but for industrial or enterprise sensor networks or control systems, 0% PER is a requirement. We have many Symphony Link customers, from Fortune 100 enterprises to startups, who tried to build on LoRaWAN and failed. The Symphony Link MAC acknowledges every message, both up and down.
Firmware Over-the-Air.
With Symphony Link, you can update the host firmware on your device after it has been fielded. This is a huge advantage early in the IOT evolution, as it allows customers to get to market more quickly and with less risk. For many customers, this is the biggest reason to adopt Symphony Link.
No duty cycle limit.
In Europe, Symphony Link uses the Frequency Hopping Listen-Before-Talk plus adaptive frequency agility band, which removes the duty cycle limit. In the 900 MHz Band, there is no duty cycle limit. Also, by using a full frequency hopping scheme, end devices can transmit up to 1W in the 900 MHz band. This is great for AC-powered devices like electricity meters and lights.
Repeaters.
Since Symphony Link is a synchronous protocol, repeaters allow users to expand the range of the network dramatically without impacting latency. Repeaters cost many times less than an outdoor access point, and thus allow Symphony Link customers to cover larger areas without spending additional thousands on infrastructure. They are also very power efficient, so repeaters can be solar or battery powered.
Quality of service.
With Symphony Link, the gateway is in control of the network it is creating, we implemented a quality of service tiering system to allow nodes with important traffic to have priority over devices with lower priority traffic. You don’t want an alarm to have to compete with a water meter for channel access.
No per-device configuration.
Probably the biggest headache when using LoRaWAN is the complicated management of multiple per-device encryption keys both at the time of device production and on the server side. With Symphony Link, the host device configuration is the same for all devices of the same type, and key exchange is handled via our world class PKI based Diffie Hellman AES architecture.
Real time power and data rate control.
In Symphony Link, before every transmission, an end device calculates the reverse link to the gateway and adjusts its transmit power and spreading factor or modulation rate to match. This way, nodes throughout the network have a balanced link budget. Close nodes are transmitting quietly and quickly, and far nodes are transmitting loudly and slowly. And ADR in Symphony Link is about optimizing performance and reliability. Symphony Link ADR instantly optimizes for capacity even better than LoRaWAN.
No security flaws.
With Symphony Link and the use of a Public Key Infrastructure (PKI), the over-the-air wireless channel is considered unbreakable by NSA standards. PKI also prevents spoofing and assures identity of infrastructure.
Multiple gateway coexistence and interference mitigation.
Symphony Link uses a dynamic channel mask that is controlled by the gateway to ensure as few collisions as possible. In the U.S., Symphony Link uses 28 times more spectrum than LoRaWAN, and in Europe seven times more.
Higher Capacity.
By using asynchronous features like slotting, and uplink/downlink coordination, a Symphony Link network has over four times the capacity of LoRaWAN. And when you couple that with quality of service, Symphony Link is a much more robust choice for users that need it.
Multicasting.
Symphony Link implements multicast session keys which allow for groups of devices to be addressed. By logically grouping together nodes you can control them in whatever way makes sense for your application. If it’s lighting control, for instance, you can group 10 nodes together and send and receive messages that way. This is also what allows Symphony Link to transfer firmware over-the-air.
No cost associated with a network ID.
Operating a Symphony Link network does not require a network ID from the LoRa Alliance. Symphony Link does not interfere with LoRaWAN and vice versa.
There are also other features unique to Symphony Link that are critical for a subset of users—like time sync broadcast, which allows end devices to sync to the real time clock of the gateway, and time stamping of data at the edge. For more on these, see the Symphony Link use cases section below.
Symphony Link Protocol Description
Say we just turned on our Symphony Link gateway. The first thing it does is scan the band and create an interference profile. (Note that this is how the system operates in 900 MHz. For 868, the operation is slightly different, since the beacon channel is fixed, but uses a TDMA scheme.)
Once the interference scan is complete, the gateway selects a 500 kHz channel for its downlink (125 kHz for Europe), and then listens to that channel to make sure there is no weak LoRa traffic there, which would indicate another Symphony Link gateway further away has chosen that same channel. Also note that this is the automatic channel selection mode; the user can also set the channel manually via the network manager interface of our network management software.
So this channel is chosen, and the system begins transmitting every two seconds. This message can be called a beacon or frame header. This frame header contains several important bits of information.
First, this message is encrypted with the network ID. This is what allows a customer to make their network “private” and unusable by other Symphony Link users. This is one of the two parameters configured on the end device, the other being Application Token, which is what identifies device data flow.
The second piece of information is the uplink/downlink time boundary. This tells the nodes that are awake during this frame when the gateway will be done transmitting. Since LoRa is a half-duplex technology, it is important to prevent up/down collisions, which are very prevalent in LoRaWAN. (A LoRaWAN gateway must respond to a node’s request for acknowledgement or downlink within a fixed time frame. Any LoRaWAN message sent during this time will not be received by the gateway. Requesting more acknowledgements in LoRaWAN just compounds the problem exponentially.)
A third piece of information is the uplink channel frequencies of the forthcoming uplink frame. Since Symphony Link utilizes a “block hopping” uplink method, where the bank of receivers hop in every frame, the nodes need to be told where these channels are. This is also how Symphony Link can have so many more networks on the air at a given time without interference. Also, since the gateway is telling the nodes what channels are available, Symphony Link can have a 1-channel, 8-channel, or 64-channel gateway—the endnode doesn’t care. A repeater or inexpensive single channel gateway can bring the same features to the network as a larger gateway, with the only difference being uplink capacity. Plus there is the added benefit of the endnode being able to detect the presence of a network passively, even across both 868 and 915. A LoRaWAN endnode has to transmit in the blind to see if any network responds to know if there is a network there or not; this can burn a lot of power.
The gateway also sends a quality of service level for that frame, so that if the network is congested, less important nodes can wait before transmitting.
Finally, the gateway transmits the compressed acknowledgement packet, which contains an acknowledgement for all messages in the previous frame. In LoRaWAN, the acknowledgements that do happen are always one to one, and when you add the LoRa preamble to those messages, they are a huge bandwidth hog. By compressing ACKs into one message, we save significant time on air over LoRaWAN.
There is additional information that nodes need to transact with the network, which is contained in the info block message and transmitted by the gateway every eight frames. Information about regulatory power limits and transmit power of the gateway is important for nodes as they calculate their power and spreading factor for each transmission. If a network needs to trade reliability for capacity, the info block can also tell nodes to apply additional signal margin to their adaptive power and data rate calculation. The software version of the gateway is also transmitted, to prevent a mismatch in capabilities between the end node and the gateway. The info block message can also turn on or off the listen-before-talk mode in the nodes, which is only required for operation in Europe and Japan. Also, the info block tells the nodes whether or not it is connected to the network management cloud, and thus whether the PKI server can be used for the public key source, and whether the node needs to register before joining the network. This allows some networks to operate completely disconnected from the internet.
Let’s say a node wants to transmit an uplink payload to the gateway. Since this is a low power network, it has been completely asleep and idle for some length of time. It will wake up and tune its receiver to the frequency where it last heard the gateway. It assumes some worst case crystal offset, and thus starts listening some milliseconds prior to the beginning of the gateway frame header preamble.
It then should detect and process the frame header message. It learns when the uplink window starts, and what frequencies are available.
Then it sleeps for the rest of the downlink period, unless it is a “downlink always on” node, which I will explain in a moment.
Once the downlink portion of the frame is over, it tunes to a random frequency from the set that the gateway just advertised. Inside the remaining frame are a series of time slots, which each make up 10 bytes of message payload length, plus a listen-before-talk period.
The node at this point calculates the power and spreading factor needed to close the link back to the gateway. Let’s say the signal is relatively strong, so it chooses spreading factor 7, and 0 dBm transmit power.
This node has a 37 byte message to transmit, so it will need 4 sub-frame slots.
Now, the node’s quality of service plays an important role at this point. Assuming the gateway isn’t suppressing nodes with that QOS, the QOS is what dictates what percentage of time slots a node can take. A high quality of service will pick 4 sub frame slots every time.
At the lowest QOS, a node is only allowed to use one sub frame slot each frame, so it would take 4 frames to get 37 bytes out the door.
But, let’s assume the QOS is in the middle, like 8, in the QOS range of 0-15. So it picks 4 slots.
It then goes back to sleep, and wakes back up the frame after next to receive the acknowledgement. If there was a collision with one of the 4 sub-packets, then only 3 would be ACK’d and the node would retransmit the missing sub-packet in that frame.
Since the Symphony Link MTU or Maximum transmit payload length is 256 bytes, it can take up to 26 slots to uplink a large message. The nice thing is that any slots that are missed will be resent automatically by the module. In LoRaWAN, if you want to send more than about 12 bytes, you have to handle retries and packetization at the application layer. Just think about how hard that would be to implement for more than a few nodes.
A repeater in Symphony Link works by fitting a beacon, downlink, uplink, and transfer message all within the uplink portion of a normal Symphony frame. This is because the modulation rate, or spreading factor of repeaters are 2x faster than the gateway. This gives up 3 dB of the link, but this is not really noticeable for repeaters, which can add huge coverage to the network. While repeaters have much less capacity than the gateway, a single gateway can host dozens of repeaters. This is a great architecture to cover large areas cost-effectively.
These are just the basics of how Symphony Link works. There are many more features like firmware transfers, multicast, and key exchanges, but the above should give you a good idea of the basic system architecture.
Symphony Link Use Cases
Link Labs customers are using Symphony Link in a variety of enterprise and industrial settings. A sampling of some current use cases include:
- GPS asset tracking of golf carts at a golf course. Cellular solutions work well in these instances but have a high monthly recurring charge. In this use case, real-time adaptive data rate is important because, as a golf cart is driving around, the channel is changing dramatically. In order to work well, the tracking device needs the ability to update the power level and spreading factor modulation rate in real time as the channel fades in and out.
- Demand response in public housing. Hot water heaters can be retrofitted with DR controllers that are controlled from the Symphony Link system. Hot water heaters send usage information in real time to the gateway; when a demand response signal hits the gateway from the internet, it can turn off some or a subset of those hot water heaters in less than two seconds.
- Commercial building energy monitoring. A Link Labs module is connected to a pulse-counting sensor that goes in circuit panels throughout large buildings. With one access point in a building you can connect dozens to hundreds of subservice panels throughout the building to monitor electrical consumption.
In addition, Symphony Link is the only LPWAN technology that works in use cases like these:
- Lock control
- Demand response
- Industrial control systems
- Lighting control
- Alarm systems
- Physical security
Interested in seeing how Symphony Link could solve your connectivity challenge?
At Link Labs, we’ve helped engineer solutions for everything from simple temperature probes all the way to multi-sensor GPS accelerometers for complicated asset tracking systems. If you’d like to see how Symphony Link could work for your use case, schedule a free demo of the technology today. We’ll show you how it will work for your LPWA; how to set up a gateway and a dev kit in Symphony Conductor; and review integration steps, power budgets, and range. Or, if you have any questions about the technology, just get in touch.
