LoRaWAN Gateway Buyer's Guide for India: Channels, Certification and Capacity
Three.
That is the number of default uplink channels in the standard Indian LoRaWAN channel plan, against eight in Europe. Everything a buyer needs to know about gateways for India grows out of that small integer, because capacity, collision rates, acknowledgement behaviour and even how many nodes one rooftop box can honestly serve are all consequences of how few channels a gateway starts with.
This guide is a verdict-style comparison for anyone choosing a LoRaWAN gateway for a deployment in India: a campus, an industrial estate, a farm cluster, a city district. It states a recommendation first, then shows the capacity arithmetic, the certification route, the antenna limit, the backhaul and security decisions, and the operating habits that decide whether a gateway is still useful a year after installation. The code is runnable, the figures are computed, and the places where sources disagree are marked.
The verdict in one paragraph. For most Indian deployments, buy an outdoor, sealed, PoE-powered eight-channel gateway with a secure connection protocol to the network server, GNSS for time, surge protection on the antenna port, and a documented wireless approval for the exact model. Configure more than the three default channels. Prefer unconfirmed uplinks. Place the gateway for line of sight and test the placement before you drill any holes. The rest of this post explains each clause.
Three Default Channels and the 865 to 868 MHz Band
India's licence-exempt band for devices like these is 865 to 868 MHz, set by the Department of Telecommunications in its rules of 10 December 2021, G.S.R. 853(E), which replaced the earlier 865 to 867 MHz allocation. For LoRa-class radios with a carrier up to 200 kHz, the 2021 table permits 500 milliwatts effective radiated power with adaptive power control, with duty-cycle caps of 10 percent for gateways and 2.5 percent for other devices. The older 1 watt and 4 watt figures that circulate online belong to the superseded rules. Check the gazette yourself before you rely on any of this, because guides and vendor pages lag the law.
The LoRaWAN regional parameters for India, in editions written before 2021, describe a plan inside the older 865 to 867 MHz range. As recalled and flagged for checking, the default channels are 865.0625, 865.4025 and 865.985 MHz, each 125 kHz wide, with data rates from spreading factor 12 to 7, and a second receive window at 866.550 MHz. Three channels is what every compliant device is guaranteed to know when it joins.
More channels are possible. A network server can send additional channel definitions to a device in the join response, up to five, so a gateway and its devices can use eight channels if the stack supports it. The wider 2021 band gives room for them. But support depends on the regional-parameter version your network server, your gateway and your end devices implement, so ask for it in writing, and test with the actual devices you will buy.
The consequence for gateways is simple. A gateway that listens on eight channels at once can use the extra channels as soon as the network configures them, and one that is hardwired to three cannot. The three-channel limit also governs your first sizing estimate, as the next section shows.
India's default plan has three channels, not eight. Any capacity figure borrowed from a European deployment is wrong by a factor of more than two before anything else is considered.
What One Gateway Can Carry: Airtime, Collisions and the Maths
LoRa uplinks are sent without a listen-before-talk. Two devices that transmit on the same channel and the same spreading factor at overlapping times collide, and both are usually lost. The chance of collision depends on how much of the channel's time is occupied, which depends on how many devices, how often, for how long.
Airtime is computed from the packet length and the radio settings. For a 21-byte frame, which is an 8-byte application payload plus 13 bytes of LoRaWAN overhead, at 125 kHz bandwidth, the airtime is about 57 milliseconds at spreading factor 7, 185 milliseconds at spreading factor 9, 371 milliseconds at 10, and about 1.48 seconds at 12. The same device at a longer range pays twenty-six times the airtime of a close one.
A simple model for capacity treats each channel as pure ALOHA, where the success probability is the exponential of minus twice the offered load. It is conservative, because it ignores that different spreading factors are close to orthogonal and that a strong signal can survive a collision. It is also easy to compute and gives the right order of magnitude. The code below computes airtime, the number of devices that keep 90 percent of uplinks collision-free, and the downlink budget.
import math
def airtime_ms(pl, sf=9, bw=125000, cr=1, preamble=8, header=True, crc=True):
de = 1 if (2**sf / bw) > 0.016 else 0 # low data-rate optimisation
tsym = 2**sf / bw
ph = 8*pl - 4*sf + 28 + (16 if crc else 0) - (0 if header else 20)
n_pl = 8 + max(math.ceil(ph / (4*(sf - 2*de))) * (cr + 4), 0)
return (preamble + 4.25 + n_pl) * tsym * 1000
def nodes_for_success(target, interval_s, airtime_s, channels):
g = -math.log(target) / 2 # exp(-2G) = target
return g * interval_s * channels / airtime_s
t9 = airtime_ms(21, 9) / 1000 # 0.1853 s
t7 = airtime_ms(21, 7) / 1000 # 0.0566 s
print(round(nodes_for_success(0.9, 600, t9, 3)), round(nodes_for_success(0.9, 600, t9, 8))) # 512 and 1364
print(round(nodes_for_success(0.9, 600, t7, 3)), round(nodes_for_success(0.9, 600, t7, 8))) # 1676 and 4469
ack9 = airtime_ms(13, 9) / 1000 # empty downlink frame, 0.1649 s
print(int(0.10 * 3600 / ack9)) # 2183 acknowledgements per hour at a 10 percent cap
Case | Reporting interval | Channels | Devices keeping 90 percent success |
Spreading factor 9, 21-byte frames | 10 minutes | 3 | about 510 |
Spreading factor 9, 21-byte frames | 10 minutes | 8 | about 1,360 |
Spreading factor 7, 21-byte frames | 10 minutes | 3 | about 1,680 |
Spreading factor 7, 21-byte frames | 10 minutes | 8 | about 4,470 |
Spreading factor 9, 21-byte frames | 60 minutes | 8 | about 8,190 |
Read the table as a range, not a promise. Real deployments see capture effects and spreading-factor separation that help, and also interference, uneven spreading-factor mixes and retransmissions that hurt. The pattern holds: capacity scales with channels and falls steeply with airtime, so the nearest devices on the fastest data rate cost almost nothing, and a few distant devices on spreading factor 12 can dominate the channel.
Two practical rules follow. Let adaptive data rate push devices to the fastest rate their link supports, so airtime stays short. And report as rarely as the application allows, because halving the reporting rate doubles the number of devices a gateway can carry.
The Hidden Cap: Acknowledgements and the Gateway Duty Cycle
Capacity in the uplink direction gets all the attention. The downlink direction is where many deployments quietly fail.
A gateway transmits when it sends acknowledgements, join accepts, commands to devices and MAC-layer adjustments. Each transmission uses the gateway's own duty-cycle allowance, which in India is 10 percent for gateways under the 2021 rules. Ten percent of an hour is 360 seconds of transmit time.
If every uplink asks for a confirmation, each one requires a downlink. An empty acknowledgement frame at spreading factor 9 takes about 165 milliseconds of airtime, so the gateway can send about 2,183 of them in an hour before it hits its cap. Now take 500 devices reporting every ten minutes, six times an hour. They want 3,000 acknowledgements an hour. The gateway can deliver about 73 percent of them, the devices that do not receive one retry, and the retries add more uplinks and more collisions. The network can enter a spiral that no amount of additional uplink capacity fixes.
The same arithmetic shows how many confirmed devices a single gateway carries at that rate: about 363. The uplink model says the radio could handle 500 to 1,400 devices. Confirmed uplinks cut it to under 400 without anyone noticing, until a gateway's downlink queue fills.
The remedy is a design habit: use unconfirmed uplinks for routine readings, and confirm at the application layer only the messages that matter, such as an alarm. A reading sent every ten minutes needs no acknowledgement, since the next one arrives soon. An alarm that must not be lost gets a confirmation, a retry policy and a way to raise the alarm another way if no confirmation arrives.
Confirmed uplinks consume the gateway's scarcest resource, downlink airtime. Make unconfirmed uplinks the default and ration confirmations to the messages that need them.
Antennas and the 500 Milliwatt Rule
The effective radiated power limit applies to the radiated signal, which includes the antenna's gain and the loss in the cable between radio and antenna. A gateway with a high-gain antenna and a short cable can exceed the limit while its radio setting looks modest.
Effective radiated power is measured relative to a half-wave dipole. The limit of 500 milliwatts is 26.99 dBm of ERP, which is 29.14 dBm of EIRP, since a dipole has 2.15 dB of gain over an isotropic radiator. Subtract the antenna gain and add the cable loss to find the largest power the radio itself may produce.
import math
def dbm(mw): return 10 * math.log10(mw)
ERP_LIMIT = dbm(500) # 26.99 dBm
def max_conducted_dbm(antenna_gain_dbi, cable_loss_db, erp_limit=ERP_LIMIT):
return erp_limit + 2.15 - antenna_gain_dbi + cable_loss_db
print(round(max_conducted_dbm(5, 0.66), 1)) # 24.8 dBm, about 302 mW
print(round(max_conducted_dbm(8, 1.5), 1)) # 22.6 dBm, about 184 mW
print(round(max_conducted_dbm(5, 3.0), 1)) # 27.1 dBm, about 518 mW
A 5 dBi antenna on three metres of low-loss cable, about 0.66 dB, limits the radio to roughly 24.8 dBm, or 302 milliwatts. An 8 dBi antenna with 1.5 dB of cable loss limits it to about 22.6 dBm. Long, lossy cable lets you run more radio power for the same radiated power, at the cost of a worse receiver, since the same loss hurts the incoming signal too.
Two points follow. Placing the antenna as close as possible to the radio, or using low-loss cable, is better than long lossy runs, because loss hurts reception while the limit applies only to what is radiated. And a higher-gain antenna narrows the vertical beam, which helps flat terrain and hurts when nodes sit well below the mast, as in a hilly campus or a multi-storey building, where a lower-gain antenna gives better coverage.
Check what the certification covers. An approval is granted for a radio with a stated antenna. Swapping in a different antenna or changing the cable can take the installation outside what was approved.
Certification: WPC ETA, MTCTE and What Customs Will Ask
A gateway sold or imported for use in India needs the relevant wireless approvals. For radios in the de-licensed bands, the Wireless Planning and Coordination wing issues an Equipment Type Approval, abbreviated ETA. As reported by one source, an order of 9 September 2024 moved this to a self-declaration process, with a fee reported at 10,000 rupees per model and a test report from a recognised laboratory, but this changes, so confirm the current procedure on the official portal before you plan.
The second question is the Telecommunication Engineering Centre's mandatory testing and certification regime, known as MTCTE, which applies to a defined list of telecom equipment. Whether a LoRaWAN gateway falls under it is the point on which advisers disagree. Some treat a gateway with cellular backhaul as telecom equipment, others do not. Do not rely on a consultant's opinion or a vendor's assurance. Ask the test laboratory for a written classification of your exact product, and keep it in the file.
A third area is the power adapter. If the gateway ships with an external mains adapter, adapters fall under the Bureau of Indian Standards compulsory registration for listed products, and a missing mark can hold up a consignment even when the radio is fully approved.
For a buyer, the practical checklist is short.
Ask the vendor for the ETA number for the exact model and regional variant, and check it against the portal.
Ask what antenna and cable the approval covers.
Ask for the laboratory's written view on MTCTE applicability.
Check that the mains adapter, if supplied, carries the required registration.
Keep the paperwork with the asset record, since customs, auditors and your own customers may ask for it years later.
Nothing here is legal advice, and the details are volatile. Verify each step with the authority or an accredited laboratory.
Concentrator Capacity, Half-Duplex and Why Eight Channels Is the Sweet Spot
Inside a gateway sits a radio concentrator chip that receives on several channels and spreading factors simultaneously. Common configurations are eight channels, sixteen, and sixty-four for large urban gateways. More channels mean more simultaneous receptions, at higher cost and power.
Two facts shape the choice. First, the concentrator is half-duplex. While it transmits a downlink, it cannot receive on that radio. A gateway that sends many acknowledgements is deaf for much of the time. Gateways with separate transmit and receive paths reduce the effect, but a busy downlink still costs uplink capacity, which is another reason to avoid confirmed uplinks.
Second, the usefulness of more channels is limited by the channel plan you can configure and by the three-channel default. A sixteen-channel gateway listening on channels that no device uses is a more expensive eight-channel gateway. For most Indian deployments of hundreds to a few thousand devices, eight channels, with the network configured to use them, is the better value. A sixty-four-channel unit is justified only where a single site expects tens of thousands of devices, and where the network server and devices actually support the channels.
Check three further capabilities. A GNSS receiver gives the gateway precise time, which matters for time-synchronised downlinks to Class B devices and for time-difference-of-arrival location. A sensitivity figure for the receiver, quoted at spreading factor 12, tells you the raw range, though real range depends on the site. And two antenna ports, with diversity, help in multipath-heavy places such as factories.
Backhaul: Ethernet First, Cellular as the Second Path
A gateway is only as good as its connection to the network server. Four options appear, and the best deployments use two.
Wired Ethernet with Power over Ethernet is the default for a reason. It is stable, the same cable powers the gateway, and it needs no SIM. Where the run is under 100 metres to a switch, use it. For longer runs, a fibre or a point-to-point radio link carries the data to a nearby building.
Wi-Fi is acceptable for temporary or short-range installations and unreliable for anything that must last, because the access point becomes a hidden dependency.
Cellular, usually LTE Cat-1 or Cat-4, suits remote sites, with caveats. SIMs need data plans and credit management, signal at a pole is not signal indoors, and a gateway with a built-in modem inherits the carrier's outages. Dual SIM with failover across two operators is a sound defence.
A hybrid is common: Ethernet as primary, cellular as backup, with the gateway switching automatically and buffering uplinks while offline where its software allows. Ask what the gateway does when the backhaul fails, how many uplinks it holds, and what happens to them on reconnection.
Bandwidth is not the problem. A gateway carrying a thousand devices sends a few kilobits a second. What matters is latency stability, since delays can push a downlink past the receive window, and reliability.
Securing the Gateway-to-Server Link
The oldest and most common way gateways talk to a network server is a UDP packet-forwarder protocol, which sends frames as plain, unauthenticated packets over UDP. It works, and it is easy to spoof or observe on an untrusted path. The newer approach, LoRa Basics Station, connects over a WebSocket secured with TLS, lets the network server manage the gateway's configuration and channel plan, and supports certificate-based authentication.
The security of the payload itself does not depend on this link, because LoRaWAN encrypts application data end to end between the device and the application server. Metadata is a different matter: gateway identities, signal strengths and timing travel in the clear on a UDP link, and an attacker able to inject packets can confuse the network's view of the world.
For a private network on your own premises over a trusted wired LAN, the plain protocol carries modest risk. For any gateway whose traffic crosses a public network, cellular, or a path you do not control, choose a gateway that supports Basics Station with TLS and unique certificates per gateway. Whatever the protocol, lock down the gateway's management interface, change default credentials on day one, disable services you do not use, and keep the firmware current.
A gateway is a small Linux computer on your network. Treat it like one: unique credentials, current firmware, no open management ports, and a record of what it is allowed to reach.
Placement: Test Before You Drill
Range in LoRa is a property of the site more than the radio. The same gateway covers kilometres from a rooftop in open farmland and a few hundred metres inside a dense industrial estate with metal sheds.
Height is the largest lever. Raising an antenna from three to ten metres changes coverage by more than doubling the gateway's output would. Line of sight to the devices matters, including the Fresnel zone, which means obstacles near the path, not only on it, cost signal. Metal roofs, tanks and stacked containers shadow and reflect.
A practical approach is to test before you install. Place a gateway, or a battery-powered test node, at the proposed location on a temporary mast, walk or drive a node around the coverage area logging signal strength and signal-to-noise ratio at each spot, and map the result. Move the gateway and repeat. A day of testing prevents a month of regret.
Expect rough ranges only: a few hundred metres to a couple of kilometres in dense built-up areas, several kilometres in suburban settings, and ten kilometres or more with clear line of sight. Our separate field guide on LoRa range on Indian farms covers the link-budget method in detail. Whatever your result, plan for overlap: a device that is heard by two gateways has a second path if one fails, and the network server can pick the better copy.
Protect against lightning. In many regions, a gateway on a mast is the tallest object around. Fit a surge arrestor on the antenna cable, earth the mast, and make sure the PoE injector and switch are protected, too. The first monsoon will test the arrangement whether you planned for it or not.
A Composite: Six Hundred Nodes on an Industrial Estate
This is a representative composite, genericised, from several estate and campus deployments. The numbers are illustrative.
An industrial estate wanted to monitor power quality and water tanks across about 40 buildings, with about 600 nodes reporting every ten minutes. The first plan used a single indoor-grade gateway on a rooftop with the default three channels, confirmed uplinks, and a packet-forwarder connection over a shared 4G router.
The first week looked good. By the third, the operations team saw gaps in the data and rising retries. Three things were wrong at once.
The confirmed uplinks were asking for 3,600 acknowledgements an hour, well above the gateway's downlink allowance of about 2,200. Devices retried, adding collisions. Dropping to unconfirmed uplinks for routine readings cut the downlink demand by about 90 percent in a day.
The three-channel default put every device on the same few frequencies. Configuring five additional channels through the network server, after confirming that the device firmware supported the channel list, spread the load across eight and cut the collision rate visibly.
The 4G router rebooted nightly under a vendor schedule, and the plain UDP link lost frames each time without any alert. Moving to a gateway with a wired connection to the estate's fibre and a TLS-secured protocol removed the gaps.
Two further changes completed the fix: a second gateway at the other end of the estate, giving overlapping coverage and a path if one failed, and a monitoring dashboard showing per-gateway uplink counts, signal histograms and downlink duty cycle. The dashboard caught a loose antenna connector three weeks later, before anyone reported missing data.
Running the Network: What to Watch and What to Keep in Stock
A gateway installed in March and forgotten is a gateway that fails in June. The operating routine is short and decides whether the network is still trusted a year later.
Watch five numbers per gateway, daily, on one screen. The uplink count tells you whether the gateway is alive and whether traffic is normal for the hour. The distribution of signal strength and signal-to-noise ratio tells you whether the antenna, cable or connector has degraded, since a loose connector shows as every device getting a few decibels weaker at once. The downlink duty cycle tells you how close the gateway is to its ten percent cap. The backhaul round-trip time tells you whether the link to the server is healthy enough to meet the receive windows. And the number of devices last seen more than a day ago tells you which nodes need a visit.
Alerts should be few and meaningful. A gateway that has sent no uplinks for fifteen minutes during the day deserves an alert. So does a sudden fall of more than a fifth in the number of distinct devices heard. An alert for every missed packet teaches the team to ignore alerts.
Keep spares. One spare gateway for every ten deployed, configured and approved for the same channel plan, turns a site outage into a swap. Keep spare PoE injectors, antennas, a length of cable with connectors fitted, and a surge arrestor. The cheapest items fail most often, and each takes a day to source if you have none.
Keep an asset register with the serial number of each gateway, its location and height, the antenna and cable fitted, its firmware version, its approval number and the date of the last visit. The register is what lets a new engineer, an auditor or a customer's inspector understand what is installed.
Update firmware on a schedule, one gateway at a time, starting with the least critical, and keep the previous version available to roll back. A fleet that updates everything at once discovers a bad release everywhere simultaneously.
Most gateway failures are slow ones, a connector loosening or a cable weathering. A daily signal-strength histogram catches them weeks before anyone loses data.
Keys, Joins and the Storm After a Power Cut
Every LoRaWAN device proves its identity to the network with keys, and how you provision them decides whether the network can be trusted. Two joining methods exist. Over-the-air activation, where the device and network derive fresh session keys at each join, is the one to use. Activation by personalisation, where session keys are fixed in the device, avoids the join process, and in doing so permanently weakens the security, since a captured device gives up keys that never change and frame counters that can be replayed after a reset.
Give every device its own root key. A fleet that shares one key across all devices lets a single extracted key compromise every device, and extraction from an unprotected microcontroller is a routine laboratory task. Generate keys per device at manufacturing, from a good random source, store them in the device's protected memory where the hardware offers it, and record them in a secure system, not a spreadsheet passed by email. Document who has access.
The join process has its own capacity problem. After a power cut, a firmware update or a gateway restart, hundreds of devices may try to rejoin at nearly the same time. Join requests use the default channels and a limited set of data rates, so they collide, and each failed attempt triggers a retry. In a network of six hundred devices this can take hours to settle, during which the data is missing and the gateways are busy.
Three habits reduce the damage. Add a random delay and an increasing back-off to the device's join retry, so that devices spread out. Stagger scheduled restarts, instead of rebooting every node at midnight. And on the network side, check how your server handles bursts of joins and how long it keeps the join nonce history, since replayed joins are rejected.
Test the scenario deliberately. Cut the power to a test group of fifty devices, restore it, and time how long the network takes to return to normal. If the answer is hours, the design needs back-off before the first real outage teaches the same lesson at scale.
A power cut is a load test for your join process. Run it on purpose, in a pilot, before it runs itself on the production network.
When a Private LoRaWAN Is the Wrong Answer
A private LoRaWAN network is not always the right tool.
If devices are few and spread over a wide area, such as a handful of tanks across a district, cellular IoT is simpler. A gateway needs enough devices nearby to justify itself.
If devices move across wide regions, like vehicles or containers in transit, a fixed network of gateways cannot follow them, and cellular or satellite links are better.
If each message is large or frequent, or the device needs a response in seconds, LoRaWAN's small payloads and duty cycles are a poor fit.
If nobody on the team can operate it, consider a managed service from a provider, which gives coverage without the gateway maintenance. The price is dependency on a vendor, and whether that is acceptable follows from the same control questions asked of any infrastructure.
And if the target devices are deep inside buildings or basements, check coverage first. LoRa penetrates walls well but not infinitely, and some sites need indoor gateways in addition to an outdoor one.
The Verdict by Use Case
Use case | Gateway class to buy | Key settings and checks |
Farm cluster, tens of nodes, open land | Outdoor, sealed, 8-channel, mast-mounted, with solar or PoE | Test placement, unconfirmed uplinks, surge protection |
Industrial estate, hundreds of nodes | Outdoor 8-channel, PoE, wired backhaul plus cellular backup, GNSS | Extra channels configured, secure server link, two gateways for overlap |
City district or large campus, thousands of nodes | Multiple outdoor gateways, 8 to 16 channels, central management | Coverage survey, downlink budget, monitoring and spares |
Indoor-heavy site, such as a warehouse | Indoor gateways spread through the building, wired backhaul | Test signal at the racks, avoid metal shadowing |
Pilot or demonstration | Indoor or compact outdoor 8-channel unit | Same approvals as production, keep the test record |
Whichever row fits, hold the vendor to the same short list of questions. Which regional parameters and channel plans does the firmware support? Which backhaul protocol, with TLS? What is the ETA number for this exact model? What antenna and cable does the approval cover? What happens when the backhaul fails? How are firmware updates delivered and signed? What is the support commitment and the spare policy?
A vendor who answers these in specific terms has deployed in India before.
Back to Three
Three default channels, 500 milliwatts, 10 percent duty cycle for the gateway: a few small numbers sit behind every sizing decision in this guide.
Count channels before you count devices. Spend downlink airtime on alarms, not routine readings. Keep antenna gain and cable loss inside the limit. Put the gateway where the nodes can see it, and test that before you drill. Carry the paperwork for the model you actually bought.
The gateway on the rooftop is the one component every device depends on. It deserves the attention of a server and not of an accessory.
Related service: LoRaWAN & IoT Connectivity
Related case study: LoRaWAN and ChirpStack Integration for Massive Scale
EurthTech is an engineering-first product design and embedded systems company with a development center in Hyderabad. To discuss a project, write to connect@eurthtech.com or see https://www.eurthtech.com/case-studies.
Comments