Fibre (FTTH) & utility network rollout planning and design automation

Planning a fibre-to-the-home network street by street is slow, expert-heavy manual CAD work, yet civil works dominate the cost. Design automation formulates the layout as a constrained network-design problem (Steiner-tree/MILP and heuristics) over GIS, cadastre and address data, uses computer vision to classify surfaces and obstacles, and outputs routes, equipment placement, bills of materials and construction packets. The same approach works for district heating, water and power distribution.

Problem & value

• Today: planners trace routes by hand in GIS/CAD tools, estimate trench lengths and surface types from maps and site visits, and iterate slowly when permits, ducts or costs change. Late changes ripple into procurement and construction.
• Why it matters: civil works (digging, surface restoration) are the dominant share of FTTH capex, so small layout improvements, more duct and pole reuse and less open trenching translate directly into money and time. The EU Gigabit Infrastructure Act (Regulation (EU) 2024/1309) pushes cost reduction through access to existing physical infrastructure and faster permitting, which rewards planners who can evaluate reuse options systematically [1].
• AI value: many alternative designs in hours instead of weeks, reproducible cost estimates, rapid what-if on permits, subsidies (Gigabitförderung) and take-up, and consistent output for tendering.
• Evidence: Deutsche Telekom has publicly worked with IQGeo's Comsof Fiber design software for automated rollout planning [3]. Concrete savings figures are vendor- and project-specific; measure on your own pilot areas.

Variants

• Telco FTTH/FTTB rollout: greenfield or brownfield, point-to-multipoint (GPON/XGS-PON) with splitter placement, or point-to-point.
• Stadtwerke multi-utility: joint trenching of fibre with electricity, district heating (see OPT-023) or water; duct reuse in the power network.
• Municipal/public sector: subsidy-area planning (Gigabit funding), white-spot analysis, open-access network.
• Engineering firms and general contractors: design-and-build quotes and construction packets at scale.
• Mobile backhaul and 5G small cells: fibre feeds, linked to OPT-030.

How it works

1. GIS + cadastre + address data + existing infrastructure inventory + imagery (mobile mapping, aerial)
2. CV: surface/obstacle classes, pole and duct detection
3. cost graph: candidate trench/duct edges with unit costs and constraints
4. optimisation: Steiner-tree / MILP + heuristics (placement of cabinets, DPs, splitters)
5. design rule checks (loss budget, capacity, standards) and scenario comparison
6. human planner review/adjustment on map
7. BoM, cost estimate, construction packets, permit documents
8. ERP/work management

• Optimisation core: classical operations research, not an LLM. Candidate edges are derived from road and parcel geometry; cost per metre depends on surface class (asphalt, paving, soft ground), reuse of existing ducts or poles is a near-zero-cost edge, and the solver minimises total cost subject to coverage and capacity. Large areas are partitioned into clusters and solved with decomposition and heuristics.
• Computer vision: segmentation of surfaces and detection of poles, manholes or obstacles on imagery and point clouds to fill cost attributes where records are missing.
• ML forecasting: take-up/penetration and cost-per-home models can feed the objective.
• LLM role (supporting): extracting rules from design standards and permit documents, drafting construction documentation, natural-language scenario queries (see OPT-018).
• Human-in-the-loop: experienced planners review generated designs, handle exceptions (private land, protected areas, crossings) and approve release to construction.

Data preparation

Network design is only as good as the GIS foundation. Data typically lives in GIS databases (parcels from ALKIS, buildings, addresses), the asset inventory (ducts, poles, manholes, spare capacity), CAD drawings, PDF as-built plans, cost tables in Excel and, increasingly, mobile-mapping imagery and point clouds. Paper and scanned plans remain common for older infrastructure.

Typical gaps: inventory that does not match reality, duct capacity not recorded, ducts without geometry, different coordinate systems, outdated address points, missing surface classes and unit costs held in individual planners' heads.

Preparation steps: 1. Inventory layers and gaps (PREP-001, PREP-002) and agree on owners per layer (PREP-004). 2. Digitise and georeference scanned plans (PREP-006, DOC-014) and convert CAD formats (PREP-007). 3. Harmonise coordinate systems, clean topology and reconcile addresses to buildings. 4. Capture surface classes via imagery classification and validate samples in the field. 5. Tidy cost tables and design rules into machine-readable form (PREP-011, PREP-012).

Tools: QGIS, PostGIS, FME or GDAL, an OCR pipeline and the planning suite's import tools. Expect more than half of the effort in inventory cleaning, which dominates cost.

Implementation paths

Which path for whom

• enterprise (A): mature fibre design suites with ALKIS import and rule sets exist, and a single operator rarely recoups custom solver work.
• developer (B): engineering firms and tool builders can combine cloud APIs for imagery analysis and LLM documentation with an own solver on the customer's GIS data.
• public (C): municipal utilities and public bodies benefit from open-source GIS and solver components (QGIS, PostGIS, pgRouting, OR-Tools) on sovereign infrastructure, which also eases procurement rules and keeps the data in-house.

Path A — Buy (recommended)

• Fibre design suites: IQGeo Comsof Fiber (automated FTTH design), Esri ArcGIS with Utility Network and fibre extensions, Hexagon, Bentley and other planning suites, Smallworld-based inventory (GE Vernova), and Geomatics/EU specialist vendors for German planning (e.g. FTTH planning tools from smaller DACH vendors). Check EU hosting, ALKIS import, German duct inventory formats (e.g. via the Infrastrukturatlas) and export to construction tools.
• Choose A when: you need a proven rule set, support and integration into inventory and work management; custom solver work rarely pays off for a single operator.

Path B — Build on cloud APIs

• Geo data and compute: OpenStreetMap plus national cadastre/open data, PostGIS/pgRouting, Esri or cloud GIS in EU regions; Google OR-Tools or commercial solvers (Gurobi, FICO Xpress, CPLEX, HiGHS) as services.
• Vision: cloud segmentation APIs or SAM-family models on imagery for surface classification.
• Orchestration: workflow engines to pass designs to inventory and ERP.
• Choose B when: you are an engineering firm needing custom rules and tendering outputs.

Path C — Self-host (open source)

• Stack: PostGIS, pgRouting, QGIS, OSMnx/NetworkX, OR-Tools, HiGHS, SCIP, Pyomo; segmentation with SAM 2 or YOLO-family detectors; point-cloud processing with PDAL/Open3D.
• Hardware: HW2 is enough for vision inference; the solver mostly needs CPU and RAM. Effort is significant: encoding design rules and duct inventory logic is the hard part.

Path D — Custom training

Train segmentation models on your own mobile-mapping imagery (surface classes, obstacles) when generic models mislabel local conditions; learn cost and take-up models from completed projects. Needs a few hundred to a few thousand labelled images or completed-build records with actual costs.

State of the art (2026)

• Design automation is established in commercial tools; the frontier is tighter integration of duct/pole reuse, as-built feedback and 3D/point-cloud imagery to cut survey effort.
• Hybrid methods (exact MILP for local subproblems, heuristics for city scale) dominate; learning-based methods (GNN-guided heuristics) are research-stage [4].
• Foundation models for imagery (SAM-family, open-vocabulary detectors) reduce labelling effort for surface classification.
• Limits: results are only as good as the infrastructure inventory; missing or wrong duct records are the main failure cause. Unit costs vary regionally, permits and landowner rights cannot be fully modelled, and generated designs still need field validation.

Shared resources & combinations

• Same solver stack: OPT-008 (network design), OPT-001 (routing), OPT-018 (LLM-to-solver copilot).
• Geospatial/vision building blocks: DATA-011 (geospatial analytics), remote-sensing models, mobile-mapping segmentation shared with infrastructure inspection use cases.
• Downstream: OPT-027 (construction schedule optimisation), OPT-019 (field service dispatch), OPT-030 (RAN optimisation on the built network).
• Multi-utility: OPT-022 and OPT-023 for joint trenching with grid and heating networks.

Effort, cost & KPIs

• Path A: weeks to a few months for data onboarding and rule configuration; licence per user or per home passed, plus GIS data preparation.
• Path B/C: 6–12+ months for a production-grade design engine; data cleaning of inventory dominates cost.
• Path D: adds labelling and model validation effort.
• KPIs: cost per home passed, trench metres per home, share of duct/pole reuse, design lead time per area, deviation between planned and as-built cost/length, rework rate in construction, planner hours per 1,000 homes.

People & change

Planning, construction and network-operations teams must agree on rules before automation starts. Involve management for budget and the rollout strategy, the head of network planning as process owner, the owners of GIS and inventory data, IT, and legal for permits and cadastre licence terms. Suppliers such as civil contractors and the planning-tool vendor join when construction packets and data exchange formats are defined. Pilot on one area and let planners compare the automated design against their own; planners approve every design and can edit routes.

Works council: no for the core planning tool as long as it processes geodata and costs only, since it does not monitor staff. It can become relevant if work logs, planner productivity or field-crew tracking are recorded (section 87(1) no. 6 BetrVG); inform the works council in good time anyway under section 90(1) no. 3 where work processes change. Public bodies: inform the staff council.

Data protection: building and address data can be personal data; involve the DPO, sign an AVV with cloud or imagery providers, and watch for faces or number plates in mobile-mapping images (blurring). A DPIA is likely only for large-scale imagery.

AI literacy: support planners with training on checking solver output and its assumptions (GUIDE-006). Typical concern: loss of craft expertise; frame the tool as a first-draft generator (GUIDE-008). See GUIDE-009 for the pilot and GUIDE-005 for data protection.

Risks, regulation & compliance

• EU AI Act: typically minimal risk. Network design is not itself an Annex III use case; however, if AI components act as safety components in the management or operation of critical digital infrastructure or utility supply (Annex III point 2), classification may change, so check operational scope. Planning-only tools are normally outside it. AI literacy (Art. 4) applies.
• GDPR: address and building data can identify residents; imagery may capture persons and number plates, so blur or filter them, minimise retention and keep a processing agreement with data vendors.
• Sector rules: Gigabit Infrastructure Act (EU) 2024/1309, German TKG and DigiNetzG successor provisions for duct access and information duties, critical-infrastructure/NIS2 security obligations for operators, and Wegerechte and permit procedures [1].
• Risks: wrong inventory data leading to unbuildable designs, over-reliance on automated costs in tenders, vendor lock-in on proprietary design formats.
• Mitigations: field verification samples, version-controlled rule sets, export in open formats, planner sign-off.

Getting started

1. Pick a pilot area (a few thousand homes) with an already built reference design to benchmark against.
2. Audit data quality: address points, cadastre, duct/pole inventory, surface information.
3. Define cost tables and design rules together with senior planners.
4. Run 2–3 tools (Path A) or a PostGIS/OR-Tools prototype on the pilot and compare cost, length and effort.
5. Feed construction as-built data back to calibrate costs and rules.

Sources

1. Regulation (EU) 2024/1309 (Gigabit Infrastructure Act) — https://eur-lex.europa.eu/eli/reg/2024/1309/oj
2. Fraunhofer IPM — https://www.ipm.fraunhofer.de
3. IQGeo — Comsof Fiber — https://www.iqgeo.com/products/comsof-fiber
4. Google OR-Tools documentation — https://developers.google.com/optimization
5. pgRouting project — https://pgrouting.org
6. HiGHS solver — https://highs.dev
7. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
8. Segment Anything 2 (Meta) — https://github.com/facebookresearch/sam2