Section 30R review of Chorus UBA Service

PDF copy of the submission can be found here.

Section 30R review of Chorus UBA Service

InternetNZ Cross Submission

15 December 2016

Introduction

1.1 InternetNZ thanks the Commission for the opportunity to provide a cross submission on submissions made on the draft determination under Section 30R of the Telecommunications Act.

1.2 We welcome further opportunities to discuss our views. Please contact Reg Hammond on 021569980 or reg@internetnz.nz.

1.3 In the initial InternetNZ submission we raised two major issues and said we would look at other issues in light of the other submissions made. In the event, it appears that the two major issues we identified have also been the major focus of all other submissions bar the Chorus submission.

1.4 This cross-submission will cover four major points:

a) Our original view that the Commission's specification of what a congestion free Local Aggregation Path (LAP) is, is flawed.

b) Our original view that a focus on a congestion free LAP is unlikely to resolve the current problem of poor service for ~20,000 rural users; in fact by carving out the ATM network this problem is exacerbated. InternetNZ believes that the only viable solution for this group of customers to get a "fit for purpose" service is a reasonable minimum throughput. We recommended that this reasonable minimum throughput should be 450kbps increasing by 50%pa. The current regulated price for the UBA service is such that Chorus is being compensated through averaged pricing to provide such a fit for purpose regulated service.

c) We disagree with the submission made by Chorus regarding the need for new exceptional circumstances.

d) We comment briefly on what we think is a better process for resolving operational processes.

95% utilisation is too high for a “congestion free” Local Aggregation Path 

2.1 It is clear from the submissions of 2 Degrees, Spark and Vodafone that a network with a utilisation rate of 95% is already congested and customers are suffering from a degraded service. We agree with Spark that with utilisation set at 95% it will incentivise Chorus to work to that standard. Vocus and TrustPower submissions also submit that 95% is inappropriately high.

2.2 Collectively, submissions other than Chorus's recommend that reporting planning requirements should be triggered at around 70% - 75% and peak utilisation should never exceed 80% - 85%. They also generally submit that the reporting period should be 5 minute periods not 15 minute and that the ATM network should not be exempt from any reporting requirements.

2.3 We also indicated in our submission that without clear penalties for breaching these requirements there was little incentive for Chorus to comply with them. Comparatively, the prospect of a future S30R review is unlikely to provide Chorus with any real incentive to comply.

2.4 For their part, if RSPs are requiring higher standards from Chorus they too should be prepared to meet those same standards. This is because end-users are in no position to know whether congestion is being caused in the RSPs network or the Chorus wholesale network. All those submitting maintain that they already meet or better the standard they expect from Chorus so meeting it themselves should not be a burden.

A congestion free LAP is not a sufficient solution for the 20,000 rural consumers receiving poor UBA service.

3.1 We consider this as the most pressing issue that the Commission should address through this review. It is further complicated by the proposal to carve out the ATM network.

3.2 As the Spark submission says:

"6. The Commission also proposes to revisit the ATM performance obligations following the RBI2 implementation. We support the Commission considering linkages between UBA investment and pricing, and RBI2 investment. The two are inextricably linked.
7. However, the RBI2 process could last an extended period and the outcome is not certain – leaving 19,000 end users sitting on poor performing services and resulting in uncertainty for Chorus and competing RBI2 investors. The RBI2 process will deliver the best outcomes where it can focus on areas that are not already commercially viable or funded through existing regulated pricing."

3.3 While Spark is clearly focussed upon the distortionary effect on competition of the Commission's proposal, InternetNZ is more focussed upon the perpetuation of poor service for rural customers.

3.4 We must question the Commission as to why it now sees fit to carve out the ATM network, on the grounds that it is in the best long term interest of end-users, when that same ATM network considered as part of the Final Pricing Principle (FPP) process; AND it was a significant determinant of the price set through that process.

3.5 When these matters were considered through the FPP process, the logic employed was that Chorus would be incentivised to meet the hypothetical service standard used to derive the FPP price. That would then result in improved services for end-users.

3.6 Our contention is that instead, that incentive structure does not appear to be working in that manner at all. As a result, Chorus is effectively receiving a higher price than it would have otherwise been entitled to, to not provide sufficiently performing copper services to approximately 20,000 rural users.

3.7 InternetNZ believes that it is fundamental to the integrity of that FPP process and this subsequent 30R review that the 450kbps requirement (raising by 50% PA) is inexorably tied to the price set as part of the FPP process. The two cannot and should not be separated. Instead, the Commission should seek to enforce that performance standard, as it is that performance standard that Chorus is being paid to provide.

3.8 There appears two options available to resolve this:

a) that Chorus provides the UBA service at a minimum of 450kbps, rising by 50% per year; OR

b) that Chorus accepts lower payments for services that aren't capable of performing at that standard, on the basis that they are unable to meet the regulated service description and therefore should not receive the regulated price.

Chorus' call for new exceptional circumstances

4.1 The Chorus submission groups four items under this broad heading; we will consider each in turn:

a) diversity restoration;

b) large unexpected demand peaks in bandwidth;

c) denial of Service (DOS) Attacks; and

d) unexpected ISP testing.

4.2 Diversity restorations required as a result of something such as the Kaikoura earthquakes are already covered by existing force majeure provisions. It is difficult to comprehend why Chorus would include this as a new exception, apart from to add weight to these other proposed exceptions.

4.3 Large unexpected demand peaks in bandwidth are exactly what Chorus (and RSPs) should be planning for. Chorus and the RSPs are all sufficiently experienced in providing service to the New Zealand market to be able to predict variations in demand. Things such as major sporting events and other premium content are well advertised and generally heavily promoted by service providers – indeed they are what persuade most end-users to take higher level services. Clearly, the lower the utilisation rate is set the greater the ability of operators to accommodate such demand peaks. This would seem to us to be a good reason for utilisation rates to be set at the 80%, or less, level.

4.4 With regard to DOS attacks: we understand that all major operators are constantly monitoring their networks for such attacks and have some means to manage the impact these attacks have on their networks. We also note that due to the scale of a network operator like Chorus, any such attack would likely need to be quite massive to cause any significant challenge to their capacities. If, as we have suggested, the Commission specifies penalties for operators failing to meet the required utilisation rate, it would seem to us that in the very rare likelihood that there was a truly significant DOS attack that the Commission could exercise discretion and take that exceptional circumstance into account when considering whether to impose any penalty.

4.5 Unexpected ISP testing is surely an operational matter between Chorus and the ISP and needs to be resolved at that level – it is not a matter for the service standard to be concerned with. As we have already submitted in the matter of utilisation rates and reporting requirements, RSPs need to be held to the same standards as Chorus for their own networks.

Operational processes and transparency

5.1 There was a lot of discussion at the Commission's workshop about various operational processes and transparency of Chorus systems which have subsequently been covered in submissions. The general consensus of submissions is that these issues are best sorted out through established operational processes and via TCF workgroups. In general, we support such pragmatic approaches but recognise that historically the best outcomes for end-users have been achieved when the Commission or the Government takes an active part in the process or oversees it to ensure timely and effective outcomes on behalf of end-users.

5.2 We would encourage the Commission to take an active role in ensuring that operational systems and transparency throughout the industry are "fit for purpose."

Submission: 
Thursday, December 15, 2016