What this issue boils down to is a guiding principal of neutrality. Now it’s hard to know what if any principals have been guiding the development of the UFB architecture since I cannot find any in the few documents that CFH and the TCF have so far made public. (This may be radical to suggest, but I think CFH needs to be more open and engaging. Hey CFH, how about doing a blog post on what you think about neutrality and take it from there?)

What should be the guiding principal here? Well we need to ask what we are building the UFB for and what we want it to achieve, and I can’t speak for other people, so this is only my perspective, but it’s one I think most people who consider the UFB as a project of strategic importance for New Zealand’s future will agree with.

The Government should not be taking on all the risk of building the UFB simply so that established providers can continue to provide the same services they do today, or entrench their positions. I believe the purpose of the UFB, and any similiar national broadband programme, is to provide a neutral platform that allows retail service providers (RSPs) to compete equally on the basis of how good their products are regardless of their size. For this reason the UFB must aim to minimize its influence on what shape those products take. Thus distinctions must not be made between types of applications or style of service delivery. That must be decided by the consumers and the competition between the RSPs.

So with that in mind I was concerned when I heard that the current proposal is have two classes of service, a high priority class and a low priority class, as illustrated in the table below taken from the TCF UFB Ethernet Access Service Description.

Let me be clear. This is stupid. (Or I’m stupid and not seeing how this is going to be used.)

What does this mean? Well it will depend on how it is going to be used. First let’s take a look at these two classes.

We have a high priority class which has tight SLAs. This class is not colour-aware, meaning that it doesn’t support the concept of bursting above the committed information rate (CIR). Excess traffic over the CIR is dropped. I do approve of the 5 ms frame delay (latency) and 1 ms frame delay variation (jitter) SLA. But I disagree with the 0.1% frame loss ratio. 0.1% is too much for what should be absolutely committed capacity through the network. Instead this frame loss ratio should be closer to 0.01%, but couched with availability, which is supported by the MEF framework that the TCF are sort-of using here. That is, we should say that 99% of the time frame loss will be below 0.01%, but 1% of the time there may be some failure or event on the network that causes it to go higher.

The other class has pathetic, almost non-existent SLAs. It is basically a service where if there is available network capacity at that time the packet will be forwarded, otherwise it may be queued for a full second, and may never get through. There is no defined FD or FDV, and the FLR at 2% is absolutely ridiculous as anyone who knows anything about networking will tell you. This document gives the impression that this class is colour-aware, but actually it’s still a single-rate class as the CIR is always zero.

I really don’t know how they arrived a this, I can imagine there was a lot of debate at the meetings, and I recognise that design by committee can be difficult at the best of times.

Ok-ok, so hurry and get to the point, you’re saying.

To me, the above implies that the two classes of service will be carried in separate queues through the UFB networks. The high priority class is the only class offering a CIR and will carry applications such as voice and video that require committed bandwidth. The low priority class offers no commitment and will carry Internet, possibly with an atrocious quality of service if the SLAs shown are any guide.

So imagine you’ve subscribed to a triple play package from your RSP. You have one phone, and one TV, so your RSP orders a service from the local fibre company with:

• 150 Kbps of high priority bandwidth for voice, enough for one voice call since you have only one phone.
• 10 Mbps of high priority bandwidth for video, enough for delivering one HD stream since you have only one TV.
• 50 Mbps of low priority bandwidth for Internet — an arbitrary number for this example, and presumably this will vary depending on each RSPs packages, e.g. there may be a 10 Mbps package, 50 Mbps package, and 100 Mbps package.

The UFB network receives traffic from many competing RSPs and delivers it to many subscribers over shared links, so queuing and scheduling must be used at these points within the UFB network to provide the desired differentiation between the two classes of service. The indication is that the high priority class will be given bandwidth before the low priority class in a strict priority or weighted fashion. (This is a simplification of the issue sufficient to illustrate the point below, but it should be noted that the problem is actually much larger, requiring the use of H-QoS to ensure fairness between the different RSPs and their respective subscribers.)

Now coming back to our scenario. Consider we are watching a VoD stream from our ISP during peak hour, and this is an HD stream requiring about 9 Mbps of bandwidth (depending on how much action is going on). As we outlined above this is delivered in the high priority class of which we have 10 Mbps to play with, so we can be certain the stream gets through in a timely manner without packet loss and the associated skipped frames or artifacts.

But we get bored of this, so turn to an over-the-top (OTT) video service (such as Hulu, NetFlix, or YouTube) for entertainment. These are delivered over our Internet service, which as we outlined above has 50 Mbps of low priority bandwidth with basically no SLAs.

Now we find that our OTT video service is getting a lot of buffering because it is peak time and there is congestion on the UFB network. It turns out everyone in our neighbourhood has come home after work and started watching TV. All of these TV streams are being carried in the high priority class so getting the share of the bandwidth on the UFB network before our Internet traffic. Our OTT service suffers as a result.

Hang on, you say, you’re no longer watching the VoD stream, but you are paying for 10 Mbps of high priority bandwidth to carry it. So when you’re not using that 10 Mbps for VoD where does it go? And who decided a VoD stream from your RSP is to be treated differently to a VoD stream from an OTT provider? You’re right to ask that. When you aren’t using your 10 Mbps of high priority bandwidth it gets shared out amongst everyone elses low priority traffic — it does not get assigned to you, you see only a fraction of it, even though you’re paying for it. And who decided that VoD from your RSP is more important than VoD from an OTT provider? Apparently CFH and the TCF did back in February.

So what’s the solution? Well this is a complex subject and there are a few solutions. In order to select the best solution the guiding principals must be established and the detailed requirements analysed. One could easily end up writing hundreds of pages on the subject, so given I get no reward for that, I’ll jump to those solutions that are readily apparent.

1. The above two classes of service could be modified to make the low priority class dual-rate, supporting a CIR and EIR, and tightenting its SLAs, with the high priority class priced to discourage its use except for very low bandwidth and special applications. The UFB network will perform the necessary H-QoS to ensure fairness between the RSPs, i.e. between the aggregate of subscribers for each RSP, but not at a per subscriber level. The RSPs will be responsible for performing the H-QoS necessary to ensure fairness between each of their subscribers and appropriately prioritise their applications and if they choose to also OTT applications. (Some inventive RSPs will choose to give the consumer granular control over this through a portal.)
2. As above, but the high priority class is simply dropped because it serves little useful purpose, and simplification is better.
3. The UFB network performs per-subscriber H-QoS on behalf of the RSPs based on the purchased bandwidth profiles. Each subscriber is guaranteed the amount of bandwidth they actually pay for, but the H-QoS is configured with multiple queues in a mix of strict priority and weighted round robin fashions. The RSPs can then manage the markings of different applications to indicate the relative priority of them and which queues they should go into.

If anyone in charge is listening — please take another hard look at this. I am happy to eat my hat if I’m wrong, but this is an issue fundamental to the purpose of the UFB, and we want to get matters such as this correct up front, rather than trying to address it later on when there is no regulatory powers to do so (given the Government’s insistence on a 10 year regulatory holiday).

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.

Deployment area

Crown Fibre has released a fact sheet which includes the following map of the deployment area. The deployment will cover the urban area of Whangarei that they claim consists of a “population of nearly 52,000, including more than 2,000 business premises, and over 300 medical and other healthcare services, with over 20 schools.” It’s also important to know how many homes there are, so for that we turn to the 2006 census and find that there are 28,149 occupied dwellings in Whangarei District. The district actually includes a large rural area not currently covered by Northpower’s indicated UFB deployment, but we can refine this using the meshblock data to find there are 16,851 occupied dwellings in the indicated deployment area.

But what about the rest of Northland? There are plenty of smaller centres with reasonable populations, for example Dargaville with around 4,500 residents, or Kaitaia and Kerikeri with around 5,000 each. I think we should have a road map for these centres. This is where Telecom should have an advantage over other proposals, if only they hadn’t spent so much time trying to derail the project and had instead embraced it from the start — but I want to talk about that in a future post, so for now let’s move onto the network design.

Network basics

The network will use GPON to deliver wholesale Ethernet services for use by the majority of customers, but the physical network will also support wholesale dark fibre for use by service providers, enterprise customers, and big institutions. The optical distribution network (ODN) has a dedicated fibre between every premise and the local convergence point, also known as a fibre distribution hub (FDH). These are small passive cabinets, and there is usually one for every 200 to 400 premises. We locate the splitters in the FDHs because this gives us the optimal flexibility, future proofing, and manageability. Feeders run from the FDH back to the central office where the OLT is housed. The term central office typically creates visions of a large exchange building, but this is not the case in our network. We only have a small amount of equipment and small number of fibre terminations to house, so a large exchange building is quite simply overkill and would be a massive unwarranted cost. A roadside cabinet or portable telecommunications hut will be sufficient in most cases. The OLT is then connected back to the aggregation switch where handovers are made to service providers.

You may be wondering about how I arrived at the ranges shown on that drawing. The range between the aggregation switch (BSA) and OLT can be whatever is supported by the installed optics, and then much longer in cases where DWDM is used to provide transport. I use <70 km as a rule of thumb for discussing concepts. The range between the OLT and the ONT is a factor of the split ratio, the GPON type, and number of connectors and splices. The typical example I use to get my <10 km rule of thumb is described below.

To start with we must know our power budget, which is the difference between the launch power and the recieve sensitivity as described in ITU-T G.984.2. For class B optics we have a 26 dB budget and for class C optics we have a 31 dB budget. This budget gets consumed as follows.

• 3 dB reserve for cable breaks and repairs.
• 0.5 dB for each pair of mated connectors. We have a connector at the port on the OLT and another at the port on the ONT. Ideally in between these everything is fusion spliced to reduce faults and maintenance, but I’ll allow for another connector at the NAP in case pre-connectorised drops are being used. 3 × 0.5 = 1.5 dB
• 0.05 dB for each fusion splice. Let’s allow for 10 fusion splices between the OLT and farthest ONT. 10 × 0.05 = 0.5 dB
• 3.5 dB for a every 1:2 split. Higher ratio splitters are just trees of binary splits, so the formula is log2(n) where n is the split ratio. Let’s allow for a typical 1:32 split ratio. log2(32) * 3.5 = 17.5 dB

At this point we’ve accumulated 22.5 dB, leaving us with around 4 dB for class B and 8 dB for class C. The downstream operates at 1490 nm and the upstream at 1310 nm wavelengths. In G.652 fibre these have a typical attenuation of around 0.2 dB per km and 0.3 dB per km respectively. Of course we need bidirectional communication to make things work so we’re bound by the higher 0.3 dB figure. From this we can conclude a range of around 10 km for class B and around 25 km for class C.

I’ve used a 1:32 split ratio above, but the Crown Fibre fact sheet for Whangarei tells us that they’ll be using a 1:24 split ratio. This doesn’t entirely make sense as splitters work as a binary tree. The fact sheet says, “GPON is split 1:24 enabling up to 24 customers to receive 100Mbps downstream and 50Mbps upstream,” from which I’m inferring that they’ve simply said 1:24 because 2.4 Gbps × 1:24 = 100 Mbps, and 100 Mbps is some magic number for Crown Fibre. Of course this also doesn’t make sense as some customers will elect to take lower speed services than others, and GPON’s dynamic bandwidth allocation (DBA) means that you oversubscribe the bandwidth, but I won’t digress down that path now.

One benefit of a smaller split ratio is less attenuation, which means we get a longer range. Remember the splitters are a binary tree, so in the case of a 1:24 split, we could have a range to 16 of the premises of up to 10 km as described above, but for 8 of the premises we gain an extra 3.5 dB because we drop one split, giving us an extra 10 km range to those 8 premises. Conceivably we could use such a splitter scheme for example as follows, allowing us to reach some more distant premises.

But there isn’t any difference between that and the following. The truth is the splitter scheme can vary to suit the specific situation.

This is where I’ll leave part 1 for today. In part 2 we’ll explore some conceptual topologies for Whangarei.

Rather than expand again on the principals of such networks, I’ll do the reverse and list some of the things that I believe would be a failure of CFH to get us the right deal. I believe the following will result in less economic transformation, less social benefit, less competition, worse service, and — what everyone cares about — higher prices.

• Sporadically connecting homes on demand as opposed to connecting all homes in a structured manner as part of the roll out.
• Not requiring an open access network offering the basic wholesale layer 2 services.
• Not having a well defined set of wholesale layer 2 services and cost model for these.
• Not having a framework for how these wholesale layer 2 service will be enforced and enhanced over the following decades to meet the evolving requirements of service providers and their customers.
• Permitting cross subsidization of wholesale services.
• Not using a network architecture that recognises the importance of aggregation for manageability, throughput, and cost efficiency.
• Using home-run fibre.
• Running drops all the way from the cabinet as opposed to a NAP in the street.
• Using blown delivery from the cabinet (see above).
• Encumbering any LFC with any of the partner’s legacy investments. For example if Telecom were to propose the establishment of an LFC that took ownership of Telecom’s existing copper outside plant, existing cabinets, or existing equipment, this would be bad. These have next to no value once you’ve decided to build a new FTTH network. Doing this is only a way for the partner to try to architect extra return from these prior investments.
• Deploying outdoor ONTs as opposed to indoor ONTs.
• Installing battery backup for all ONTs. Only necessary for those requiring lifeline services for which mobiles are insufficient, and even then this is really a larger subject: should we even bother with a POTS service on the UFB networks?
• Permitting any LFC to operate non-access services in competition with service providers. LFCs must only offer services between recognised service providers and their clients, not between subscribers. This applies to both the layer 1 and 2 services.
• Having more than two POIs for the wholesale layer 2 services within any 30 km radius. (Roughly speaking that is. Varies with circumstances.)
• Encumbering the LFC with the requirement to provide housing for service provider equipment at non-POI sites. Roughly one cabinet in each 5 km radius is all that is needed to house the MSANs.

Meanwhile, a quick post on the proposal for Chorus to be the UFB partner. In this article it is claimed that Telecom has 25,000 kms of fibre already in the ground: Telecom hopes for a break on regulation if it separates.

Really? They’re not including Southern Cross are they? That’s great, if it’s accurate. The problem is that probably more than half of this is running down state and local highways and linking towns and communities. It’s not the fibre in the street running past those homes in New Zealand’s urban areas that the UFB project is targeting.

To give you an idea of what is needed I’ll pick on Wellington, only because the council makes available the convenient fact that they maintain 654 kilometres of roads. This is good enough for us to make a first order assumption that the UFB project needs to deploy between 654 and 1,308 kilometres of cable and duct in Wellington to serve it’s 67,000 households. Why do I say 1,308 kilometres? Well sometimes we might need to run ducts down both sides of the street, in other cases there’ll be one duct down a street but lots of ducts drilled across the street to provide drops into homes. So simply doubling the route kms gives us a very nice fudge factor to cater to both situations.

Now if we use the National Broadband Map to check out Telecom’s fibre assets in Wellington’s southern and eastern suburbs we see that the fibre is actually quite sparse.

What’s more, this fibre may not be appropriately designed for FTTH, requiring some reworking. The reality is that the value this brings is not as great as Telecom might like us to think. It may seem like I am beating up on Telecom here, I’m not. As I’ve said before, having Chorus as a partner does makes sense, if done right. I don’t have the confidence that the bureaucracy springing up around UFB could get it right though.

Why is it that FTTH has had to face a far more stringent test of its business case than the billions of dollars poured into roads every year in this country? Even today there are deniers out there that still think the meagre $200 million per year over 8 years that will be spent on deploying FTTH is a waste. Yet anyone who looks at transport funding will know that road spending has almost no business case.

In this Auckland context, let’s take the proposed Waterview Connection, at $1.4 billion (though there are serious questions about that). You would expect that to spend $1.4 billion dollars would require a lot of analysis, first examining and setting the goals, and then looking at options on how best to achieve them. Well no, there have been absolutely zero comparitive studies according to NZTA. The decision has been made to build a road, and the only question has been what kind of form will that road take. So we can spend billions of dollars a year on roads this way, even while other countries are increasingly redirecting their transport spending away from roads. But when it comes to spending a comparitively meagre amount of money on something that all of the top countries in the OECD are doing (some have been doing it for quite some time now), and when it actually pays for itself, there are still so many naysayers. I would love to see a day when transport spending had to stand up to the same tests FTTH spending had in this country.

If there had to be a choice, between this one over-priced 4 km stretch of road with questionable returns, versus 75% of the country having FTTH, I think it’s pretty clear which is the better purchase.

“The actual quantum of investment required is not yet clear. Based on the estimates of independent expert Dr Murray Milner, the real cost of the investment may be as high as $5 to $6 billion,” it says. “In Australia, the government has announced a total requirement of A$43 billion to reach 90% of homes which when mapped to the New Zealand context indicates a figure closer to $9 billion. There is clearly more work to be done on the business case.”

$43 billion is certainly the upper limit. More realistic estimates, based on real-world experience in deploying FTTH, both in Australian brownfields and greenfields, put the likely cost at less than half of this figure. So simply scaling that figure to fit New Zealand isn’t advisable.