Immunity Networks & Technologies has been designing and manufacturing enterprise networking equipment in India since 2009, from a factory at Sanand GIDC in Gujarat and a head office in Powai, Mumbai. This page is the index to everything we solve: enterprise networking across campus, branch and multi-site estates; switching and routing architecture; high-density campus wireless; network security at the gateway and the edge; PM-WANI public Wi-Fi; and captive portal and guest Wi-Fi. Each solution has its own page. This one explains what each is for, and how the pieces assemble.
Most networking vendors publish a solutions section that is really a second product catalogue with different headings. We have tried to avoid that here. A solution, in the sense we use the word, is a recurring problem that Indian enterprise IT teams bring to us — a hostel block where nothing works after 8pm, a factory that has grown three extensions since the network was designed, a college that has to give ten thousand students access without giving all ten thousand of them the same rights, a public location that has to offer Wi-Fi under a scheme with its own compliance vocabulary. The products are the answer. The solution is the reasoning that gets you to the right answer for your building, your users and your budget.
That reasoning matters more in India than the brochures usually admit. Buildings here are rarely designed around the network. Ceilings are crowded, risers are shared, power is uneven, and the site you are handed on day one is almost never the site described in the drawings. Estates grow by extension rather than by master plan, so a network that was correct for four hundred users becomes a network carrying two thousand without anyone ever taking a decision to make it so. Procurement is genuinely price-sensitive, and support has to be reachable in Indian working hours by people who can be on site rather than on a ticket queue in another time zone. Those constraints shape design as much as any specification sheet does.
So each of the six sections below is written in the same shape: what the problem actually is, how we approach the design, and which products deliver it. Every section then hands off to a dedicated page where the detail lives. If you would rather start from your industry than from the technology, the industries index arranges the same capability by sector — education, healthcare, hospitality, government and rural connectivity. If you would rather start from the hardware, the products index lists the families and what each one is for.
Every item in our Solutions menu, with the problem it addresses and a route into the detail.
Campus, branch and multi-site estates that have to behave as one network rather than a collection of sites that happen to share a logo. Addressing, segmentation, wireless, wired access and central management designed together. See enterprise networking.
Network architecture and design: how ports, VLANs, uplinks and routing between segments are laid out so the estate can grow without being rebuilt. Access, distribution and core, sized to real port counts. See switching and routing.
High-density Wi-Fi 6 for universities, colleges and schools, where hundreds of devices associate in the same lecture theatre within the same two minutes. Channel planning, capacity per room and per-user policy. See campus wireless.
Gateway and edge protection: controlling what leaves the estate, what reaches it, and what one internal segment may say to another. Policy defined once and applied consistently across sites. See network security.
Public Wi-Fi under the Government of India PM-WANI framework, where Immunity operates as a certified PDO Aggregator. The roles, the compliance obligations and the equipment that supports them. See PM-WANI public Wi-Fi.
Branded guest onboarding with PMS integration for hospitality, voucher and OTP journeys, bandwidth control per user class, and the record-keeping Indian operators are expected to hold. See captive portal and guest Wi-Fi.
The six areas are not alternatives to one another. They sit at different points in the same network.
Reading that diagram from the bottom up is the honest order of work. Transport and site interconnect comes first, because fibre routes and uplink capacity decide what the rest of the design is allowed to assume. Distribution and core follow, because that is where segmentation is expressed and where traffic between segments is actually routed. The access layer — wireless access points and the switch ports that feed them — is what users touch, but it is the layer with the least freedom, since it inherits every constraint set below it. Above the access layer sits the security and policy edge, and above that the public-facing and guest experience that most people mistake for the whole network. Running vertically through all of it is the management and assurance plane.
Enterprise Networking, the first of our six areas, is drawn as a bracket rather than a band because it is not a layer at all. It is the discipline of making the other five agree with each other across an estate: the same addressing logic in Mumbai and in a branch four hundred kilometres away, the same segment names, the same policy vocabulary, and one place to look when something changes. Teams that skip that discipline end up with six good decisions that do not compose, which is a harder problem to unpick than any single bad decision.
The problem. An organisation rarely builds its network in one go. A head office is cabled properly. A second floor is added under time pressure. A branch is opened with whatever the local integrator had in stock. A warehouse gets a link because production needed it that week. Individually every one of those decisions was defensible. Collectively they produce an estate where addressing overlaps between sites, where the same department has different rights depending on which building the user is standing in, where nobody can say with confidence how many access points are actually deployed, and where a change at one site has consequences at another that only become visible after the fact.
The design approach. We start from an inventory and an addressing plan, not from a bill of materials. That means agreeing a segment scheme that will still make sense when the estate is fifty per cent larger, allocating address space per site with room to grow, deciding which services are central and which are local, and settling how branches reach the core. Then we size the access layer against real port and coverage counts rather than against a headcount figure, and we specify a single management plane so that the estate can be seen from one place. Where a site has existing equipment that is doing its job, we say so; replacing working infrastructure to tidy up a diagram is rarely a good use of a capital budget.
What delivers it. The full portfolio: NetForce switches at access, distribution and core; NetWave Wi-Fi access points for wireless coverage; NetGuard controllers at the internet edge; NetBeam optics for fibre uplinks between buildings and floors; and NetCloud Central as the management and assurance plane over all of it. The detail, including how we handle phased migrations of a live estate, is on the enterprise networking page.
The problem. Switching gets treated as a commodity purchase — a port count and a price — right up to the point where the network stops behaving predictably. The symptoms are familiar to anyone who has inherited an estate: a flat network where a broadcast storm in one department is felt in every other, uplinks that were adequate when they were installed and are now the constraint on everything above them, VLANs that were created for a reason nobody has written down, and inter-segment routing that happens in whichever device happened to be capable of it at the time. None of this is exotic. It is simply what happens when ports are bought and architecture is not designed.
The design approach. We treat switching and routing as an architecture exercise with three questions. First, what are the segments, and why — separating staff from guests, cameras from clinical systems, production from office, payment devices from everything else. Second, where does traffic between those segments get routed, and is that device positioned where the traffic actually flows. Third, what is the uplink budget from access to distribution and distribution to core, given the wireless capacity being planned above it and the growth expected over the life of the equipment. Only after those three are settled does the port count become a meaningful number. We also plan the physical layer honestly: fibre versus copper, distances, and which optics belong in which uplink.
What delivers it. NetForce switches across Layer 2 and Layer 3, with NetBeam optics for the fibre links between them and NetCloud Central for visibility once the design is live. Read the switching and routing page for how we document a design so that whoever maintains it in three years can follow the reasoning. Specifications vary by model and by production batch, so ask us to confirm current specifications in writing for the specific model before you commit to a bill of materials.
The problem. A university, a college or a school is the hardest wireless environment most Indian integrators will ever be asked to build, and it is hard for a reason that coverage-led design cannot fix. In an office, users arrive over an hour and spread across a floor. On a campus, a bell rings and four hundred devices in one lecture theatre all try to associate within the same ninety seconds. Hostels concentrate heavy evening usage into a few blocks. Examination halls need controlled access for a fortnight and then go quiet. Laboratories have equipment that will not tolerate a roaming decision made at the wrong moment. A survey that only proves signal strength will pass in an empty building and fail on the first day of term.
The design approach. Density-led planning starts from concurrent devices per room, not from square metres. That changes access point placement, channel width decisions, the number of radios per space and the amount of switch capacity that has to sit behind them. It also changes the policy conversation: students, staff, guests, hostel networks, examination networks and administrative systems are different populations with different rights, and they need to be different from the first day rather than separated later under pressure. We plan roaming across corridors and quadrangles so that a device moving from a classroom to a canteen does not drop, and we plan the outdoor spaces — quadrangles, walkways, gate areas — as part of the same design rather than as an afterthought.
What delivers it. NetWave Wi-Fi access points, indoor and outdoor, Wi-Fi 6 capable, with NetForce switches providing the access ports and the uplink capacity behind them, and NetCloud Central for monitoring across blocks. The campus wireless page covers survey methodology and hostel, classroom and open-ground scenarios in detail. Again, ask us to confirm current specifications in writing for the specific model before you finalise a design.
The problem. Security spending in mid-sized Indian enterprises tends to be concentrated at the perimeter and thin everywhere else, which made sense when the perimeter was the only way in. It is a weaker assumption now. Guest devices sit on the same physical infrastructure as finance systems. Cameras, access-control panels, digital signage, biometric readers and building-management controllers all speak IP and very few of them can be patched on a normal cycle. Branch sites often reach the internet directly because backhauling everything to head office was too expensive. The practical question is no longer only what is allowed in, but what each internal segment is permitted to say to every other, and whether that answer is the same at every site.
The design approach. We work outward from segmentation, because policy without segmentation is a wish. Once segments exist and are routed deliberately, the gateway becomes a place to express intent: which segments reach the internet and under what controls, which may reach each other, what is logged, and what happens to guest traffic. Content and application controls, bandwidth allocation between classes of user, and the retention of access records all sit here. We then make sure the same policy vocabulary is used at every site, because the most common security failure we are called in to fix is not a missing control — it is the same control configured six different ways across six locations.
What delivers it. NetGuard controllers at the gateway and edge, NetForce switches enforcing segmentation in the wiring, and NetCloud Central for cross-site visibility. The network security page sets out the control set in detail. Feature availability differs between models and firmware releases, so ask us to confirm current specifications in writing for the specific model rather than working from a general description.
The problem. PM-WANI — the Prime Minister's Wi-Fi Access Network Interface framework — is a Government of India scheme for public Wi-Fi, and most of the confusion around it is not technical. It is about roles. The framework defines a Public Data Office, which is the entity that physically operates a hotspot; a Public Data Office Aggregator, which authorises and manages PDOs and handles the authorisation and accounting functions on their behalf; an app provider, which is how the end user discovers and connects; and a central registry. A shop owner, a bus depot or a panchayat can be a PDO. An organisation that wants to enable many PDOs needs an aggregator behind it. Buying equipment before deciding which role you are playing is the usual reason a PM-WANI project stalls.
Where Immunity sits. Under PM-WANI, Immunity Networks is a certified PDO Aggregator, or PDOA. That is a specific, registered role and we describe it precisely. Separately, and this is a different relationship that should never be conflated with the first, Immunity is a Public Wi-Fi Partner with BSNL. Being a BSNL Public Wi-Fi Partner does not make us a PDO, and being a PDOA under PM-WANI is not the same thing as the BSNL partnership. If a proposal you have been given blurs those two, ask the vendor to separate them in writing before you evaluate anything else in the document.
The design approach and what delivers it. We start by establishing which role you intend to occupy, what the authorisation journey should look like for your users, how sessions are accounted for, and what records the deployment has to keep. Only then do we specify hardware. Typically that means NetWave access points, indoor or outdoor depending on the site, NetGuard controllers handling authorisation and session control, and NetCloud Central for management across a distributed hotspot estate, with NetForce switches where a location needs more than a single access point. The PM-WANI page explains the framework, the roles and the onboarding process in full.
The problem. For a hotel guest, a hospital visitor, a retail customer or a delegate at a conference, the captive portal is the entire network. It is the only part they see, and it is the part they will describe to somebody else. Yet it is routinely the least designed element of a deployment: a default splash page, a shared password that has been the same for two years, no way to tell a paying guest from a passer-by in the car park, no bandwidth separation so one large download degrades the experience for a whole floor, and no usable record of who connected and when. In hospitality specifically, a portal that cannot verify a guest against the property management system means the front desk ends up doing manually what the network should be doing automatically.
The design approach. We treat the portal as three separate decisions that are usually collapsed into one. First, identity: how does the network know who this person is — PMS lookup against room and surname, OTP to a mobile number, a voucher issued at a desk, a social or email sign-in, or a sponsored guest flow. Second, entitlement: what does this class of user get, for how long, at what bandwidth, and what happens when the entitlement expires. Third, presentation and record-keeping: the portal carries your branding and your terms, in the languages your visitors actually read, and it keeps the access records that Indian operators are expected to be able to produce. Getting those three right is what separates a guest network people compliment from one they complain about.
What delivers it. NetGuard controllers host the portal and enforce entitlement, NetWave access points provide the coverage, and NetCloud Central gives operators visibility across properties or branches. The captive portal and guest Wi-Fi page covers PMS integration, voucher workflows, branding and compliance in detail.
The same five product families assemble into all six solutions. This is which ones do the work in each.
The pattern in that matrix is worth reading deliberately, because it is the argument for buying a portfolio rather than a component. NetCloud Central appears as a primary element in five of the six rows, which tells you that management and assurance is not an add-on to any of these solutions — it is part of all of them. NetForce switches appear in every row, because there is no wireless deployment, no security policy and no public Wi-Fi hotspot of any size that does not ultimately depend on the wired ports underneath it. NetGuard controllers carry the two solutions where user identity and entitlement are the whole point. NetWave access points carry the two where physical coverage is the whole point. NetBeam optics appear where distance between buildings or floors makes fibre the only sensible answer.
A single OEM behind all five has a practical consequence at procurement and at fault time. Commercially, it means one quotation, one warranty conversation and one set of lead times rather than four vendors each blaming the other three. Operationally, it means that when something misbehaves at two in the morning, the engineer you reach can look at the access point, the switch port, the gateway policy and the management record without an escalation matrix in between. That is the whole argument, and we would rather state it plainly than dress it up. Browse the full portfolio on the products page, or see how the same stack is applied by sector on the industries page.
Indian enterprise and public-sector buyers are asking harder procurement questions than they were five years ago, and rightly so. Certification is increasingly one of them. Mandatory Testing and Certification of Telecom Equipment, administered under TEC, and equipment licensing through WPC for products using licence-exempt radio spectrum, are requirements that many tenders now reference explicitly. Our position on this is deliberately conservative: rather than making a blanket claim on a web page, ask us — and ask every vendor on your shortlist — for written, per-model confirmation of exactly which certifications apply to exactly which model you are buying, with the certificate reference. A vendor who cannot produce that on request is telling you something useful. Our certifications page is the right place to start that conversation.
The same principle applies to specifications generally. Ranges change, components change, and a specification table published on a website eighteen months ago is a liability rather than a service. We would rather you asked us to confirm current specifications in writing for the specific model, against the actual quantity and configuration you intend to order, than have you build a tender around a number we published for a previous revision. If you are working to a tender deadline, tell us the date and we will work to it.
Two other things are worth establishing early. First, support: our engineering team is in India, working Indian hours, and site attendance is a normal part of what we do rather than an exception that requires a separate contract. Second, the commercial route: many projects reach us through system integrators and channel partners rather than directly, and if you already have an integrator you trust, we would rather work through them than around them. The partners page explains how that works. Whichever route you take, the technical conversation is the same one, and it starts at contact us or with the datasheets on the downloads page.
Send us drawings, an occupancy plan, a port count or simply a description of what is going wrong today. Our India-based engineers will tell you which of these six solutions your requirement actually is, what we would deploy, and what we would leave alone. If a site survey is needed, we will say so. If your existing infrastructure can carry the design, we will say that too.
Start from the symptom rather than the category. If the complaint is that wireless fails when a space fills up, it is a campus wireless question. If it is that sites behave differently from one another, it is an enterprise networking question. If it is that the network is flat and slow at peak, it is a switching and routing question. If it is about who can reach what, it is network security. If visitors are the users, it is captive portal and guest Wi-Fi, or PM-WANI if you are offering public Wi-Fi under that scheme. Most real projects turn out to be two or three of these at once, which is why they are designed together.
No. Under the PM-WANI framework Immunity Networks is a certified PDO Aggregator, or PDOA — the role that authorises and manages Public Data Offices. Separately, and this is a distinct relationship, Immunity is a Public Wi-Fi Partner with BSNL; that partnership does not make us a PDO. The two should never be conflated in a proposal or a tender response. The PM-WANI page sets out the roles in the framework in full.
We do not make blanket certification claims on this page, because certification is granted per model and the correct answer for one model is not automatically the correct answer for another. Indian buyers increasingly require MTCTE, TEC and WPC evidence in tenders, and you should ask any vendor — including us — for written, per-model confirmation with certificate references before you finalise a bill of materials. Raise it with us through contact us or start at the certifications page.
Yes, and most estates are built that way. The thing that makes later phases straightforward rather than painful is agreeing the addressing plan, the segment scheme and the policy vocabulary at the start, even for the parts you are not buying yet. A campus wireless rollout designed against a segment scheme that anticipates guest access, PM-WANI hotspots and future branch sites will absorb those additions. One designed only for the immediate purchase order usually has to be revisited. We are happy to document the target design and then quote the first phase against it.
Each product family has its own page — NetWave WiFi, NetForce switches, NetGuard controllers, NetCloud Central and NetBeam optics — and datasheets are on the downloads page. For anything that will appear in a purchase order or a tender, ask us to confirm current specifications in writing for the specific model. Published material describes capability; written confirmation against a model and a quantity is what you should rely on commercially.
Both. A large share of our projects reach us through system integrators, consultants and channel partners who already hold the customer relationship, and where that is the case we work through them rather than around them. We also engage directly with enterprise IT teams, particularly at the design and evaluation stage. Either way the engineering conversation is the same, and the design work happens before any commercial route is settled. See the partners page for how the channel programme works, or write to us through contact us.