Doc #133 — Local Network Architecture

---

RECOMMENDED ACTIONS (BY URGENCY)

First 30 days:

1. Mirror critical internet content to NZ-hosted servers and local storage devices while any international connectivity remains (see also Doc #132 Section 6.4)
2. Identify and protect NZ Internet Exchange Point (NZIX) infrastructure — this is the domestic internet’s backbone¹
3. Issue guidance to organisations: back up all cloud-hosted data to local servers immediately

First 3 months:

4. Include networking equipment in the national asset census (Doc #8) — routers, switches, access points, servers, Ethernet cabling, fibre patch leads, uninterruptible power supplies
5. Designate IT infrastructure maintenance as an essential service; retain key network engineers
6. Begin establishing community file servers at libraries, schools, and Civil Defence centres with mirrored copies of Recovery Library content, medical references, agricultural databases, and technical manuals

First year:

7. Pilot mesh network deployments in 3–5 towns to develop standardised configurations and deployment procedures
8. Begin training community network administrators through the trade training framework (Doc #157)
9. Establish regional network equipment depots — stockpile recovered routers, switches, cables, and access points from decommissioned sites

Years 1–3:

10. Roll out community networks to all towns of 2,000+ population
11. Develop standardised “community intranet” content packages for distribution to isolated communities
12. Transition from internet-dependent services to locally hosted alternatives

Years 3+:

13. Interconnect community networks into regional intranets where fibre or wireless backhaul remains functional
14. Develop power-optimised network designs for communities relying on intermittent or renewable power

---

ECONOMIC JUSTIFICATION

Person-years and cost

The primary investment is labour for network setup and maintenance. Equipment already exists — the task is repurposing it, not manufacturing it.

Community file server deployment (per site): Approximately 2–5 person-days for initial setup (hardware selection, operating system installation, content loading, basic network configuration, user documentation). With 200–300 community sites targeted nationally, total initial deployment is roughly 2–6 person-years of IT labour spread across the country.

Community mesh network deployment (per town): Approximately 5–20 person-days depending on town size and terrain, covering site survey, access point installation, configuration, and testing. For 50–80 towns, total deployment is roughly 3–8 person-years.

Ongoing maintenance: Each community network requires approximately 0.05–0.1 person-years of annual maintenance (roughly 2–5 weeks of part-time attention from a trained community administrator). For 200 sites, this is 10–20 person-years per year nationally — but this is distributed across local communities, not concentrated in a single team.

Comparison with alternatives

Without local networks: Communities lose access to digital knowledge as the internet contracts. Information stored on individual computers is fragmented, inaccessible to others, and lost when individual devices fail. Printed copies of critical references (Doc #5) are the only fallback — valuable, but limited in volume and not searchable.

With local networks: Centralised community file servers preserve searchable digital knowledge accessible to multiple users simultaneously. A single 4TB hard drive can store the equivalent of millions of pages of text — more than any community could print. Medical references, engineering manuals, agricultural databases, Recovery Library documents, educational materials, and locally generated records (census data, resource inventories, maintenance logs) remain accessible as long as the server and a basic network function.

Breakeven: The labour investment pays for itself almost immediately. A community with a functioning file server and local network has access to vastly more reference material than one relying solely on printed copies. The practical question is not whether this is worthwhile — it is — but whether the IT labour can be spared from other priorities. Given that NZ has approximately 100,000–120,000 people employed in the broader IT sector (including software, infrastructure, and support roles), dedicating a few thousand to network preservation is a modest allocation.²

---

1. NZ’S EXISTING LOCAL NETWORK INFRASTRUCTURE

1.1 What is already deployed

NZ has extensive local networking infrastructure, most of it deployed for internet access that will eventually cease to function. The installed base includes:

Domestic routers and access points. Approximately 1.8–2.0 million broadband connections exist in NZ, each served by a router/access point (typically a combined device provided by the ISP — Spark, One NZ, 2degrees, or smaller providers).³ These devices provide Wi-Fi and typically 4 Ethernet ports. They are designed for internet access but are equally capable of serving a local network with no internet connection. Most run embedded Linux-based firmware that can be reconfigured.

Enterprise and institutional networking. Schools, hospitals, government offices, universities, and businesses operate local networks with commercial-grade switches, access points, servers, and structured Ethernet cabling. NZ has approximately 2,500 schools, 20 universities and polytechnics, hundreds of government offices, and thousands of businesses with IT infrastructure.⁴ This equipment is typically higher-quality, more configurable, and longer-lived than domestic devices.

Ethernet cabling. Structured cabling (Cat5e, Cat6) is installed in virtually every commercial and institutional building built or refurbished in the past 25 years. This cabling is passive copper — it does not degrade in use and has an indefinite lifespan if physically undamaged. The cabling is already in the walls. It costs nothing to repurpose.

Fibre patch infrastructure. NZ’s UFB programme (Doc #127) installed fibre to approximately 87% of premises.⁵ While the wide-area fibre network depends on OLT equipment at exchanges (which will eventually fail), the fibre cables between nearby buildings — and the passive optical splitters — can potentially be repurposed for building-to-building local connections if appropriate terminal equipment is available. This is a secondary consideration; Ethernet and Wi-Fi are simpler and more flexible for local networks.

Servers and storage. NZ has thousands of servers in data centres, offices, and institutions. As internet services contract, many of these servers become available for local use. Even modest hardware — a desktop computer repurposed as a file server — can serve dozens of simultaneous users on a local network.

1.2 Equipment lifespan

Networking equipment fails through the same mechanisms as other electronics (see Doc #115 Section 2.1): electrolytic capacitor aging, semiconductor degradation, connector corrosion, and mechanical wear (fans).

Estimated lifespans under careful use:

Equipment Type	Typical Lifespan	Primary Failure Mode	Notes
Consumer router/access point	5–10 years	Capacitor aging, power supply failure	Large installed base; many spares available
Enterprise switch	10–20 years	Capacitor aging, fan failure	Higher build quality; fans replaceable
Enterprise access point	8–15 years	Capacitor aging	PoE-powered models eliminate internal power supply (a common failure point)
Ethernet cable (Cat5e/Cat6)	30+ years	Physical damage only	Passive copper; essentially permanent if undisturbed
Hard drives (HDD)	5–10 years	Mechanical wear (bearings, heads)	Spinning disks; store spares, keep backups
Solid-state drives (SSD)	10–20 years	Flash cell wear, controller failure	Limited write cycles but long read life; excellent for static content
Server hardware	8–15 years	Capacitor aging, power supply, fans	Fans and power supplies are the most replaceable components
Uninterruptible power supply (UPS)	Battery: 3–5 years; electronics: 10–15 years	Battery degradation	Batteries can be replaced with locally produced lead-acid (Doc #35)

These are estimates with wide variance depending on environmental conditions, manufacturing quality, and usage patterns. NZ’s temperate climate is favourable — heat is the primary enemy of electronics, and NZ rarely experiences the sustained high temperatures that accelerate degradation.

The spares advantage: NZ has far more networking equipment than it needs for local networks. If 80% of domestic routers are surplus to local networking requirements, they represent a vast pool of spare parts and replacement units. The challenge is not equipment scarcity — it is organisation and distribution.

1.3 Equipment that NZ cannot produce

Networking equipment contains semiconductors (processor chips, memory, Ethernet PHY chips, Wi-Fi radio chips) and other precision components that NZ cannot manufacture. The dependency chain for even a basic Ethernet switch illustrates why:

• Semiconductor fabrication requires photolithography equipment (UV light sources, precision optics, photoresist chemicals), ultra-pure silicon wafers (99.9999%+ purity, requiring zone refining and Czochralski crystal growth), clean-room facilities (ISO Class 5 or better), and process gases (argon, nitrogen, silane) — none of which NZ can produce at the required purity or scale.
• Printed circuit boards require copper-clad laminate (fibreglass and epoxy resin, typically imported), photoresist, ferric chloride or ammonium persulfate etchant, solder paste (tin-lead or tin-silver-copper alloy), and precision drilling equipment for via holes.
• Passive components (capacitors, resistors, inductors) require specialised ceramic dielectrics, thin metal films, and precision manufacturing tolerances that depend on imported materials and equipment.

There is no pathway to domestic production of networking silicon within any foreseeable timeframe (see Doc #134 for the computing self-sufficiency timeline). The strategy is entirely about extending the life of existing equipment through careful use, maintenance, and cannibalisation — not about manufacturing replacements. The practical ceiling is set by equipment attrition rates (Section 1.2) and the effectiveness of component-level repair (Doc #130).

---

2. COMMUNITY FILE SERVERS — THE CORE APPLICATION

2.1 Why file servers matter

The single most valuable application of local networking under isolation is the community file server: a computer with large storage capacity, connected to a local network, serving digital content to anyone who connects.

Consider what can be stored on a modest 4TB hard drive:

• The entire English Wikipedia (approximately 22 GB compressed, ~90 GB uncompressed with images)⁶
• The complete Recovery Library (all 172 documents — perhaps 50–100 MB total as formatted text)
• Medical references: the Merck Manual, WHO treatment guidelines, essential drug formulary, surgical atlases — perhaps 2–5 GB
• Agricultural databases: NZ-specific crop data, livestock management, pest identification — perhaps 1–2 GB
• Engineering references: machinery handbooks, electrical codes, materials specifications, construction standards — perhaps 5–10 GB
• Educational materials: textbooks for primary through university level across core subjects — perhaps 10–50 GB
• NZ-specific data: topographic maps, geological surveys, census data, legislation, standards — perhaps 5–20 GB
• Software repositories: operating systems, tools, development environments — perhaps 50–100 GB

Total: well under 500 GB, leaving 3.5 TB free for locally generated content — community records, resource inventories, training materials, correspondence archives, and research notes. A single drive stores more reference material than any community library.

The value proposition is access. A printed Recovery Library might occupy several shelves and serve one reader at a time. A file server serves the same content (and vastly more) to dozens of simultaneous users, with full-text search capability.

2.2 Hardware requirements

A community file server does not require specialised server hardware. Any reasonably modern computer can serve files to a local network:

Minimum viable configuration:

• Any x86 or ARM computer manufactured after approximately 2010
• At least 2 GB RAM (4 GB+ preferred)
• At least one storage drive (HDD or SSD) for content
• Ethernet port (present on virtually all desktop computers)
• A stable power supply

Recommended configuration for a community library server:

• Desktop computer or repurposed business workstation (Dell OptiPlex, HP ProDesk, Lenovo ThinkCentre — NZ has an estimated 2–3 million business desktop and laptop computers across offices, schools, and government agencies)⁷
• 8–16 GB RAM
• Two storage drives in a mirrored configuration (RAID 1 or equivalent), so that a single drive failure does not destroy the data
• Gigabit Ethernet connection to a local switch
• UPS with 30–60 minutes of battery backup (to allow clean shutdown during power interruptions)
• Linux operating system (free, stable, low-resource, well-suited to file serving — specifically Debian or Ubuntu Server, which have large NZ user communities)

Power consumption: A typical desktop computer repurposed as a file server draws 30–80W under load, depending on hardware.⁸ A single-board computer (Raspberry Pi 4 or 5) can serve files to a small network drawing only 5–15W, though with reduced performance for many simultaneous users.⁹

Low-power option for intermittent power environments: A Raspberry Pi or similar ARM single-board computer, combined with an SSD (no spinning disk — lower power, more resilient), a small battery bank, and a solar panel, can operate entirely off-grid. NZ has thousands of Raspberry Pi units in schools, hobbyist collections, and IT departments. These suit remote community deployments where grid power is unreliable. Performance gap versus desktop server: a Raspberry Pi 4 has approximately 5–15% of the processing throughput and 25–50% of the memory capacity of a typical repurposed business desktop. Under concurrent access by more than 10–15 users, response times for file serving degrade noticeably, and full-text search across large document collections (>50 GB) becomes slow (seconds to tens of seconds per query versus sub-second on desktop hardware). For communities with fewer than 15 simultaneous users accessing primarily text-based content, the Pi is adequate; for larger communities or those requiring search-intensive use, a desktop server is strongly preferred.

2.3 Software

Operating system: Linux is the clear choice for community file servers. It is free (no license server to contact — unlike Windows Server, which requires activation that may be impossible without internet), stable (servers routinely run for years without reboot), well-documented, and has a large NZ user community including professional system administrators.¹⁰ Debian Linux is particularly well-suited — it prioritises stability, supports the Raspberry Pi and x86 hardware, and has excellent package management for installing server software. NZ mirror sites (e.g., mirror.fsmg.org.nz) host Debian packages domestically, meaning installation media and updates can be sourced without international connectivity if mirrored early.

File sharing: Samba (for Windows-compatible file sharing) and NFS (for Linux/Mac clients) are standard and mature. Configuration requires understanding of file permissions, network shares, and authentication — a Level 1 administrator (Section 8.1) can manage this with printed documentation, but initial setup benefits from Level 2 expertise. Any device on the local network can browse and read shared files using built-in operating system capabilities — no special client software required.

Web-based access: A lightweight web server (Nginx or Apache) can serve content as a local website — an “intranet.” Users connect with any web browser and navigate the content as they would a website, but all traffic stays on the local network. This is particularly useful for serving formatted documents (HTML, PDF) and for providing a familiar interface to non-technical users.

Search: Full-text search of documents stored on the server is provided by tools like Recoll, Xapian, or simple command-line search. This is one of the most significant advantages over printed material — finding a specific piece of information in a large document collection takes seconds rather than hours.

Content management: For communities generating local content (meeting minutes, resource inventories, technical notes, training materials), a lightweight wiki (DokuWiki or MediaWiki) provides structured collaborative authoring. MediaWiki is the same software that powers Wikipedia and runs comfortably on modest hardware.

2.4 Content preparation — the critical early action

The most time-sensitive aspect of community file servers is not the hardware or software — it is the content. While international internet connectivity exists (hours, days, or weeks after the event, depending on submarine cable status), NZ should aggressively download and cache critical content.

Priority content for download/mirroring:

1. Wikipedia — the most comprehensive general reference available. Offline copies are available as pre-built packages (Kiwix project provides compressed offline Wikipedia).¹¹
2. Medical references — WHO essential medicines list, clinical treatment guidelines, surgical references. Some are available as open-access downloads.
3. Agricultural databases — FAO data, NZ-specific crop and livestock references from Massey University, Lincoln University, AgResearch, and Plant & Food Research.
4. Engineering and technical standards — NZ Building Code, electrical regulations, engineering handbooks. Many NZ standards are accessible through the Standards NZ website.
5. Educational materials — Open-access textbooks, Khan Academy content (video and text), university course materials under Creative Commons licenses.
6. Software and documentation — Linux distribution ISOs, programming language documentation, system administration guides. NZ mirror sites (e.g., mirror.2degrees.nz) already host some of this content domestically.
7. NZ-specific datasets — LINZ topographic data, GeoNet earthquake and geological data, NIWA climate data, Stats NZ census data.

Assumption: Some of this content is already cached on NZ servers, CDN nodes, and institutional systems. The task is not downloading everything from scratch — it is ensuring that NZ-hosted copies exist and are preserved. This effort should be centrally coordinated (perhaps through the National Library, university libraries, or NZIX participants) to avoid duplication and ensure completeness.

2.5 Deployment locations

Community file servers should be deployed at locations that are:

• Publicly accessible (or at least accessible to community members)
• Physically secure
• Powered (grid, with backup)
• Staffed by someone with basic IT competence (or willing to be trained)

Priority deployment sites:

Location Type	Why	Notes
Public libraries	Existing public access, staff with information management skills, often have IT infrastructure already	NZ has approximately 300 public library sites12
Schools	IT infrastructure exists (computers, network), serve as community hubs, teachers can be trained	Approximately 2,500 schools
Marae	Community hubs in Māori and mixed communities, existing gathering infrastructure	Partnership with iwi for deployment and management
Civil Defence centres	Government coordination points, need reference access, existing communication infrastructure	Regional and local emergency management offices
Hospitals and health centres	Medical reference access is critical, existing IT infrastructure	District hospitals, community health centres
University and polytechnic campuses	Extensive IT infrastructure, technical expertise on site	8 universities, 16 polytechnics/institutes of technology13

Not every site needs identical content. A hospital server prioritises medical references. A school server prioritises educational materials. All should carry the Recovery Library and general reference materials (Wikipedia, agricultural guides). Content packages should be modular — additional collections can be added as storage and needs dictate.

---

3. LOCAL AREA NETWORK DESIGN

3.1 The simplest useful network

The minimum useful local network is a single switch (or router) connecting a file server to several client devices (computers, laptops, tablets). This requires:

• One Ethernet switch (any consumer or enterprise switch — 5-port, 8-port, or larger)
• Ethernet cables connecting the server and client devices to the switch
• A file server configured to share files (Section 2.3)
• Client devices with Ethernet ports or Wi-Fi capability

A person with network configuration experience can set this up in 1–3 hours, including IP configuration, DHCP setup, and verifying client connectivity. No internet connection is needed. No ISP is involved. The network is entirely self-contained.

DHCP and addressing: A router (even a consumer Wi-Fi router with internet port unused) provides DHCP — automatic IP address assignment — so that client devices can connect without manual configuration. Alternatively, a Linux file server can run a DHCP server directly. Either approach works; the router approach is simpler for non-technical administrators.

3.2 Building-scale network

For a library, school, or community centre, the network extends to cover multiple rooms or an entire building:

• A central switch (24-port or 48-port enterprise switch) in a utility room or communications cabinet
• Ethernet cable runs to each room (likely already installed in most institutional buildings)
• Wi-Fi access points in areas where wireless access is needed
• The file server connected to the central switch

Structured cabling already installed in NZ institutional buildings reduces deployment effort significantly, though building-scale networks still require someone with IP networking knowledge to configure switches, DHCP, and access points correctly. The existing cable runs — from a patch panel in a communications room to wall outlets in each office, classroom, or reading room — are purpose-built for this exact use. No new cabling is needed.

Power over Ethernet (PoE): Many enterprise switches support PoE — delivering electrical power over the Ethernet cable to devices like access points and IP phones. This simplifies access point deployment (no separate power outlet needed at each access point location) and is a feature of switches already deployed in NZ institutional buildings. PoE switches should be specifically preserved and prioritised for community network deployments.

3.3 Town-scale network: wireless mesh

Connecting multiple buildings across a town — the library, the school, the hospital, the council office, the marae — requires either running cable between buildings (expensive and slow) or using wireless links. Wireless is the practical approach.

Point-to-point wireless links: Directional Wi-Fi equipment (such as Ubiquiti airMAX, MikroTik, or similar devices widely deployed in NZ for rural internet) can bridge distances of 1–15 km with line of sight.¹⁴ A directional antenna on the library roof aimed at a directional antenna on the school roof creates a high-bandwidth link between the two buildings’ local networks. Each link requires two devices (one at each end), line of sight, power at both ends, and basic configuration.

NZ already has significant deployment of this equipment. Rural wireless internet service providers (WISPs) use point-to-point and point-to-multipoint wireless equipment extensively. The Rural Broadband Initiative and various WISP operators have deployed thousands of these devices.¹⁵ As internet backhaul fails, this equipment can be repurposed for local inter-building links.

Mesh networking: A mesh network uses multiple wireless nodes that automatically discover each other and route traffic between them. If any single node fails or any single link is obstructed, traffic routes around the failure through alternative paths. Mesh networking firmware (such as OpenWrt with batman-adv, or LibreMesh) can be installed on many consumer and enterprise routers, turning them into mesh nodes.¹⁶ Performance gap versus dedicated point-to-point links: mesh routing adds latency (each hop adds 2–10 ms) and reduces effective throughput (each intermediate hop roughly halves available bandwidth for that traffic flow, since the same radio must receive and retransmit). A three-hop mesh path might deliver 15–30% of the throughput of a single direct link. Mesh networks trade raw performance for redundancy and ease of deployment.

A mesh network covering a small NZ town (population 1,000–5,000, typical footprint 1–3 km across) might use 5–20 nodes, placed on rooftops or elevated locations across the town. Each node connects to nearby nodes wirelessly, forming a fabric of redundant links. Any device connected to any node (by Ethernet or Wi-Fi) can access any service on any other node — including the community file server. NZ’s predominantly single- and double-storey building stock means roof-mounted nodes typically achieve 5–10 m elevation, adequate for short-range links but limiting compared to taller urban structures.

Mesh network practicalities:

• Range between nodes: 100 metres–2 km depending on antenna type, frequency (2.4 GHz has better range than 5 GHz but lower bandwidth), and obstructions
• Bandwidth: Adequate for file serving and text-based content (10–100+ Mbps per link depending on equipment). Not adequate for high-definition video streaming, but video streaming is not the priority use case
• Power per node: 5–15W for a typical consumer router running mesh firmware; 10–30W for outdoor directional equipment¹⁷
• Configuration: Requires someone who understands IP networking — specifically subnetting, routing protocols, and wireless channel management. Not beginner-level, but well within the capability of NZ’s IT workforce. Once configured, mesh networks are largely self-managing, though periodic monitoring is needed to identify degraded links or failed nodes
• Weather resilience: Outdoor wireless equipment designed for NZ conditions (UV-resistant enclosures, weatherproof connectors) is already deployed across the country. Consumer routers deployed outdoors need weatherproof enclosures — plastic electrical junction boxes work

3.4 Addressing and naming

When networks are no longer connected to the global internet, the Domain Name System (DNS) that translates names (like “library.local”) to IP addresses must be handled locally.

Practical approach: Use a local DNS server (configured on the same Linux machine as the file server using dnsmasq or similar lightweight software — requires editing configuration files and understanding DNS resolution order) that resolves local names. Devices configured to use the local DNS server can access “library.townname.local” or similar intuitive names instead of remembering IP addresses.

Addressing scheme: Use the private IP address ranges already standard for local networks (192.168.x.x, 10.x.x.x, or 172.16.x.x). For regional interconnection, a coordinated addressing scheme prevents conflicts — each town or community is assigned a unique subnet from the 10.x.x.x range (which provides over 16 million addresses, vastly more than needed).

A national coordination body — perhaps attached to NZIX or the InternetNZ successor organisation — should publish and maintain the addressing scheme. The administrative overhead is modest (maintaining a registry document and resolving allocation conflicts), but failing to coordinate early forces painful renumbering later when networks are interconnected.

---

4. REGIONAL INTERCONNECTION

4.1 When local networks connect

Individual community networks are valuable on their own, but connecting them into regional intranets multiplies their value. A doctor in Masterton can access medical references on a server in Wellington. A farmer in Ashburton can retrieve crop data from a server at Lincoln University. Communities can share locally generated knowledge — “we found this method works for seed treatment” — across districts.

Regional interconnection depends on surviving wide-area network infrastructure:

Fibre backbone (best case): If the inter-city fibre backbone described in Doc #127 survives (likely for years to decades with proper maintenance), it can carry traffic between community networks in different towns. A community network in Hamilton connects to the surviving fibre infrastructure at the local exchange, which carries traffic to a community network in Tauranga. This is essentially how the domestic internet works now, minus the international connectivity.

Point-to-point wireless (medium case): Where fibre links have failed, point-to-point wireless bridges can span distances of 10–50 km between hilltop relay points, using the same directional wireless equipment described in Section 3.3 but with higher-gain antennas and higher-power radios.¹⁸ NZ’s mountainous terrain is actually advantageous for this — hilltop sites with wide visibility are common, and many already have power (cell tower sites, repeater sites).

Sneakernet (fallback): When no electronic link exists, data can be physically transported on USB drives, hard drives, or SD cards. A person travelling between communities can carry a hard drive containing updated content — the modern equivalent of the postal service for bulk data. This is slow (days to weeks, not seconds) but high-bandwidth for bulk transfers (a 1TB drive carried by hand transfers data at an effective rate of many gigabits per second over a day-long journey, far exceeding any radio link). Regular content synchronisation between community file servers can be maintained this way even with no electronic interconnection. Performance gap compared to electronic links: sneakernet latency is measured in days rather than milliseconds, making it unsuitable for interactive use (email, queries, coordination). It is a bulk data distribution mechanism only — communities relying solely on sneakernet lose the ability to request specific information on demand and must instead receive periodic content dumps. Update frequency depends entirely on transport logistics and may range from weekly (near main routes) to monthly or less (remote communities).

4.2 The domestic intranet

If NZ successfully maintains its fibre backbone and core network equipment (the Tier 1 assets described in Doc #127), the domestic internet effectively becomes a domestic intranet — a nationwide network connecting NZ institutions, communities, and individuals, but with no international connectivity.

This intranet is enormously valuable:

• Government coordination: Central and local government communicate via email, file transfer, and web-based tools — faster and more capable than HF radio for administrative traffic
• Knowledge sharing: Any content hosted on any NZ server is accessible from anywhere on the network
• Resource coordination: The National Resource Authority (Doc #1) and regional coordinators access census data, inventory systems, and planning tools across the country
• Education and training: Distance learning continues for communities with network access. Universities can share course materials nationally.
• Healthcare coordination: Medical records, treatment protocols, and specialist consultation via telemedicine (video or at least text) between hospitals

The transition: The domestic intranet does not need to be “built” — it already exists. It is the NZ portion of the current internet, minus international routes. The transition is about recognising this, ensuring critical services are hosted domestically (not on international cloud infrastructure), and maintaining the network equipment that carries domestic traffic. Performance gap versus pre-event internet: the domestic intranet loses all internationally hosted services (the majority of current web content, cloud applications, software updates, and streaming services). Domestically hosted alternatives for email, file sharing, and collaboration exist (NZ-based providers and self-hosted solutions) but lack the breadth and polish of international platforms. NZ-hosted content represents a small fraction of what NZ users currently access online.

4.3 Content distribution and synchronisation

As the network contracts (some links fail, some regions lose connectivity), a systematic approach to content distribution becomes necessary:

Hub-and-spoke content distribution: A small number of “content hubs” — likely at existing NZ data centre clusters in Auckland (Datacom, Spark data centres in Albany and Mayoral Drive), Wellington (Government IaaS at Revera/CCL), and Christchurch (REANNZ/university facilities) — maintain master copies of reference content. Periodically — weekly, monthly, or whenever connectivity allows — community file servers synchronise with the nearest content hub to receive updates. The Linux tool rsync is purpose-built for this: it efficiently transfers only the changes since the last synchronisation, minimising bandwidth use.¹⁹

Offline content packs: For communities without any electronic link to a content hub, content is distributed on physical media (USB drives, hard drives). Content packs are prepared at regional hubs, labelled by version and date, and distributed through postal service, supply runs, or travellers. Each community server’s administrator applies the update locally.

Locally generated content propagation: Content flows in both directions. A community that develops useful local knowledge (agricultural observations, repair techniques, medical case reports) can package it and send it upstream to the content hub for distribution to other communities. This turns the network into a collective knowledge-building system.

---

5. POWER-EFFICIENT NETWORK DESIGN

5.1 Why power matters

Under the baseline scenario (Doc #3), grid power continues from NZ’s 85%+ renewable generation. But grid power is not infinite or guaranteed at every location at every moment. Localised outages occur. Some remote communities may lose grid connection. Power generation capacity may be allocated to higher priorities than keeping networking equipment running 24/7.

Designing networks for low power consumption:

• Extends battery backup duration during outages
• Makes off-grid operation feasible with modest solar panels
• Reduces the load on an electricity system that has other demands
• Makes the network more resilient to any power disruption

5.2 Power budgets

Configuration	Approximate Power Draw	Notes
Raspberry Pi file server + SSD	5–10W	Serves 5–15 simultaneous users adequately for file access
Desktop PC file server	30–80W	Serves 50+ simultaneous users; higher power but more capable
Consumer Wi-Fi router (mesh node)	5–12W	One building or small area coverage
Enterprise PoE switch (24-port)	30–60W (without PoE loads)	Central switch for building network
Outdoor directional wireless link (per end)	8–15W	Point-to-point bridge between buildings
Total: minimal community network (Pi server + 3 mesh nodes)	20–45W	Covers a small town centre
Total: full community network (desktop server + switch + 5 access points + 2 wireless bridges)	100–200W	Covers a town with multiple buildings

A minimal community network drawing 20–45W can be powered by a 200–400W solar panel array with a 100–200Ah battery bank (12V), providing 24-hour operation under normal NZ conditions. The lower end of the range assumes North Island summer (4–5 peak sun hours); the upper end assumes South Island winter (1.5–2.5 peak sun hours in Southland/Otago in June–July). Under nuclear winter conditions, solar irradiance may be reduced 20–70%, potentially requiring panel capacity 2–3 times larger or acceptance of reduced operating hours.²⁰

5.3 Power management strategies

Scheduled operation: Not all network equipment needs to run 24/7. A community file server might operate during “library hours” (e.g., 0800–2000) and shut down overnight to conserve power. A timer or simple script handles this automatically. Critical content that might be needed at any hour (medical references for emergency use) can be kept on a separate always-on low-power device (Raspberry Pi).

Wake-on-LAN: Many computers support Wake-on-LAN (WoL) — a feature where the computer powers on automatically when it receives a specific network signal. A server in standby draws less than 5W but can be woken remotely when a user needs it. The network switch stays on; the server sleeps until needed.

Selective activation: In a mesh network, not all nodes need to operate simultaneously. Core nodes (connecting key buildings) run continuously; peripheral nodes activate during working hours or on demand.

UPS and battery integration: Even where grid power is available, UPS units protect equipment from power fluctuations and brief outages. The UPS batteries degrade over time (3–5 years for sealed lead-acid), but replacement batteries can be produced from recycled lead (sourced from NZ’s existing battery recycling infrastructure and vehicle battery stocks) and locally produced sulfuric acid (Doc #35, Doc #113). The dependency chain for replacement batteries is: lead recovery (smelting from scrap batteries at ~330 degrees C) -> grid or plate casting -> sulfuric acid production (requiring sulfur or pyrite, which NZ has limited domestic sources of — see Doc #113) -> electrolyte filling -> formation charging. This is a [B]-feasibility process that requires the prerequisite acid production capability. The UPS electronics — inverter, charger, control circuit — last much longer (10–15 years) and are worth preserving; they contain MOSFETs and control ICs that cannot be locally manufactured.

---

6. REPURPOSING CONSUMER NETWORKING EQUIPMENT

6.1 Consumer routers

NZ has approximately 1.8–2.0 million ISP-provided routers in homes.²¹ Most are combined devices offering Wi-Fi, a 4-port Ethernet switch, and a WAN port (for the ISP connection). When the ISP connection ceases to function, the device is still a fully functional Wi-Fi access point and Ethernet switch.

Reconfiguration: Many consumer routers can be reconfigured to operate as access points (disable the router/NAT function, use the LAN ports only). This is a settings change, not a hardware modification. Most routers support this through their web-based administration interface.

Alternative firmware: Many consumer routers can be reflashed with OpenWrt — an open-source Linux-based router firmware that provides far more flexibility than the manufacturer’s firmware, including mesh networking capability (batman-adv), advanced routing, DHCP, DNS, VPN, and firewall functions.²² OpenWrt runs on hundreds of router models from TP-Link, Netgear, Linksys, Asus, and others. A router running OpenWrt can be configured as a mesh node, an access point, a repeater, a network bridge, or a lightweight server.

Caution on ISP-locked devices: Some ISP-provided routers (particularly those from Spark and One NZ) have locked firmware that prevents reconfiguration or reflashing. These may still function as basic access points but cannot be repurposed for mesh networking without firmware replacement, which may not be possible on all models. The skills census should identify which router models are deployed in each community and which support alternative firmware.

6.2 Enterprise equipment

Businesses, schools, and government offices use enterprise networking equipment — managed switches, commercial access points, rack-mounted servers — that is typically higher-quality and more configurable than consumer equipment. As organisations downsize or relocate under recovery conditions, this equipment becomes available for community use.

Priority recovery targets:

• Managed switches (Cisco, HP/Aruba, Juniper) — highly configurable, long-lived, support PoE and VLAN segmentation
• Enterprise access points (Ubiquiti UniFi, Cisco Meraki, Aruba, Ruckus) — designed for dense deployment, PoE-powered, weather-resistant outdoor models available
• Rack-mounted servers (Dell PowerEdge, HP ProLiant, Lenovo ThinkSystem) — powerful, redundant components, designed for continuous operation. Higher power draw but enormous capability.
• UPS units — critical for power resilience. Enterprise UPS units are larger and longer-lasting than consumer models.

The Cisco/cloud dependency problem: Some modern enterprise equipment (particularly Cisco Meraki and some Ubiquiti cloud-managed products) depends on cloud management platforms hosted internationally.²³ When international connectivity is lost, these devices may lose management capability, refuse to pass traffic, or enter a degraded mode. Identifying and reconfiguring cloud-dependent equipment to operate in standalone mode is an early-phase IT task. Most enterprise equipment supports standalone operation, but it may require local configuration that was previously handled by the cloud platform.

6.3 Networking equipment NZ has in unusual quantity

NZ’s UFB programme and extensive rural wireless deployment mean NZ has disproportionate stocks of certain networking equipment:

• ONTs (fibre modems): Approximately 1.2–1.5 million deployed.²⁴ These are useful primarily for their power supplies and electronic components (for salvage), not for local networking per se, since their primary function (connecting to the ISP’s OLT) ceases when the OLT fails.
• Outdoor wireless equipment: Thousands of point-to-point and point-to-multipoint wireless devices deployed by WISPs and the RCG programme.²⁵ These are exactly the equipment needed for inter-building and inter-town wireless links.
• PoE injectors and splitters: Deployed wherever PoE equipment is used without a PoE switch. Useful for powering remote access points from a central location.

---

7. SECURITY CONSIDERATIONS

7.1 The changed threat landscape

Under isolation, the cybersecurity threat landscape changes dramatically. External threats (state-sponsored attacks, international criminal groups, botnet traffic) largely disappear as international connectivity ceases. The remaining threats are:

• Insider threats: Disgruntled individuals or groups with network access who may attempt to disrupt services, alter data, or access restricted information
• Malware already present: Devices infected with malware before the event continue to harbour it. Without antivirus updates, existing infections may persist or spread on local networks
• Physical theft or sabotage: Network equipment, especially in unattended locations, may be stolen or damaged
• Data integrity: Ensuring that reference content on community file servers has not been tampered with — corrupted medical references could be dangerous

7.2 Pragmatic security measures

Full cybersecurity under isolation is neither possible nor necessary. The approach should be pragmatic:

• Physical security for servers: Locked rooms or cabinets. Servers in community libraries should be in a restricted area, not publicly accessible.
• Read-only content partitions: Reference content (Wikipedia, medical references, Recovery Library) should be stored on read-only partitions or served from read-only media. Users can read but not modify. This prevents both accidental and malicious corruption.
• Separate write areas: Community-generated content (wiki, local records) is stored separately and backed up regularly to offline media (USB drives kept in a different physical location).
• Basic access control: Administrative access to servers and network equipment should require passwords. General read access to reference content can be open — the goal is knowledge sharing, not restriction.
• Network segmentation: Where possible, separate administrative traffic (server management, network configuration) from user traffic using VLANs. This prevents a compromised user device from accessing server administration.
• Regular offline backups: The most important security measure. A USB drive containing a copy of all critical content, stored offline and updated weekly, protects against any digital threat — malware, hardware failure, or data corruption.

---

8. TRAINING AND WORKFORCE

8.1 Skills required

Community network deployment and maintenance requires skills at several levels:

Level 1 — Community network administrator (moderate training required):

• Basic Linux system administration (starting and stopping services, checking logs, updating content)
• Basic network troubleshooting (checking cables, restarting equipment, verifying connectivity)
• File server content management (adding and organising files, running backups)
• User support (helping community members connect and find information)

Training time: 2–6 weeks of focused instruction depending on the trainee’s starting competence (2 weeks for someone with existing IT experience; 4–6 weeks for someone with basic computer literacy but no system administration background). This role can be filled by librarians, teachers, or technically inclined community members with appropriate training.

Level 2 — Network engineer (existing IT skills):

• Network design and configuration (IP addressing, routing, DHCP, DNS, VLANs)
• Wireless network planning and deployment (site surveys, antenna placement, channel selection)
• Server administration (operating system installation, service configuration, security)
• Hardware troubleshooting and repair (component-level diagnosis, soldering, power supply repair)

NZ has thousands of people with these skills — network engineers, system administrators, IT support technicians. The task is retaining them in IT roles rather than losing them to other essential services, and distributing them geographically (NZ’s IT workforce is concentrated in Auckland, Wellington, and Christchurch).

Level 3 — Electronics repair (specialist):

• Component-level repair of networking equipment (capacitor replacement, power supply repair, solder rework)
• Firmware recovery and flashing
• Cable fabrication (Ethernet cable termination with RJ45 connectors — the basic technique can be demonstrated in an hour, but producing reliable terminations consistently requires practice; poorly crimped connectors are a common source of intermittent network faults)

Electronics repair extends equipment life significantly. A router with a failed electrolytic capacitor is a 10–30 minute repair for someone with soldering experience, a soldering iron, and a replacement capacitor of matching specification (salvaged from another failed device). The repair requires identifying the failed component (typically bulging or leaking capacitors), desoldering it, and soldering a replacement — skills that require practice to execute reliably on densely packed circuit boards. Without this capability, the entire router is discarded. Doc #130 (Device Life Extension) covers this in detail.

8.2 Training delivery

Training for community network administrators should be integrated into the broader trade training framework (Doc #157). Specific delivery mechanisms:

• Regional IT training centres: At polytechnics or community colleges, offering 2–4 week intensive courses for community network administrators
• Printed training manuals: Step-by-step guides for common tasks (server setup, content loading, network troubleshooting). These should be produced as part of the printing programme (Doc #5) and distributed to all deployment sites.
• Peer training: Once the first community networks are operational, experienced administrators train new ones. This scales the workforce without centralised training capacity.
• Online training (while the intranet functions): Video and text-based training materials hosted on the domestic intranet for self-paced learning.

---

9. COMMUNITY DEPLOYMENT AND LOCAL CONTENT

9.1 Community deployment sites

Community file servers should be deployed at existing gathering points where people already come for information and services. Suitable venues include:

• Schools — the most widely distributed public buildings in NZ, present in nearly every community. Schools already function as information hubs, civil defence assembly points, and community meeting places.
• Community halls and rural halls — common in small towns and rural areas where no other public building exists.
• Libraries — where they survive as staffed facilities, they are natural knowledge-access points with existing information-management capability.
• Marae — important community centres in rural and predominantly Māori areas. Deployment at marae should be led by iwi and hapū, with government providing equipment and support. This mirrors the approach recommended for HF radio in Doc #128 and the skills census in Doc #8.
• Churches and church halls — widely distributed, particularly in Pacific and rural communities.
• Sports clubs and RSAs — in some small towns, the rugby club or RSA is the primary community gathering point.

The deployment model is the same across all venues: government provides equipment, training, and ongoing support; the host community decides where and how to deploy. Site selection should prioritise geographic coverage — every community of 500+ people should have at least one access point within walking distance.

9.2 Content localisation

Community file servers should carry the full Recovery Library content set plus locally relevant materials. This includes te reo Māori dictionaries and learning resources where available, local agricultural observations, and any regionally specific technical content. The digital platform is well suited to preserving and distributing materials in multiple languages — a practical access function that complements the printed library.

9.3 Local knowledge capture

Community networks are not only repositories for pre-existing reference material — they are platforms for capturing and sharing local knowledge. Communities can document:

• Local agricultural observations (what grows, what does not, under changed climate conditions)
• Repair techniques developed for local equipment
• Traditional practices relevant to local conditions
• Resource inventories and condition reports
• Community governance decisions and meeting records

This locally generated knowledge, aggregated across communities and shared through content synchronisation (Section 4.3), becomes a national knowledge asset — a bottom-up complement to the top-down Recovery Library.

---

10. CRITICAL UNCERTAINTIES

Uncertainty	Why It Matters	How to Resolve	Impact if Adverse
Actual networking equipment inventory in NZ	Determines available equipment pool and spare parts	National asset census (Doc #8); IT industry survey	If equipment stocks are lower than estimated, deployment scope reduces
Hard drive lifespan under NZ conditions	Determines data preservation timeline	Track failure rates across deployed servers; maintain multiple copies	If drives fail faster than expected, more aggressive backup and replication needed
Fibre backbone survival timeline	Determines whether regional interconnection is possible	Dependent on Doc #127 maintenance actions	If backbone fails early, communities operate as isolated intranets; sneakernet becomes primary distribution
Grid power reliability at deployment sites	Determines need for off-grid power design	Monitor grid status; deploy solar backup at vulnerable sites	If power is intermittent, low-power designs (Raspberry Pi) become essential
IT workforce retention	Determines whether enough skilled people are available for deployment and maintenance	Designate IT as essential service; retain workforce	If IT workers are reassigned to other priorities, deployment pace slows and maintenance degrades
Nuclear winter solar irradiance reduction	Affects viability of solar-powered off-grid nodes	Measure actual irradiance post-event	If reduction exceeds 50%, solar-powered nodes need larger panels or alternative power
Cloud-dependent equipment behaviour	Some enterprise equipment may cease functioning without cloud management	Test and reconfigure cloud-managed devices early	If devices cannot be reconfigured, they become unusable — replace with standalone-capable equipment
Content availability at time of event	Determines initial content on community servers	Begin mirroring immediately; cannot be retrospectively fixed	If international connectivity is lost before mirroring is complete, content gaps are permanent

---

Cross-References

• Doc #127 — NZ Telecommunications Maintenance — Network architecture described here depends on the surviving wide-area telecom backbone: regional intranet interconnection is only viable as long as Doc #127’s maintenance programme keeps inter-city fibre and exchange equipment operational. Degradation timeline from Doc #127 determines the window in which community networks can remain regionally connected before contracting to standalone local operation.

• Doc #128 — HF Radio Network — HF radio and local networks are complementary, not competing: local networks provide high-bandwidth data access within a community; HF radio provides low-bandwidth long-distance communication between communities. Communities that have lost electronic backbone links to the regional intranet fall back on HF for inter-community coordination. Deployment planning should treat both as parts of a layered communications stack.

• Doc #129 — AI Inference Facility Operations — Community file servers are the local distribution endpoint for AI-generated content produced at central inference facilities. If NZ maintains AI inference capacity (Doc #129), outputs — synthesised agricultural guidance, medical decision support, translated materials — are packaged and pushed to community servers via the content synchronisation process described in Section 4.3.

• Doc #130 — Device Life Extension — Local network operation depends entirely on continuing availability of networking hardware: routers, switches, access points, and servers. Doc #130 provides the component-level repair and maintenance practices that extend equipment lifespan beyond the manufacturer’s expected service life. Without the capacitor replacement, fan servicing, and power supply repair techniques in Doc #130, network equipment stocks deplete on the timelines in Section 1.2 with no prospect of replacement.

• Doc #131 — Radio Equipment Fabrication — When commercial directional wireless equipment (Section 3.3) eventually fails and no replacements are available, Doc #131 provides pathways to fabricating basic radio links from locally sourced components. Fabricated wireless bridges cannot match commercial equipment performance, but they can maintain inter-building and inter-town connectivity after the commercial equipment pool is exhausted.

• Doc #132 — Digital-to-Print Priority Schedule — Determines which content held on community file servers should be committed to print as a durable fallback if digital infrastructure fails. The content prioritisation framework in Doc #132 directly informs which collections community file servers should stock and which are print-only candidates. Community servers depend on early content mirroring actions described in both documents.

• Doc #134 — Computing Roadmap — Sets the long-term trajectory for NZ’s computing self-sufficiency, of which local network architecture is one layer. Networking equipment cannot be manufactured domestically within any near-term horizon (Section 1.3); Doc #134 establishes the timeline and preconditions under which that constraint might eventually be relaxed. Network design decisions made now should be compatible with the computing hardware trajectory Doc #134 describes.

• Doc #135 — Computer Construction — File servers and network nodes depend on available computing hardware. Doc #135 addresses the long-term construction of basic computing devices from locally available or manufacturable components. As commercial computing hardware ages out, servers built or repaired using Doc #135 methods may become the primary computing substrate for community network nodes.

---

12. WHAT THIS DOCUMENT DOES NOT COVER

• Wide-area telecommunications maintenance — Covered in Doc #127. This document addresses local networks, not the inter-city backbone.
• HF and radio communication — Covered in Doc #128 and Doc #131. Radio provides long-distance communication; local networks provide local data access. They are complementary, not competing.
• Device repair and life extension — Covered in Doc #130. This document assumes devices exist and function; Doc #130 addresses keeping them functional.
• Data centre operations — NZ’s major data centres (in Auckland, Hamilton, Wellington, Christchurch) are large-scale infrastructure with their own operational requirements. This document addresses community-scale deployments.
• Cybersecurity in depth — Section 7 covers pragmatic measures. A comprehensive cybersecurity assessment for NZ’s domestic intranet would be a separate document.
• Software development — NZ’s software industry may develop locally hosted alternatives to international services (email, collaboration tools, databases). This is a software rather than network architecture question.

---

---

1. NZ Internet Exchange (NZIX) operates peering exchanges in Auckland and Wellington where NZ internet service providers exchange domestic traffic directly. See https://www.nzix.net/. NZIX is operated by the Internet New Zealand Association. The peering exchanges enable NZ ISPs to route domestic traffic within NZ without sending it through international links — this is the infrastructure that makes a “domestic intranet” possible.↩︎

2. NZ IT sector employment: Statistics NZ reports the broader Information Media and Telecommunications sector (ANZSIC Division J) at approximately 40,000–50,000 employees. The Information Technology and Services subsector (including IT consulting, software, hardware support, and managed services) adds significantly to this. The figure of 100,000–120,000 for the broader IT-related workforce is an estimate that includes software developers, system administrators, network engineers, IT support, and related roles across all industries. Exact figures require verification from Statistics NZ Business Demography data.↩︎

3. NZ broadband connection numbers: Commerce Commission Annual Telecommunications Monitoring Report. As of recent reports, NZ has approximately 1.8–2.0 million broadband connections. See https://comcom.govt.nz/regulated-industries/telecommunica...↩︎

4. NZ school numbers: Ministry of Education. NZ has approximately 2,500 schools (primary, intermediate, and secondary). Most have IT infrastructure including computer labs, local networks, and internet access. See https://www.education.govt.nz/.↩︎

5. Ultra-Fast Broadband (UFB) programme: Covered in detail in Doc #127 and footnotes therein. Approximately 87% of NZ premises passed by fibre, with approximately 1.2–1.5 million active fibre connections.↩︎

6. Wikipedia offline size: The Kiwix project (https://www.kiwix.org/) provides compressed offline copies of Wikipedia. The full English Wikipedia with images is approximately 90–100 GB uncompressed; a text-only version is approximately 20–22 GB. These figures are approximate and grow over time as Wikipedia expands.↩︎

7. NZ business computing device estimate: Based on approximately 530,000 businesses registered in NZ (Stats NZ Business Demography Statistics) and an estimated 1.5–2 million office workers with access to desktop or laptop computers. Schools add approximately 400,000–500,000 devices (Ministry of Education digital technology figures). Government agencies operate additional devices. The 2–3 million figure is an estimate; the actual inventory would be established by the national asset census (Doc #8).↩︎

8. Desktop computer power consumption varies widely by hardware. Modern low-power desktop PCs (particularly those designed for office use, such as Intel NUC or small-form-factor business desktops) draw 15–40W at idle and 30–65W under load. Older or more powerful desktops draw 50–120W. A file server workload (mostly disk reads, modest CPU usage) falls toward the lower end of each range.↩︎

9. Raspberry Pi power consumption: The Raspberry Pi 4 Model B draws approximately 3–6W under varying load conditions; the Raspberry Pi 5 draws approximately 5–12W. With an attached USB SSD, add 2–5W. Based on Raspberry Pi Foundation published specifications and independent testing.↩︎

10. Linux adoption in NZ: NZ has an active Linux user community and significant professional Linux deployment. Many NZ web servers, cloud services, and institutional systems run Linux. The NZ Open Source Society (NZOSS) promotes open source adoption. NZ government has used Linux and open-source software in various contexts.↩︎

11. Kiwix project: https://www.kiwix.org/. Kiwix provides offline access to web content including Wikipedia, Project Gutenberg, TED talks, and other educational resources. Content is distributed in the ZIM file format. Kiwix readers are available for Linux, Windows, macOS, Android, and iOS.↩︎

12. NZ public library sites: Public Libraries of New Zealand (PLNZ). NZ has approximately 300 public library service points (including main libraries and branches) operated by territorial authorities. See https://natlib.govt.nz/librarians/nz-libraries.↩︎

13. NZ has 8 universities (Auckland, Waikato, Massey, Victoria University of Wellington, Canterbury, Lincoln, Otago, and Auckland University of Technology). The former 16 polytechnics and institutes of technology were merged into Te Pukenga - New Zealand Institute of Skills and Technology in 2020, but Te Pukenga was disestablished in 2024 with its subsidiary entities reverting to independent institutions. The physical campuses and IT infrastructure at these approximately 16 sites remain regardless of governance structure. See Tertiary Education Commission, https://www.tec.govt.nz/.↩︎

14. Directional Wi-Fi equipment range: Ubiquiti Networks’ airMAX product line is widely deployed in NZ for point-to-point links. Manufacturer specifications claim ranges of 1–50+ km depending on model, antenna gain, and conditions. Practical reliable range in NZ conditions (factoring in weather, vegetation, and alignment) is more conservatively 1–15 km for typical installations. Similar products from MikroTik and Cambium Networks are also deployed in NZ.↩︎

15. Rural wireless internet service provision in NZ: Multiple WISPs operate across rural NZ, including Lightwire, Velocity Networks, Primo Wireless, and others. The Rural Broadband Initiative (RBI) and Rural Connectivity Group (RCG) have deployed fixed wireless infrastructure extensively. The total number of deployed point-to-point and point-to-multipoint wireless devices in NZ is not publicly documented but likely numbers in the thousands to tens of thousands.↩︎

16. OpenWrt: https://openwrt.org/. An open-source Linux distribution for networking equipment. Supports hundreds of router and access point models. Includes mesh networking support via batman-adv (Better Approach To Mobile Ad-hoc Networking — advanced) protocol. Device compatibility is documented in the OpenWrt Table of Hardware.↩︎

17. Outdoor wireless equipment power consumption: Based on manufacturer specifications for typical devices. Ubiquiti NanoStation M5 (outdoor directional): approximately 8W. Ubiquiti Rocket M5 (higher power): approximately 12W. MikroTik SXTsq 5 ac: approximately 11W. Consumer routers running OpenWrt: typically 5–12W depending on model.↩︎

18. Long-range point-to-point wireless: With high-gain directional antennas (parabolic dishes or panel antennas), point-to-point wireless links can span 30–100+ km with clear line of sight. Equipment designed for this purpose (Ubiquiti airFiber, Cambium PTP series, MikroTik high-gain products) is deployed in NZ by WISPs and telecommunications companies. Achievable bandwidth at long range varies from 50 Mbps to 1+ Gbps depending on equipment, frequency, and conditions. For community interconnection, even 10 Mbps is more than adequate.↩︎

19. rsync: A standard Unix/Linux utility for efficient file synchronisation. Transfers only the differences between source and destination, minimising bandwidth and time. Well-established, open-source, and available on all Linux distributions.↩︎

20. Solar irradiance in NZ: NIWA climate data. NZ receives approximately 3–5 peak sun hours per day averaged annually, with the South Island winter being the lowest period (approximately 1.5–2.5 peak sun hours in Southland/Otago in June–July). Nuclear winter solar reduction estimates of 20–70% are from Robock, A. et al. (2007), “Nuclear winter revisited with a modern climate model,” Journal of Geophysical Research, 112, D13107. At the pessimistic end (70% reduction), South Island winter solar irradiance could drop below 1 peak sun hour per day, making solar-only operation of even low-power equipment challenging without substantial battery storage.↩︎

21. NZ broadband connection numbers: Commerce Commission Annual Telecommunications Monitoring Report. As of recent reports, NZ has approximately 1.8–2.0 million broadband connections. See https://comcom.govt.nz/regulated-industries/telecommunica...↩︎

22. OpenWrt: https://openwrt.org/. An open-source Linux distribution for networking equipment. Supports hundreds of router and access point models. Includes mesh networking support via batman-adv (Better Approach To Mobile Ad-hoc Networking — advanced) protocol. Device compatibility is documented in the OpenWrt Table of Hardware.↩︎

23. Cisco Meraki devices require periodic communication with the Meraki cloud dashboard (hosted on AWS infrastructure, primarily in the US) to maintain their license and full functionality. Devices that cannot reach the dashboard for an extended period (typically 30 days, configurable) may enter a degraded mode with limited management capability. Ubiquiti UniFi devices can operate in standalone mode but lose cloud management features (remote access, firmware updates, site statistics) when the UniFi cloud service is unreachable. See Cisco Meraki documentation: https://documentation.meraki.com/ and Ubiquiti community forums for offline operation guidance.↩︎

24. Ultra-Fast Broadband (UFB) programme: Covered in detail in Doc #127 and footnotes therein. Approximately 87% of NZ premises passed by fibre, with approximately 1.2–1.5 million active fibre connections.↩︎

25. Rural wireless internet service provision in NZ: Multiple WISPs operate across rural NZ, including Lightwire, Velocity Networks, Primo Wireless, and others. The Rural Broadband Initiative (RBI) and Rural Connectivity Group (RCG) have deployed fixed wireless infrastructure extensively. The total number of deployed point-to-point and point-to-multipoint wireless devices in NZ is not publicly documented but likely numbers in the thousands to tens of thousands.↩︎