An airport terminal is one of the hardest wireless environments in the country to get right. Thousands of unfamiliar devices arrive together, wander through open concourses with almost no walls to shape the signal, and expect to be online within seconds of sitting down at a gate. Behind that same roof sit airline systems, ground handling, retail tenants and airport operational technology that must never share a broadcast domain with a passenger's phone. Immunity Networks & Technologies designs, manufactures and supports the wireless, switching, optics and control layers for that environment as an Indian OEM, with the hardware built at our Sanand GIDC facility in Gujarat and engineering support based in India.
Most enterprise wireless designs assume a reasonably stable population in a reasonably partitioned building. A terminal offers neither. The people change completely every few hours, and the building is deliberately built as one enormous open volume.
Gate hold rooms, security queues and immigration halls concentrate a very large number of devices into a small footprint for a short, predictable window. Designing by square metres rather than by concurrent devices under-provisions exactly the spaces where passengers are most likely to be waiting, bored and connected.
Terminals are built from glass, steel, exposed services and high ceilings. There is very little to attenuate a signal, so cells overlap far more than the designer intended, co-channel interference rises and clients cling to distant access points instead of roaming cleanly to the nearest one.
Traffic follows the flight schedule, not the working day. Festival travel, holiday seasons, weather diversions and bunched departures create surges that a design based on annual average footfall will simply not absorb.
These three realities interact. A concourse that already suffers from excessive cell overlap will degrade fastest at exactly the moment three wide-body departures share a hold room. That is why our engineers treat coverage design and capacity design as separate exercises rather than assuming that one access point count satisfies both. The same discipline underpins our work in high-density campus wireless, but a terminal adds a constraint a university does not have: the passenger is a stranger, using an unmanaged device, who will not raise a support ticket. They will simply form an opinion about the airport.
A terminal is not one wireless environment. It is a sequence of them, and each has a different device population, a different dwell time and a different consequence when it underperforms.
The zoning above drives hardware selection rather than the other way round. Indoor spaces with high ceilings and long sight lines are covered with NetWave Lotus Alpha indoor access points selected and mounted for the mounting height actually available, which in a terminal is frequently a services gantry, a soffit or a purpose-built column enclosure rather than a convenient false ceiling. Aprons, stands, kerbside canopies, cargo areas and perimeter roads are covered with NetWave Lotus Alpha outdoor access points rated for the weather, dust and temperature range those positions actually see. The full family, indoor and outdoor, is described on the NetWave Wi-Fi product pages, and we will confirm current model specifications in writing for the models in your design.
Placement in a terminal is also an aesthetic and structural negotiation, not only an RF one. Architects and terminal infrastructure managers rarely accept visible hardware in a public concourse, and structural teams have views about what may be fixed to a roof truss. Our survey output is therefore expressed as zones and constraints as much as coordinates, so that the design survives contact with the building's own engineering approvals.
This is the part of an airport network that carries genuine risk, and the part that airport IT heads are usually asked about first in any review.
Separation is structural, not advisory. Passenger SSIDs, airline and airport operational systems and each retail or lounge tenant sit on distinct VLAN sets carried by NetForce L2 and L3 switches, with inter-domain policy applied at NetGuard controllers. Baggage handling systems, common-use check-in platforms such as CUTE and CUPPS, the airport operational database and ground-handling devices are treated as an operational domain with its own addressing, its own policy owner and no routed path to or from the public passenger network. Client isolation on the passenger SSID means passenger devices cannot see one another either, which matters more in a terminal than almost anywhere else, because the population is entirely unvetted.
Tenants deserve the same discipline in the opposite direction. A duty-free operator, a lounge, a food and beverage brand or a bank kiosk will each want their own SSID, their own bandwidth policy and their own back-office access, and none of them should be able to see another tenant's payment terminals. That is the same multi-tenant pattern we apply in retail Wi-Fi deployments, scaled to a concession list rather than a store list. The physical layer that carries all of this between terminal risers, satellite piers and the technical block is fibre, which is where NetBeam SFP and SFP+ optics come in — matched to the switch platform so that link-level faults are diagnosed on the same console as everything else.
Airports also operate inside a security context that most enterprises do not. DGCA and BCAS requirements shape who may enter which room, who may hold which credential and how changes to systems in secure areas are authorised. In practical terms this means an airport network project is governed by an access and works regime as much as by an IT design. We plan installation windows, escort requirements and staged commissioning on that basis, and we will not make claims about resilience, redundancy or failover behaviour on a public page — those are engineering commitments that belong in a signed design document, not in marketing copy.
For a great many passengers the captive portal is the only piece of airport IT they will ever consciously use. It should take seconds, work on an unfamiliar device, and give something back.
The portal is where an airport decides whether passenger Wi-Fi is a cost line or a service with a return. Because the splash page is served by the NetGuard controller and rendered as a web page, it can carry live flight information for the passenger's own flight, wayfinding to the correct pier, terminal announcements and language options — which turns a compliance screen into something a passenger actually wants to look at. Commercial teams generally want more than that: sponsored access underwritten by a bank, telecom operator, airline or duty-free brand; a complimentary tier with a paid upgrade for longer or faster sessions; and loyalty programme sign-in that recognises frequent flyers automatically. All three are policy variations applied to a session rather than separate platforms, which keeps the operational burden on the airport's own team modest.
Mandatory logging sits underneath all of it. Indian public Wi-Fi carries clear expectations about session records, and an airport is the least likely place in the country to be given latitude on the point. Sessions are logged with the identity established at authentication and retained according to the retention rule agreed in the design, on infrastructure the airport controls. We will set out exactly what is captured, where it is stored and for how long, in writing, as part of the design documentation rather than as a claim on a web page.
An aviation deployment normally uses every layer of the Immunity stack, designed and manufactured in India at our Sanand GIDC facility in Gujarat, with engineering and support run from our Powai, Mumbai head office.
The NetWave Lotus Alpha family covers terminals indoors and aprons, kerbsides and perimeters outdoors. Model choice follows the survey, and we will confirm current specifications in writing for the models proposed in your design.
NetForce L2 and L3 switches power access points over PoE and enforce the VLAN separation between passenger, operational and tenant domains in hardware rather than as a policy that can be edited away.
NetCloud Central gives terminal operators one AIOps console across piers, satellites and remote facilities, so that a degrading access point in a gate hold room is visible before a passenger complains about it.
Between those layers sit the pieces that decide whether an airport network is pleasant to run. NetGuard controllers handle captive portal, authentication and policy for the passenger and tenant domains. NetBeam optics carry the fibre between the technical block, terminal risers and remote piers. If your wider estate includes offices, cargo facilities, training centres or staff accommodation, those are ordinary enterprise networking problems and can sit on the same management plane rather than becoming a second vendor relationship.
Airport Wi-Fi is no longer purely a terminal-level commercial decision. It sits inside a national conversation about how public and institutional Wi-Fi should be organised.
The Broadband India Forum's 2026 PM-WANI Foundation Report recommends that institutional Wi-Fi across railways, airports, hospitals and campuses be integrated into the national PM-WANI framework, and that parallel closed systems be phased out over time. Immunity's Managing Director co-authored that report as Co-Chair of the BIF Wi-Fi Committee, so the direction of travel is one we have been directly engaged with rather than one we are reading about second hand. For an airport, the practical consequence is worth thinking about early: a terminal that treats passenger Wi-Fi as a completely proprietary island may find itself re-architecting later, whereas one designed with interoperable authentication in mind has an easier path.
Two facts about our own position are frequently confused, so we state them plainly. With BSNL, Immunity is a Public Wi-Fi Partner. Separately, under PM-WANI, Immunity is a certified PDO Aggregator (PDOA). These are two distinct roles under two distinct arrangements, and we are not a PDO. Our PM-WANI page sets out what each role means and what it does and does not allow, which is the right starting point if your tender documentation asks about framework participation.
For a terminal operator, PM-WANI alignment is not an all-or-nothing decision. A passenger SSID can offer app-based PM-WANI authentication alongside conventional mobile OTP and sponsored access, so that passengers who already have a PM-WANI app on their phone are online without touching a portal at all, while everyone else follows the familiar route. That is a portal and policy configuration question, and it is one of the first things we would discuss in a design conversation.
Aviation procurement has constraints that a straightforward enterprise purchase does not, and integrators bidding into it carry most of the risk of getting the specification wrong.
Indian buyers increasingly require MTCTE, TEC and WPC approvals to be demonstrated per model rather than per brand. Ask any vendor, including us, for written per-model confirmation of approval status covering the exact SKUs in the bill of materials, and attach it to the tender response. Our certifications page is the place to start that conversation.
There is rarely a moment when a terminal is empty. Cable routes, riser access, hot works permissions, escorted access and night-only installation windows shape the programme far more than the equipment lead time does. We plan installation in phases that a live building can absorb, and we say so honestly when a proposed timeline is not realistic.
Airport IT teams are small relative to the estate they run and are pulled towards operational systems first. The practical test of a passenger network is whether it can be diagnosed remotely from one console and whether a duty engineer can be talked through a fix. That shapes how we configure and hand over.
Our commercial route into aviation projects is usually alongside a system integrator rather than instead of one, and our partner programme exists for exactly that reason: integrators bidding aviation tenders need design support, a clean bill of materials and someone who will answer a clarification question inside the tender clock. Because we are the OEM, engineering change requests, firmware questions and warranty escalations do not have to travel through an overseas principal before they get an answer.
We have run passenger Wi-Fi deployments at regional airports, and the anonymised case study covering that work is available on request. It is deliberately written up without identifying the operator, and it describes design approach, sequencing and what we would do differently rather than headline numbers. If you want figures for your own terminal, the honest answer is that they come from a survey and a written specification, not from a web page — so ask us to confirm current specifications in writing for whatever design you are evaluating.
Related environments often come up in the same conversation. The traffic-separation pattern here is close to what we deploy for hospital networks, where clinical systems must be walled off from visitor devices, and the branded-onboarding pattern is close to hotel and resort Wi-Fi. A fuller list of the sectors we work in is on the industries page. Datasheets and the anonymised aviation case study sit in downloads, and if you would rather begin with a conversation than a document, contact us and we will put an engineer on the call rather than a salesperson.
Tell us the terminal footprint, the piers and satellites in scope, the operational systems that must stay separate, the tenants who need their own SSIDs and where passengers complain about coverage today. Our engineers will come back with a design approach, a zone-by-zone coverage plan and datasheets, and will confirm current model specifications in writing.
No. Passenger traffic sits on its own VLAN set enforced in NetForce switching hardware, with policy applied at the NetGuard controller, and there is no routed path from the passenger domain into baggage handling, common-use check-in platforms, the airport operational database or ground-handling systems. Client isolation on the passenger SSID also prevents passenger devices from reaching one another.
Yes. Each tenant can be given its own SSID mapped to its own VLAN, with its own bandwidth and access policy, and no visibility of other tenants. This is the same multi-tenant approach used in our retail deployments, applied to a concession list.
Yes. The portal is a web page served by the NetGuard controller, so it can present flight information, terminal announcements, wayfinding and language options alongside the airport's own branding. The specific data source and integration method are agreed during design.
Sponsored access, complimentary tiers with paid upgrades and loyalty-based tiering are handled as session policy on the controller rather than as separate platforms. A sponsor's branding appears on the splash page, and the session receives the rate and duration policy associated with that route.
Session logging is a core function of the controller, tied to the identity established at authentication, with retention configured to the rule agreed in the design and stored on infrastructure the airport controls. We document exactly what is captured, where it is held and for how long as part of the design pack.
No. PM-WANI app authentication can be offered as one option alongside mobile OTP, sponsored access and loyalty sign-in, or not offered at all. The Broadband India Forum's 2026 PM-WANI Foundation Report recommends integrating institutional Wi-Fi at airports, railways, hospitals and campuses into the national framework over time, which is worth factoring into a long-lived design, but it is your decision.
No. Under PM-WANI, Immunity is a certified PDO Aggregator, or PDOA. Separately, and under a different arrangement, Immunity is a Public Wi-Fi Partner with BSNL. The two roles are distinct and should not be treated as interchangeable in tender documentation.
Indian buyers increasingly require MTCTE, TEC and WPC approvals, and the right approach is to ask for written confirmation per model rather than accepting a brand-level statement. Ask us — and every other bidder — to confirm approval status in writing for the exact models quoted, and ask for current specifications in writing as well.