A service-area boundary can look settled while the business case still counts apartment buildings as individual customers. That mismatch reaches the design team as a capacity problem, even though it began in the address file. We start planning by asking what the owner intends to serve and whether the records support that commitment.
The work before design gives the project an agreed basis for investment. We connect demand assumptions to a feasible build sequence, with enough detail to expose decisions that need field verification. This guide covers that planning work; our explanation of what FTTH design includes follows the project into engineering.
Set the FTTH network planning basis
FTTH network planning establishes the service footprint and investment assumptions that guide a fiber-to-the-home build before engineering develops the network. We separate 2 quantities from the start: premises the owner intends to make serviceable and subscribers expected to connect. That distinction anchors demand forecasting without shrinking coverage to the initial sales forecast.
Define coverage and the launch goal
Start with a mapped boundary that the owner can approve. Include excluded pockets explicitly, especially where a road divides the commercial target from the area the network must traverse. We want a designer to understand whether an isolated group of homes is outside scope or merely absent from the source data. A blank space cannot explain that difference.
The goal also needs an operational definition. An owner may prioritize getting an initial service area ready for sale while another must reach every eligible premises in a defined footprint. Those goals produce different phase boundaries. We record which commitment governs when the shortest route conflicts with complete coverage, rather than leaving a designer to resolve a commercial decision through routing.
Write down the service expectations before selecting an architecture. Residential service and dedicated business connections may share corridors without sharing the same capacity assumptions. An existing network may impose a particular handoff location or operating standard. We capture those constraints at planning level and leave equipment selection and detailed performance calculations to engineering, where they can be checked against the actual network.
Reconcile addresses with serviceable premises
An address point identifies a location in a dataset; it does not automatically establish the number of service opportunities there. A multi-dwelling building may have a common street address and separate units that need individual service. Conversely, duplicate address records can represent the same occupied premises. We keep the source identifier attached while resolving these differences so the count remains auditable.
Use a premises register that distinguishes buildings from units and records whether access is confirmed. New development needs its own treatment: planned lots should remain distinguishable from occupied properties. The planning count should show what is included in the initial build and what is held for later expansion, with unresolved records visible instead of buried in a rounded total.
Our preference for a clean register has a limit. Repeated desktop reconciliation can consume time without resolving a locked building entrance or an uncertain property boundary. We send those questions to targeted field verification and retain the uncertainty in the planning record. The owner can then decide whether to hold that area or authorize a bounded assumption for design.
Test demand before drawing serving areas
Separate interest from take rate
A request for updates, a service preorder and an activated subscription provide different evidence of demand. We keep those categories separate when testing take rate, defined for a stated date and denominator. The forecast should say whether it refers to all planned premises or only premises that will be ready for service by that date. Otherwise, the same percentage can describe different commercial outcomes.
The basic relationship is straightforward: expected connections equal serviceable premises multiplied by the assumed take rate. Both inputs need a common boundary. Applying a forecast for a dense neighborhood to an entire mixed-density footprint can conceal weak demand on the outer branches, even when the overall total appears reasonable. We compare serving-area forecasts before accepting the combined business case.
Keep uncertainty in the investment decision
Ask the owner for a base forecast and a downside case, with the evidence supporting each assumption. We also test what higher demand would require from the planned footprint. These are planning scenarios, not claims about achieved adoption. A case should change because the underlying evidence changes, such as building access becoming available or a demand campaign reaching previously uncontacted premises.
The forecast should distinguish expenditure needed to pass the intended footprint from expenditure triggered when a subscriber orders service. Low early adoption does not remove the route required to reach a remote cluster. We flag that distinction before a phase is funded, so a low connection forecast does not quietly become permission to omit homes the owner committed to cover.
The remaining decisions turn those assumptions into a buildable program. Use this planning comparison to identify the unresolved choice in each workstream before authorizing engineering.
| Planning workstream | Decision before design | Evidence handed forward |
|---|---|---|
| Architecture | Centralized or distributed split preference | Operating rationale and conditions for review |
| Serving areas | Boundary and candidate cabinet location | Assigned premises and access questions |
| Aerial and underground mix | Preferred corridor treatment | Records reviewed and field verification needs |
| Phasing and approvals | Release sequence and dependencies | Phase map and permit or make-ready assumptions |
Choose architecture and candidate serving areas
Centralized and distributed splitting
Centralized splitting groups the optical split at a hub, while distributed splitting places split stages farther into the serving network. Corning's Choosing the Right FTTH Network Architecture describes the tradeoff between centralized flexibility and the leaner distribution arrangement available with distributed splitting. At planning level, we compare those operating consequences before committing to particular splitter products or ratios.
A centralized approach deserves consideration when the operator values flexible customer assignment at an accessible hub. The planner must still establish a credible place for that hub and the routes that reach it. Distributed splitting deserves consideration when smaller downstream groups fit the settlement pattern and the operator accepts the resulting field access and maintenance arrangements. Neither preference settles the engineering checks.
Our architecture recommendation should explain how the operator will accommodate growth. If later connections require reopening difficult locations, that consequence belongs in the comparison now. We also ask whether a proposed approach fits the operator's existing practices, because a theoretical material saving may require an operating change the owner has neither staffed nor accepted. Engineering then tests the preferred approach against its technical limits.
Boundaries follow access and route constraints
A serving area needs a credible path back to the upstream network. We begin with premises clusters, then test whether physical barriers make the apparent grouping impractical. A group on the other side of a controlled crossing may belong in a different phase even when it sits close to the proposed cabinet on a map. Distance alone cannot establish a useful boundary.
Cabinet placement starts as a candidate location with a defined status. Check whether the operator can obtain access and whether the position permits safe maintenance. A convenient point in a public map can fall outside the available right-of-way or conflict with another use. We retain an alternate location when losing the preferred site would change the serving area substantially.
Keep each premises assigned to an identifiable serving area as boundaries change. That assignment lets the planner recompute demand when a cabinet candidate moves, rather than carrying an old count into a new polygon. It also reveals gaps at the edges, where neighboring areas can each assume the other will serve a small cluster. Resolve the responsibility before detailed design begins.
Where uncertain counts keep changing proposed hub boundaries, our FTTH network design services carry the agreed planning assumptions into engineering review. Draftech performs engineering 100% in-house. The useful starting point is a versioned premises register with a stated architecture preference, so design can test the owner's intent instead of reconstructing it from disconnected maps.
Plan the aerial and underground mix by corridor
Test the preferred construction approach
A network-wide aerial percentage tells the owner little about the corridor that controls launch. We classify route segments according to the evidence available, distinguishing an assumed attachment path from plant whose suitability has been investigated. Existing poles may suggest an aerial option, but the planning schedule must still account for access permission and the make-ready work identified through the applicable review process.
Underground segments need equally clear assumptions. Existing conduit shown in records should remain unverified until access and usability are established; a line on a map cannot demonstrate spare capacity. For a proposed new underground route, we flag constrained crossings and areas where surface conditions need investigation. The plan identifies where uncertainty could force a different corridor, without prescribing construction details ahead of survey.
Preserve alternatives where a route can fail
An alternate route is useful only if it changes the dependency that threatens the preferred route. Moving a line to the opposite side of a road may leave the same crossing approval unresolved. We compare alternatives by the premises they reach and the permissions they require, then record which owner decision or field finding would trigger a switch. That keeps options tied to a practical decision.
The construction mix also affects who must review the planning assumptions. An aerial corridor needs input from the team handling attachments; an underground corridor needs attention to civil access and surface restoration constraints. We bring those perspectives into planning before setting the launch sequence. Draftech delivers full turnkey construction through Draftech-managed subcontract crews, with engineering retained in-house.
Sequence phases around permitting and make-ready
Release areas that can become serviceable
A phase should end in an operational result the owner can describe. Building distribution in a neighborhood has limited launch value if its upstream connection depends on an unresolved corridor outside the phase. We map that dependency explicitly and distinguish work that can proceed independently from work that needs a shared feeder first. The phase boundary must support the activation plan.
Demand helps rank phases, but it cannot erase prerequisite work. A high-interest cluster may be a poor opening phase if its sole access route is uncertain. Conversely, completing an enabling corridor may enable several later areas even if that corridor passes few immediate customers. We show the commercial benefit beside the dependency so the owner can make the sequencing decision knowingly.
Confirm the cabinet site early: Before treating a serving area as settled, identify who can authorize use of its candidate cabinet location. A change at that point can affect every premises assigned to the area, even when the distribution corridors remain available.
Put approval assumptions on the schedule
Permitting and make-ready need their own planning logic. Identify the authority or asset owner for each corridor and establish what starts its review. Some planning questions can be discussed early, while a formal application may require engineering that does not yet exist. We separate early coordination from submission readiness so the schedule does not assume that a preliminary conversation has started an approval clock.
Record estimated lead times with their source and the date they were checked. Ask whether the estimate covers review alone or also the work required before construction can start. Our discussion of make-ready timing for fiber deployment explains why those activities must remain distinct. We use project-specific information for the schedule rather than assigning a universal duration to every attachment corridor.
A schedule needs a response to delay. Name the condition that would release a different phase, and check that the alternative still has a usable upstream path. We keep owner decisions separate from dependencies controlled by others; that distinction shows which dates the project team can move and which need confirmation from an outside party before a launch commitment becomes credible.
Hand off the FTTH network planning decisions
Give design an approved basis and open questions
The planning package should let an engineer trace each boundary back to a decision. Hand over the service-area map with its premises register, keeping the same identifiers across both. Include the demand assumptions and the rationale for the preferred architecture. The candidate cabinet sites should carry their access status, rather than appearing as fixed assets simply because a symbol has been placed on a drawing.
Provide the phase map with its approval dependencies and explain what would change the release order. We also preserve the corridor assumptions so an engineer can prioritize fieldwork where a different result would change the network materially. The OSP high-level design checklist addresses the subsequent HLD review; this planning handoff supplies the owner's decisions that the review must test.
Mark approval boundaries clearly. The owner can authorize design for a defined footprint while leaving an access question open, provided the affected work is identified and the designer knows when to stop for a decision. We recommend a dated baseline and an accountable owner for each unresolved issue. When a count or boundary changes, the revision should explain the downstream impact before the new version replaces the old one.
Match the next action to the build
For a new market entry: Reconcile the premises register and substantiate demand before funding a full design footprint. Commit to the initial area only when its upstream connection has a credible path. This gives the commercial team a serviceable boundary to evaluate and prevents early enthusiasm from fixing a phase that depends on an unavailable corridor.
For an extension of an operating network: Confirm the available handoff and operating constraints first. Use those findings to test whether the proposed serving areas fit the existing system before opening new cabinet locations. The value of that sequence is practical: an extension should preserve the operator's ability to serve existing customers while the new footprint is brought online.
For an owner with a fixed coverage obligation: Keep the entire required premises set visible when sequencing work. Do not allow a favorable early phase to conceal an unresolved outer area. Require a documented path to the remaining premises before treating the phase plan as complete, even where the final route still needs engineering validation.
Uncertain building counts and unconfirmed cabinet access are specific reasons to pause a design release. Draftech can turn that planning uncertainty into defined survey and engineering work; send the proposed boundary and the question holding it up to info@draftech.com. We can then discuss the scope needed to establish a usable design basis.
For a qualifying route, Draftech's free design offer covers engineering of the first 20,000 linear feet at no cost, from feasibility and field survey through permit approval. The owner reviews each request before Draftech commits the package. Bring the proposed route and its unresolved planning constraints so that review can address the work the project needs.
Discuss the planning handoff: Talk to Draftech about the decisions holding up your design release.

