Whangarei case study (part 2)
I’ve been playing with PostGIS recently, so I thought I’d start part two with a quick map showing the dwelling density of each area unit from the 2006 Census and the roads from Whangarei District Council. The area units shown correspond reasonably closely to the deployment area indicated by the map in the Crown Fibre fact sheet.
Equipment
A good OLT will support a minimum of 80 GPON ports, which at a 1:32 split ratio permits over 2,500 premises to be served off each OLT. This OLT must also be capable of at least two 10 Gbps uplinks, but a good one should give us the option to go to four 10 Gbps uplinks, e.g. if an OLT ends up with a lot of high bandwidth services on it.
The other piece of equipment is the aggregation switch, I like the term broadband service aggregator (BSA). The role of the BSA in our network is to aggregate connections from the OLTs and handover the wholesale Ethernet services to the retail service providers. A decent BSA will support at least 48 10 Gbps ports today with a roadmap to twice that (or in some cases four or more times that). We don’t need 1 Gbps ports for our OLTs, those really must connect at 10 Gbps, but it is conceivable that some smaller retail service providers will want the option to connect at 1 Gbps. That said, we can get over 40 such ports in a single slot so there is no concern about 1 Gbps port capacity.
There is no need to consider DWDM in this network because it is so small.
Coming back to the statistics from part 1, we have 16,851 dwellings, “2,000 business premises, and over 300 medical and other healthcare services, with over 20 schools,” for an approximate total of 20,000 premises. We can see this is going to be quite a small network: we’ll only need 10 OLTs, and two BSAs. In a FTTH deployment this equipment is the cheap part. Under 400,000 for each of our OLTs for a total of $4m. Our two BSAs aren’t fully populated, and should come in south of 500,000 for a total of $1m.
Deployment
Thanks to the Whangarei District Council releasing their GIS data on Koordinates we can quickly estimate the total linear length of our deployment. A query of the total length of all roads in the deployment area (in this case as shown in the image above) returns 278 km. At a minimum fibre must be deployed once down the length of every road, and at a maximum twice this. The actual requirement will fall somewhere towards the top end as of course it is almost always necessary to serve both sides of the road. (Some readers may be thinking they’d only run one distribution cable down the street, but you still need to drill across the street to deliver the drops to each premise, and in New Zealand our frontages aren’t much different to the street width so it typically works out as twice the length.) If we took the time and had the relevant per unit costs we could quickly build an estimate of the total deployment cost from high level designs of sample areas. But for our purposes a quick first order approximation will suffice, to get that let’s assume an average cost of $100 per meter to encompass the pits, pipes, cable, and closures. 2 × 278 km × $100 = $55.6m.
Topology
To get a quick idea of how our 10 km rule of thumb for the GPON range applies to the deployment area I’ll turn to Free Map Tools to plot the 10 km driving radius in various directions from the centre of Whangarei. Another useful tool (for those without access to their own GIS) is the Google Maps route planner, it has the nifty ability to plot routes and let you drag and adjust them while giving you the distance.
As you can see our 10 km GPON range comfortably encapsulates the entire deployment area and then some. From this we might conclude that everything could all be delivered from one central office, so should we just bang everything into one building and be done with it? To answer that we’d need to fully develop the outside plant architecture and validate our range estimates against the actual topology, understand growth, compare costs, and analyse the availability requirements.
Existing infrastructure will have a major impact on the cost comparison. Telecom for example might have an existing central office that is highly resilient and has a lot of useful life left in it. In this case it might make sense to centralise most if not all of the equipment. Telecom would also have existing fibre, of which much must be overbuilt (reducing its value to almost nothing), but some won’t need to be overbuilt, particularly where it connects an isolated suburb or centre. Looking at our map above the Onerahi peninsula (bottom right) might be an example of this. The existing cable would need to support the 2230 dwellings: at a 1:32 split that’s 70 cores. If it couldn’t then we might find the cost in this case to run a new cable outweighed the cost of deploying a cabinet to serve those suburbs.
The most important consideration of course is meeting the availability requirements. There is always a risk that any facility can be taken offline, particularly in a natural disaster. The question becomes how many premises can we accept going without fixed line services, for how long, and under what circumstances? A cabinetized approach in this case merely divides this risk down.
One thing to note is that if we do centralise everything into one building then we cannot offer fully redundant wholesale Ethernet services. This is only likely to be requested for a small portion of the commercial premises. So our choices are to design the PON network with this in mind in those likely areas, allowing us to deploy two ONTs off of two different OLTs via diverse paths, or to omit this and instead when diversity is required the retail service provider will have to use two dark fibre services that follow diverse paths back to their chosen POPs. In the case of Whangarei this latter option probably makes the most sense.
On this note, I do believe we need to switch our attitude. There is an assumption by many that the fixed line network provides lifeline services and must be the most resilient. Some people seem overly concerned about things like battery backups for ONTs. I believe we must shift our emphasis to ensuring our wireless networks are resilient and always available during emergencies. We already do have outages on our existing fixed line network. (I once needed to call 111 in a life threatening emergency but landlines in our entire neighbourhood had been down all day due to an overzealous digger a few blocks up the street. Fortunately mobile services were operational.) Can we expect to use the mobile networks in an emergency? I think there’s an important discussion to be had here about how much we want our different networks in New Zealand to share facilities, and what regulatory requirements wireless networks should have for availability and location reporting during emergencies.
