Basic UBA Product User Guide

Basic UBA product user guide | November 2016 1

Basic UBA Product user guide


Table of Contents 1 INTRODUCTION 4

1.1 Who is it for? 4

1.2 About this document 4

1.3 Purpose 4

1.4 Updates 4

1.5 Relationship with other documents 4

1.6 Intellectual property 5

2 KEY BENEFITS 5

3 PRODUCT DESCRIPTION 5

3.1 Introduction 5

3.2 Basic UBA components 6

3.2.1 External termination point (ETP) 6

3.2.2 Basic UBA access 6

3.2.3 Coverage area 6

3.2.4 Local aggregation path 6

3.2.5 Parent handover point 6

3.2.6 Handover point 7

3.2.7 Handover link 7

3.2.8 Backhaul 7

3.3 Variants of Basic UBA 7

3.4 End customer interface 8

3.5 Your interface 8

3.6 Aggregation of traffic 9

3.7 IP addressing 9

3.8 Interleaving 10

3.9 Geographic availability 10

3.10 Modem installation 10

3.10.1 Approved modem list 10

4 ORDERING 11

4.1 Prerequisites 11

4.2 Basic UBA service requests 11

4.3 Prequalification 11

5 FAULTS 12

5.1 Fault definitions 12

5.1.1 Modem re-sync fault definition 13

5.1.2 Your tier 1 testing 14

6 PRICING 14

6.1 Monthly rental 14

6.2 Transaction charges 15

6.3 Ancillary charges 15

6.4 Additional services 15

6.5 Tail Extension pricing 15

6.6 Coverage area mapping/remapping charges 15


6.6.1 Coverage area remapping charges 16

7 BILLING 16

8 CONNECTION AND PREMISES NETWORKING 16

8.1 Connection option tasks 17

9 GLOSSARY 19

Appendix A Service levels 22

Appendix B Interface options 23

Appendix C Coverage area and handover point list 25

Appendix D Coverage area maps 27

Appendix E Layer 2 tunnelling protocol 29

Appendix F Unique service identifier 36


1 Introduction

1.1 Who is it for?

Basic UBA allows you to deliver internet-grade broadband services. Basic UBA is an

intermediate input service that you can combine with your network or other services to

provide services to your customers. Basic UBA can be combined with our UBR Backhaul

service.

It’s available nationally where we’ve deployed DSL based technology with terrestrial access

and backhaul assets (i.e. it excludes services supported by satellite and/or wireless access

links or backhaul links).

Basic UBA is provided in accordance with the UBA Standard Terms Determination (STD).

In this document we refer to the Basic UBA delivered over the L2TP network. The Basic UBA

variant EUBA 0 can be found described in the Enhanced UBA product user guide.

1.2 About this document

This documentation has been developed by Chorus. It is intended as a guide line if you

would like to purchase Basic UBA in conjunction with other Chorus services.

1.3 Purpose

This document has been developed to:

Provide details of Basic UBA and its components

Provide you with product, technical and operational information, business rules and prerequisites.

Provide information on how Basic UBA can be used in conjunction with our other input component

services.

1.4 Updates

This product user guide is subject to change from time to time. We’ll update it to reflect

changes as new developments are made. The latest version of this document can be found

on the Basic UBA page of our website.

Any specific technology mentioned in this document is current as at date of issue and is for

guideline purposes only. We reserve the right to adapt the technology employed to deliver

Enhanced UBA.

1.5 Relationship with other documents

This document outlines the operational functioning of Enhanced UBA.


Terms and conditions governing Enhanced UBA are recorded in the UBA STD for regulated

Enhanced UBA and in the Chorus Services Agreement (CSA) between you and us for

commercial Basic UBA.

This document does not constitute an offer by Chorus to provide Basic UBA.

1.6 Intellectual property

Chorus owns all copyright and all other intellectual property rights in this document.

2 Key benefits Ability to offer own branded broadband offerings to the retail market.

Ability to establish total service relationship with your customer.

Layer 2 – internet grade – service that extends the reach of your network beyond the reach of

your current network.

Flexibility to deploy your network assets wherever it makes commercial/engineering sense. You’re

free to choose as few, or as many, handover points as you require.

You can build up a local/regional/national presence to meet your business needs.

3 Product description

3.1 Introduction

Basic UBA provides you with a broadband access service that can be used to provide a

range of own-branded broadband services, including access to the internet.

Typically the service will provide network capability to serve your customers with a single

PC connection, but could support connectivity for multiple networked PCs.

Basic UBA will be available to you exclusively through Chorus.

Basic UBA is a regulated product, subject to a Standard Terms Determination (STD). This

document can be found on the Commerce Commission website – www.comcom.govt.nz.


3.2 Basic UBA components

Figure 1: Basic UBA service with UBR Backhaul

3.2.1 EXTERNAL TERMINATION POINT (ETP)

The ETP is the external termination point for telecommunications services at your customers

premises. Where there is no termination point external to the premises it is either the first

jack on the premises wiring, or the building distribution frame.

3.2.2 BASIC UBA ACCESS

Basic UBA access consists of a DSL data connection from the ETP at your customer’s

premises to the DSLAM at the local exchange or cabinet.

3.2.3 COVERAGE AREA

A coverage area is the collection of DSLAMs in a geographic area connected to a handover

point. More information on Basic UBA coverage is available on the BUBA product page of our

website.

3.2.4 LOCAL AGGREGATION PATH

The traffic from numerous DSLAMs in a coverage area is carried to the handover point over

local aggregation paths.

3.2.5 PARENT HANDOVER POINT

For a particular ATM handover point means one of the associated coverage areas listed in

appendix D that is nominated by you as the parent coverage area to which the UBR

Backhaul S step applies for that ATM handover link.


For a particular Ethernet handover point means one or more of the associated coverage

areas listed in Appendix D that are nominated by you as the parent coverage area(s) to

which the UBR Backhaul S step applies for that Ethernet handover link.

3.2.6 HANDOVER POINT

This is a point within a coverage area where all traffic within that coverage area is

aggregated for handover to you, or backhaul.

3.2.7 HANDOVER LINK

The handover link is an interface between our network and yours. Basic UBA traffic can be

handed over on Gigabit Ethernet or ATM interfaces.

More information can be found in the handover links product user guide on our website.

3.2.8 BACKHAUL

If you don’t have a handover link at the parent handover point you can purchase UBR

Backhaul (Basic UBA Tail Extension) or another backhaul service, which will terminate on a

remote handover point.

3.3 Variants of Basic UBA

Basic UBA supports a set of applications intended for home and home business use. It is a

layer 2 tunnel protocol (L2TP) service that supports a variety of IP connectivity applications.

Basic UBA does not support applications that require real-time network performance or

availability.

Basic UBA is available with a FS/FS speed profile, which is provided under the terms of the

UBA STD.

The FS/FS profile means the maximum speed that the DSLAM can support on the end

customer’s line (whether upstream or downstream).

Actual speeds for both profiles may vary, depending on CPE and wiring, your environment,

volume of traffic, the customer’s location and network congestion.

It can be provided ‘with POTS’, ‘without POTS’, ‘with Baseband IP’ or ‘with Baseband

Copper’.

Without POTS means without an active analogue telephone service on the same copper

pair.

With POTS means with an active analogue telephone service on the same copper pair. The

analogue telephone service is not provided as part of the Basic UBA service and is available

separately from us as an agency.


With Baseband Copper means with Baseband Copper on the same copper pair to the ETP.

Baseband Copper is a copper pair from the ETP to your HDP in the local exchange.

With Baseband IP means with Baseband IP on the same copper pair to the ETP. Baseband

IP is a copper pair from the ETP to where a copper path exists between the end customer’s

ETP and a Chorus DSLAM. At the DSLAM voice frequencies are converted into a bitstream

service and delivered to you on a VLAN at a handover connection at the first data switch.

The Baseband Copper and Baseband IP services are not provided as part of the Basic UBA

service and are as defined in the Baseband service description and product user guide.

3.4 End customer interface

Basic UBA is delivered as PPP over ATM (PPPoA) over a DSL copper interface (ITU-T

G.992.1) to the ETP at the end customer’s premises (or, if appropriate, the building

distribution frame). You must make your own arrangements with your customers for the

purchase and installation of all required CPE and wiring (e.g. DSL modems and in-line

filters) to use the service. It’s your responsibility to ensure that Telepermit requirements are

adhered to.

3.5 Your interface

The service is handed over to you via a handover link. Handover links can be provided by

either us or by you. See the handover links product user guide for additional interface

specifications and setup information.

You must establish a handover link at a minimum of one handover point. A handover link is

required to hand over Basic UBA traffic to you.

A handover link is made up of two parts:

Handover connection - from the handover point to the OFDF in the exchange where the handover

point is located; and

Handover fibre - which runs from the OFDF to your equipment.

The handover link is a single service and includes both the handover connection and the

handover fibre.

For your handover link we provide the handover connection. This connects to the handover

fibre supplied by you, or a third party on your behalf.

Basic UBA traffic can be handed over on STM1, STM4 or Gigabit Ethernet interfaces.

The handover link interface requires the following protocol stack:


Component Detail

IP MTU of 1500 bytes

L2TP L2TP termination per end-customer

All your customers in a coverage area must be mapped to the same LNS

An LNS can support multiple coverage areas, limited by the number of your

customers the LNS can support

IP MTU 1600 bytes

One public IP address per LNS

For ATM: One LNS per handover

For Ethernet: Multiple LNS per handover

Layer 2 ATM

Cell

Ethernet

Jumbo Frames to support L2TP

One shared VLAN for all handover points on the handover link

Physical ATM STM-1

ATM STM-4

GigE

For additional information refer to the handover link product user guide.

3.6 Aggregation of traffic

Each end customer is located in a Basic UBA coverage area. The traffic from numerous

DSLAMs in a coverage area is carried to the handover point over local aggregation paths

dimensioned to support the throughput rate for Basic UBA.

You may, via handover links and/or UBR Backhaul, connect your network to any number of

handover points throughout the country.

Our access network is currently divided into 34 coverage areas. When combined, these

coverage areas provide national coverage of the Chorus DSL network.

The location of handover points and related coverage areas may change in the future.

3.7 IP addressing

You’ll be responsible for your customer’s IP addressing requirements, as well as acquiring

and managing address space for this purpose.


3.8 Interleaving

For each Basic UBA variant ordered you can elect whether that connection will be

provisioned with interleaving on or interleaving off.

The default setting for Basic UBA is to have interleaving turned on.

Data interleaving is used by us on DSL connections to increase the tolerance of line noise.

Your customers can ask you to have interleaving turned off. With interleaving turned off

there may be a reduction in latency, but the service may now be more susceptible to line

noise that may cause your customer to believe your service is faulty. You will bear the

responsibility for evaluating if the fault is attributable to interleaving being turned off, and if

so, for remedying this.

3.9 Geographic availability

Basic UBA is only available where we have ADSL or ADSL2+ coverage and the line speed

meets the minimum rate of 64 Kbps.

3.10 Modem installation

Modem installation is available with a connection and wiring order. The terms relating to

modem installation are set out in the Commerce Commission’s decision, which can be found

on the Commerce Commission website.

In order for us to complete modem installation you will need to ensure your customer has:

A modem available from the approved modem list; and

A single desktop or laptop computer with the operating system required to support the modem.

If the requirements above are in order we’ll organise one of our field services representative

to:

Connect the modem and load the modem driver software

Enter the user ID and password supplied by you and set up your customer’s email account

(Microsoft Outlook, Outlook Express and Mail for Mac 9.0 and above are currently supported)

We can also set up their internet browser and wireless network as specified by you

If the modem does not connect we’ll perform basic fault finding or diagnostics in conjunction with

your helpdesk.

3.10.1 APPROVED MODEM LIST

We will install modems from the approved modem list. It is available on the UBA product

pages of our website.

We have the ability to add modems to this list, to do this please supply:


A telepermitted sample modem

The modem installation and technical manuals (including email and internet browser settings)

Your helpdesk’s contact details

Technical and operational specialists to assist us with drafting operational requirements

4 Ordering

4.1 Prerequisites

The following prerequisites must be in place prior to placing an order for an instance of

Basic UBA:

Copper access at your customer’s premises

You must have an established handover link at the handover point corresponding to your

customer’s coverage area, or have established UBR Backhaul capability from that coverage area

Help desk level 1 support

Authentication, authorisation and accounting (AAA) for end customer servicing if required

Online Order and Tracking capability (OO&T) in place

Online Fault Management capability (OFM) in place

You must provide all necessary IP addressing.

4.2 Basic UBA service requests

You’ll forward an order to us using Online Order and Tracking (OO&T). The order will be

processed and advised as per current processes. Basic UBA will be handed-over to you at

the handover point in your customer’s coverage area, unless UBR Backhaul is requested

from that coverage area.

If you request Basic UBA that cannot be delivered because there is no service coverage this

request will be rejected.

Request types include:

New connection

Transfer

Change plan

Move address

Relinquishment.

4.3 Prequalification

You’ll be able to ascertain whether individual end customer premises are able to be

provisioned with Basic UBA by requesting a pre-qualification check from us.


The purpose of prequalification is to ensure services being ordered for locations can be

delivered so that the service specification targets are met. This not only reduces

unnecessary cost, but will improve the end customer experience by providing a degree of

certainty that a particular service can be delivered.

Prequalification works by analysing the following information:

Technical analysis of recorded cable characteristics based on gauge, length and other factors. This

is translated into an expected dB loss level at 160 kHz.

The minimum specifications for the Enhanced UBA variant.

Exchange/cabinet capability, e.g. does the exchange have ADSL2+ DSLAMs.

The following table shows the maximum attenuation for Basic UBA and the derived

minimum speed:

Service variant Minimum speed up/down Max attenuation

BUBA FS/FS 64 kbps 56.4 dB

Prequalification is based on best knowledge of the line characteristics and is not a guarantee

of success. Factors that may affect the accuracy of a prequalification result include:

Incorrect records. While we use the most accurate information available, occasionally there will be

incomplete or inaccurate information.

House wiring. Some houses have poor wiring characteristics that may be suitable for voice but

have a negative impact on broadband performance, e.g. additional jack-points have been

installed. This impact can be mitigated by installing splitters.

5 Faults

Basic UBA faults must be reported via Online Fault Management (OFM).

We’ll diagnose and repair any faults in the Chorus Network. You’re responsible for diagnosis

and repair of any fault on your customer’s premises and within your own network.

Fault pre-diagnosis must be conducted by you to establish that the fault is not within its

responsibility prior to reporting the fault to us.

For more details please refer to the Premises Networking – assure activities Service

Description.

5.1 Fault definitions


The following fault definitions provide guidance on when a broadband connection is

considered to have a fault. The definitions do not cover all causes of a fault.

5.1.1 MODEM RE-SYNC FAULT DEFINITION

By using the online service performance management tool (eSPM), you can run your own

tests - refer to the line quality diagnosis (LQD).

This is a test on an individual customer line to check the performance (in terms of the modem

synchronisation speeds, noise margin and various other parameters) and stability (the frequency

with which the customer modem spontaneously resynchronises) of the copper line connected to a

DSL port in our access network.

An LQD will show results for 1 or more points in time. Typically these points may be 15 minutes

apart.

The stability, with respect to DSL lines, refers to the frequency with which the customer’s modem

spontaneously resynchronises because of deterioration of the copper line.

For further information on the LQD test please refer to the eSPM user guide.

If the number of spontaneous re-syncs is more than shown in the table below, then a fault

should be logged with our Assure team for further investigation.

You can, of course, opt to request a self-service truck roll via OFM to by-pass the Assure team

investigation process.

If the number of re-syncs is less than the number shown in the table below, you should

advise your customer that the there is no apparent fault with the network and your service

is performing satisfactorily.

LQD Test Length LQD Spontaneous Resyncs

24 Hours ≥ 10

12 Hours ≥ 6

6 Hours ≥ 4

2 Hours ≥ 3

There could still be issues with the network that multiple customers could experience when

the modem re-sync are less than 10 in a 24 hour period. (e.g. Power feeding into DSLAM).

The following is recommended for end customer service testing by the customer during tier

1 support process before a fault is logged:

1. Isolate any environment factors where possible that may have caused the modem

to re-sync (e.g. modem has close proximity with other electronic equipment

causing frequency interference)


2. Is there any ‘cluster’ pattern during certain periods of the day that the modem re-

syncs more than other times of the day?

5.1.2 YOUR TIER 1 TESTING

The following is recommended for end customer service testing during tier 1 support

process, before a fault is logged:

1. Ask your customer to perform a minimum of 4 tests within a 48 hour period

(www.speedtest.net)

2. Only 1 PC connected

3. Connected via Ethernet or USB is preferable. (if using wireless, make sure wireless

connection is working and running properly)

4. Any peer to peer (P2P) or FTP programs are not running at the time of the speed

test being performed which may slow down the results

5. Your customer’s PC has been checked re firewalls/virus/or other malicious

software.

1. Normal CPE checks to be performed. e.g. reset router, router not plugged into an

external lead back to the jackpoint

2. Has your customer exceeded their pre-set download limit, where your customer

experience is limited to dial up speed.

3. Test to be performed at different time of the day (peak 6pm to midnight vs. off

peak)

4. Trace routes to local New Zealand servers

5. Check the line via eSPM and make sure the customer’s connect rates are normal

6. To log a fault for low data throughput, you must provide evidence that the above

Tier 1 tests have been carried out and supply the associated test results for

investigation.

6 Pricing

The following list details the Basic UBA price components. For more detail please refer to the

UBA STD.

6.1 Monthly rental

Basic UBA with POTS

Basic UBA with Baseband Copper

Basic UBA without POTS urban

Basic UBA without POTS non urban

Access seeker handover connection (STM1, STM4 or GigE)

Chorus handover link (STM1, STM4 or GigE)

Handover fibre space rental.


6.2 Transaction charges

Connection

Connection & wiring

Wiring only

Modem installation

Access seeker handover connection installation

Chorus handover link installation

Handover fibre installation

Transfer

Exception to BAU order

Multiple order for single end customer

Relinquishment

Move address

Relinquishment of access seeker handover connection

Coverage area mapping and re-mapping (design charge and charge per end customer).

Change plan

(changes between with POTS, without POTs, with Baseband Copper, with Baseband IP)

6.3 Ancillary charges

Special manual pre-qualification

No fault found

Abortive End customer site visit

Cancellation of exception to BAU order

Cancellation of order

A pre-truck roll cancellation charge applies to orders cancelled before a truck roll is

confirmed i.e. before 3:00pm on the day before the RFS date.

A post-truck roll cancellation charge applies to orders cancelled after a truck roll is

confirmed i.e. after 3:00pm on the day before the RFS date.

6.4 Additional services

In addition, backhaul and handover link charges will apply.

6.5 Tail Extension pricing

Tail Extension monthly rental charge is charged on a per Basic UBA access tail basis and is

in addition to the Basic UBA access tail monthly rental charge.

6.6 Coverage area mapping/remapping charges


There is no charge for setting up coverage area mapping when you’re setting up consume

Basic UBA, or when mapping is required when we add coverage areas to Basic UBA.

6.6.1 COVERAGE AREA REMAPPING CHARGES

There are two remapping charges that are applied when you request your coverage area

mapping be changed:

Remapping design charge - for the design plan to reconfigure the affected network elements to

map to the new handover point. Basis for determining the charge is the estimated equipment,

time and materials incurred to design and implement a remapping including network rebuild

design and network changes

Access remapping fee - changes to each Enhanced UBA service connection to correctly map and

charge for the new handover point. This is a per end customer charge as the size of the

remapping work is directly related to the number your customers. Therefore the charge reflects

the cost to map each end customer.

These charges are applied by the service delivery manager once the remapping has been

completed and are detailed in the CSA price list.

7 Billing

Basic UBA will be billed as a wholesale service as per existing services currently offered to

you by Chorus. Where the provision for electronic billing exists, the billing details for Basic

UBA will be presented on your electronic bill.

8 Connection and Premises Networking

There are four options for UBA installation:

1. Connection only – we provide connection to the ETP with no site visit. A

Telepermitted line filter (PTC 280-series) must be fitted on the network side of all

POTS CPE (not the DSL modem). This includes any medical or security alarm

systems and SKY Digital decoders (which incorporate a dial-up modem) that are

plugged into jack points.

2. Connection and wiring – a service technician will visit your customer’s premises. If

required they will install a splitter and premises wiring to a single jackpoint or

isolate the premises from our network. Connection and wiring is needed where

medical or security alarm systems are already connected to the line in ‘line break-

in mode’, or where more than 5 line filters would be required.


3. Connection and wiring with modem installation – we provide connection and

wiring in accordance with the description above and the service technician will

install a service compatible modem provided by you from the approved modem

list.

4. Wiring only – where you’ve requested connection only, however subsequent wiring

work to be done as described in connection and wiring.

For more details please refer to the Premises Networking – broadband installation options

Service Description.

8.1 Connection option tasks

Tasks carried out

as required for each

connection option

Connection

only

Connection

and wiring

Connection

and wiring

with

modem

installation

Wiring only

Confirm that correct

POTS and DSLAM ports

are allocated

Break down any intacts

Rearrange pair gain your

customers

Provide ADSL jumper to

existing POTS/Baseband

Run any other jumpers

Install / connect

POTS/Baseband if

associated

Conduct functional tests

of POTS/Baseband

Conduct functional tests

of ADSL

Connect wiring in ETP

and install low pass

splitter

Install jack point for

broadband and any

premises wiring

Convert any 3-wire systems


to 2-wire systems*

Confirm PC meets

minimum requirements

Install and configure

broadband modem

Install and configure

Ethernet adapter to PC

Install and configure WiFi

devices

Set up of WiFi security

Install and configure web

browser and email client

Resolve any hardware or

software conflicts

Train end-customer

The list of tasks for each option is undertaken ‘as required’ for each end customer premises.

There is no change in the charge for the service if not all of the tasks are required.


9 Glossary

Term Definition

AAA Authentication, authorisation and accounting.

AAL5 ATM adaption layer 5.

ADSL Asymmetric digital subscriber line.

ATM Asynchronous transfer mode.

Basic UBA Basic Unbundled Bitstream Access.

Basic UBA access The portion of the Basic UBA service between the ETP and the

DSLAM.

Bitstream Transmission of character stream (i.e. a Data Stream, not a

transmission protocol).

BRAS Broadband remote access server.

Business voice

access service

A retailed or resold business access (POTS) line or standard

Centrex line. Business voice access service does not include

ISDN or ISDN Centrex.

CPE Customer premises equipment.

Coverage area The geographic area serviced by a given handover point and will

contain numerous DSLAMs.

DSL Rate adaptive asymmetric digital subscriber line. In relation to

Basic UBA, DSL does not include other forms of digital

subscriber lines such as SHDSL.

DSLAM Digital subscriber line access multiplexer.

End-customer The ultimate recipient of a service (or of another service whose

provision is dependent on that service); or one of our customers

(excluding you and other service providers), as the context

requires.

ETP External termination point.

FTP File transfer protocol.

Handover

connection

Part of the handover link from the handover point to the OFDF in

the handover point exchange.

Handover fibre Part of the handover link from the OFDF in the handover point

exchange to your OFDF.

Handover link A connection between the handover point and your point of

presence used for the purpose of handing over Basic UBA traffic.


Handover point This is a point where all traffic for a coverage area is aggregated

for handover to you, or backhaul. The list of Ethernet and ATM

handover points are in the UBR Backhaul product user guide.

Also called a USAP.

IP Internet protocol.

ISP Internet service provider/you.

ITU International Telecommunications Union.

Kbps Kilobits per second.

L2TP Layer 2 tunneling protocol (RFC2661).

Local

aggregation path

(LAP)

The local aggregation path aggregates all service traffic between

the DSLAM and the first Ethernet aggregation switch. The LAP is

shared by all service providers with Basic UBA customers

connected to the DSLAM; the LAP is also shared by Basic UBA

with other services that use the DSLAM. The physical connection

is a Gigabit Ethernet.

LAC L2TP access concentrator – a function provided by the BRAS.

Latency A term variously used to define the time delay for data to pass

through a network.

Layer 2 The data layer of the OSI model.

LCP Link control protocol (see PPP).

LLC Logic link control (IEEE 802.2).

LNS L2TP network server.

MAC Moves, adds or changes.

Mbps Megabits per second.

Metro Within a designated metropolitan area.

MRU Maximum receive unit.

MTU Maximum transmit unit.

NNI Network to network interface.

OFDF Optical fibre distribution frame

PAP Password authentication protocol.

Parent coverage

area

One of the coverage areas associated with a handover point

listed in Appendix D that is nominated by you as the parent

coverage area to which the UBR Backhaul S step applies for that

handover link.

Parent handover The handover point for the parent coverage area.


point

PCR Peak cell rate.

PDN Public data network.

POI Point of interconnect

POP Point of presence

POTS Plain old telephony system.

PPP Point to point protocol (RFC1661).

PTC Permit to connect documents published at

http://www.telepermit.co.nz/.

RADIUS Remote authentication dial-in user service.

Realm The part of a username after the @ symbol.

Regional Within a designated regional area.

SDH Synchronous digital hierarchy.

You/service

provider

A Chorus customer with a Chorus Services Agreement.

SNAP Sub network access protocol (RFC1042).

STM Synchronous transfer method.

UBA STD The Commerce Commissions Standard Terms Determination for

the designated service Chorus’ unbundled bitstream access –

Decision 611

UBR Unspecified bit rate.

UDP User datagram protocol (RFC768).

UNI User network interface.

Unique service

identifier

The unique service identifier described in Appendix VI

URSA Basic UBA regional service area.

Also called a coverage area.

USAP Unbundled service aggregation point.

Also called a handover point.

VPN Virtual private network. The use of a public (i.e. PSTN or

internet) network infrastructure to create private connections.

Voice access

service

Residential voice access service or business voice access

service.


Appendix A Service levels

A.1.1 Service specifications

The table below outlines the target service specification for Basic UBA:

Metric Specification

Throughput 99.9% probability of providing to any

provisioned end-customer a minimum downlink

average throughput of 32kbps during any 15

minute period on demand

Mean packet transfer delay (one

way for 1500 byte packet)

< 1 sec

Delay variation (one way) Unspecified

Packet loss Unspecified

For the avoidance of doubt the average throughput of 32kbps is used to dimension the size

of the handover connection at an aggregate level, i.e. the size of the handover connection

equals the number of your customers x 32kbps.

A.1.2 Service level agreement

Please refer to schedule 3 of the UBA STD for service targets relating to the regulated Basic

UBA service.


Appendix B Interface options

B.1.1 Your requirements

A handover link in each coverage area where Basic UBA Access is required (unless UBR Backhaul

service is purchased).

For an ATM handover link an ATM 155Mb/s or 622Mb/s interface to support the ATM PVC carrying

Basic UBA traffic. Egress traffic should be placed below the PCR of the backhaul PVC to prevent

cell discard. The PCR will be specified by Chorus. AAL5 Encapsulation (VCMux) will be used for the

interconnection.

For an Ethernet handover link a 1 GigE interface to support the VLAN carrying the Basic UBA

traffic. Egress traffic should be placed below the VLAN CIR, as specified by Chorus according to

provisioning forecasts, to prevent frame discard.

An L2TP network server (LNS) supporting IPv4.

AAA (RADIUS) servers are required if authentication of Basic UBA subscribers is desired (Note: no

proxy authentication occurs within the Chorus network).

You must route traffic to the originating BRAS out the same interface the traffic was received on.

Firewall filters will prevent traffic on ingress when the handover point is not nominated for the

specific tunnel-server-endpoint.

At each handover point there must be a unique tunnel endpoint (IP address) provided by you. The

tunnel endpoint must be a globally unique internet address, not RFC1918 address space. We’ll add

a corresponding static route (/32) for the LNS with next-hop down the POI interface.

Ethernet handovers will support multiple tunnel endpoint IP addresses, each of which must be a

globally unique internet address.

You must not permit internet traffic ingress into our network. Any non-L2TP traffic will be

discarded.

B.1.2 End customer equipment requirements

B.1.3 DSL modem

A DSL modem conforming to ITU-T G.992.1 (G.dmt).

All DSL modems must carry a valid Telepermit before they can be connected to our network.

A list of Telepermitted modems is available at www.telepermit.co.nz.

B.1.4 Modem setup instructions

Operating mode set to G.992.1, G.DMT or ANSI T1.413 is 2 but not G.Lite or G.992.2.

VPI/VCI set to 0/100.

Protocol set to PPP over ATM (PPPoA) (RFC 2364) with VC multiplexed encapsulation.

If authentication is used the username and password set to the user ID that the end customer is

trying to connect to. The username must be set to ‘user ID’ followed by an ‘@’ symbol followed by

‘domain name’ e.g. [email protected]

The ‘username@domain name’ string is validated only to the extent that it is in the correct

format. No further validation or authentication takes place within our network. You’re

responsible for all end customer authentications.


The end customer should be supplied with instructions as to how they can change this

username string without altering other settings. Any other application layer proxy, firewall

or other functionality within the modem that your customers intend to use must be included

in manufacturers' instructions or be supported by you.

We don’t provide support for any additional functionality built into the ADSL modem.

The DSL modem should be configured as follows:

B.1.5 Filters

If DSL filters are to be used, your customers must install these on each and every jack point

in the premises to which a voice-band device is connected.

This includes: phones, faxes, analogue modems, cordless phones, monitored

medical/security alarm systems, Sky Digital decoders.

A single device that is not filtered can adversely affect an end customer’s Basic UBA.

DSL Parameters

Operational mode G.dmt Annex A

Maximum bits per tone upstream 13

ATM parameters

ATM service category BACKHAUL

Encapsulation PPP over AAL5 (RFC 2364)

AAL5 VC-Mux

ATM VPI.VCI 0.100

PPP parameters

PPP compression (LCP PCOMP) Off

PPP address & control field compression

(LCP ACCOMP)

Off

Magic number Enabled

MRU As appropriate (1500B for Ethernet)*

Authentication protocol PAP

Multilink PPP Controlled by service providers and LNS


Appendix C Coverage area and handover point list

No Coverage area

name

ATM handover point Ethernet

handover point

1 Northland Airedale St 2 Whangarei 1

2 North Auckland Mayoral Drive 1 Mayoral Drive 1

3 East Coast Bays Glenfield 1 Glenfield 1

4 North Shore Mayoral Drive 2 Mayoral Drive 2

5 Hobsonville Mayoral Drive 3 Mayoral Drive 3

6 West Auckland Mayoral Drive 4 Mayoral Drive 4

7 Hillsborough Papatoetoe 3 Papatoetoe 3

8 Grey Lynn Mount Albert 1 Mayoral Drive 5

9 Auckland Central Airedale St 1 Mayoral Drive 6

10 Grafton Airedale St 3 Mayoral Drive 7

11 Tamaki Ellerslie 1 Papatoetoe 4

12 South Auckland Papatoetoe 1 Papatoetoe 1

13 Eastern Suburbs Otahuhu 1 Papatoetoe 5

14 Counties Papatoetoe 2 Papatoetoe 2

15 North Waikato/

Coromandel

Hamilton 1 Hamilton 1

16 Hamilton Hamilton 2 Hamilton 2

17 Tauranga Tauranga 1 Tauranga 1

18 Bay of Plenty/ East

Coast

Rotorua 1 Rotorua 1

19 Central Palmerston North 2 Palmerston North 2

20 Taranaki New Plymouth 1 New Plymouth 1

21 Hawkes Bay Napier 1 Napier 1

22 Manawatu Palmerston North 1 Palmerston North 1

23 Hutt/Wairarapa Lower Hutt 1 Porirua

24 Wellington Suburbs Porirua 1 Porirua 1

25 Wellington Central Wellington 1 Wellington 1

26 Nelson Nelson 1 Nelson 1

27 Marlborough/North

Canterbury

Courtenay Place Wellington 3


28 West Coast Wellington 2 Wellington 2

29 Christchurch North Christchurch 3 Christchurch 3

30 Banks Riccarton 1 Riccarton 1

31 Christchurch Central Christchurch 1 Christchurch 1

32 South Canterbury Christchurch 2 Christchurch 2

33 Otago Dunedin 2 Dunedin 2

34 Southland Dunedin 1 Dunedin 1


Appendix D Coverage area maps

D.1 Basic UBA coverage areas

D.2 Basic UBA coverage areas


Appendix E Layer 2 tunnelling protocol

E.1 L2TP tunnel termination requirements

The protocol delivery is L2TP over UDP over IP over ATM or Ethernet. You’ll need to

terminate multiple LT2P tunnels (i.e. will require multiple LNS instances), with a minimum

of at least one L2TP tunnel per handover point served. You’re responsible for authentication

of users.

Your L2TP tunnel terminator must be capable of terminating at least 200 unique L2TP

tunnels. The tunnel terminator must be sized to handle the number of L2TP connected

users, where each user necessitates an LNS session. The L2TP network server (LNS) must

support IPv4.

A unique L2TP tunnel is used per coverage area and a single coverage area may span

multiple LACs.

At least one unique tunnel-server-endpoint (single IP address) is required per handover link,

appreciating that a tunnel-server-endpoint determines where traffic will be routed across

our network (and delivered to the appropriate handover point). A single tunnel-server-

endpoint is required per handover point (needs to be unique per handover link).

The tunnel-server-endpoint IP address must be a globally unique internet address allocated

by APNIC (or similar RIR) to you (i.e. not RFC1918 address space). A /30 linknet will be

provided by us across the handover link interface.

You must route traffic to the originating LAC out the same interface the traffic was received

on. Firewall filters will prevent traffic on ingress when the handover link is not nominated for

the specific tunnel-server-endpoint.

An AAA (RADIUS) server is required if authentication of Basic UBA subscribers is desired by

you.

E.2 Layer 2 tunnelling protocol implementation

L2TP, or Layer 2 tunnelling protocol, allows individual PPP frames to be transported over an

IP network. This allows the PPP session to be terminated away from the initial aggregation

point.

For Basic UBA, L2TP transports subscribers PPP frames from the L2TP access concentrator

(LAC) to your L2TP network server (LNS). This allows you to control LCP and NCP as well as

to have delivered an authenticated, logical interface on which profiles can be applied.

There are two fundamental concepts in L2TP: the tunnel; and the session. The L2TP tunnel

is managed by control connections between the LAC and LNS and is uniquely identified in

each session.


The L2TP session is the term for an individual PPP connection.

One L2TP tunnel can support many L2TP sessions.

L2TP uses UDP for all communications between LAC and LNS (noting that control traffic is

reliable by the nature of the exchange). If an L2TP packet is lost in transit it may be

detected through the use of optional sequence numbers, but they are not used to resend

the packet. The full responsibility of retransmitting the packet lies with the protocol

encapsulated by L2TP. Chorus Basic UBA implementation does not use sequence numbers.

L2TP takes the PPP PDU and encapsulates it within L2TP, UDP and finally IP.

Figure VII-3: Layer 2 tunnelling protocol implementation

This has the impact of adding around 38B to a typical IP datagram of between 20 and

1500B. This additional overhead requires that the MTU of a link carrying the L2TP traffic is

an additional 38B greater that the largest IP datagram processed by a subscribers. Both

Ethernet II and IEEE 802.3 has a maximum data field of 1500B, meaning that the maximum

size of the subscribers IP datagram must not exceed 1462B. This limitation is not as

prevalent on ATM networks because the default IP MTU on ATM AAL5 is 9180B.

We’ll set the MTU to 1600B on all ATM connections for Basic UBA and require you to support

such a configuration.

You must expect IP datagrams to arrive of at least 1538B.

E.3 Information Exchange

When an L2TP tunnel/session is established with you, certain attributes are passed between

LAC and LNS. Some of these attributes can be used to establish details on the subscriber.

For security reasons, some of these attributes are considered ‘hidden’, using an MD5 XOR

derived from the tunnel-password.

At time of tunnel-establishment, the following attributes are learnt by the LNS:

LAC hostname

LAC vendor


Tunnel-ID

Challenge/response (tunnel-authentication/tunnel-password)

At time of session-establishment, the following attributes are learnt by the LNS:

Session ID

Calling number

Called number

Initial received LCP CONFREQ

Last received LCP CONFREQ

Last sent LCP CONFREQ

Proxy authentication name

Proxy authentication ID

Proxy authentication response.

These fields will be formatted as follows:

E.3.1 Tunnel-password

The tunnel-password parameter is used as the ‘secret’ during L2TP [RFC 2661] tunnel

establishment and for the hiding of sensitive AVP in the L2TP control connection. The secret

is based on CHAP [RFC 1994] which is simply an MD5-based authentication algorithm.

For the purposes of our implementation, the tunnel-password is a ASCII string of between 1

and 16 characters made up of the characters from ASCII 48-57 [‘0’-’9’], 65-90 [‘A’-’Z’] and

97-122 [‘a’-’z’]. The tunnel-password is case sensitive.

Tunnel-password examples include:

pAssw0rd

tunnelPassword12

hYh26xU82kj

E.3.2 LAC hostname

The LAC hostname is defined in RFC 2661. Host name (Attribute Type 7). It should be noted

that a single IP source address may advertise more than one hostname. This is because

each hostname will represent a different tunnel.

TCNZ-WN-RAN-11

E.3.3 Calling number

The calling number AVP is defined in RFC 2661 as attribute type 22 - this encodes an

undefined length ASCII string commonly used to represent the RADIUS AVP calling-station-

ID.

The calling number attribute will be encoded to provide granular detail about the

subscribers. This will include:


Serving DSLAM

LAC interface

VCI

Changes will be notified in accordance with the unique service identifier process.

atm 4/0.2700110:27.110#184549418#JETBasic UBA JV-DSLAM-02 U024#speed:UBR#

E.3.4 Basic UBA establishment

Tunnels will be established by the lac when an incoming call is detected for the appropriate

tunnel-server-endpoint provided the tunnel doesn’t exist. By using the tunnel-client-auth-ID

attribute in RADIUS, we will direct particular sessions down specific tunnels (related to the

coverage area to which the customer is associated) and more importantly: updates the

hostname provided to the remote LNS.

E.3.5 Session teardown

Sessions will be automatically disconnected at the request of the LNS. The LAC itself has no

control over the PPP going through it, so the control lies with you.

E.3.6 Tunnel teardown

L2TP tunnels have been configured to remain established for up to 5 minutes after the last

session has disconnected before the tunnel will terminate. This is to prevent unused tunnels

consuming resource, and on the other hand preventing tunnels consuming CPU in your

continual re-establishment.

E.4 Authentication, authorisation and accounting

E.4.1 Multi-stage authentication

We’ll be adopting a method of compulsory L2TP tunneling based on RADIUS not unlike

‘4.1.2.3 user name authentication’ described in RFC 2809. Because e-series sub interface

assignments are static, the NAS-port is used in place of calling/called-station-ID to

authorise users and create the appropriate tunnel. Although NAS-port is the method used to

identify the tunnel, the nature of authentication on the e-series requires LCP to negotiate

PAP and a username and password to be passed to the rate-limit proxies. Because LCP has

already been negotiated by the LAC, you may optionally choose to renegotiate LCP although

this is not necessary in many cases because the e-series support proxy authentication and

will pass LCP CONFREQ details at time of session establishment.

E.4.2 Authentication protocols

RADIUS authentication will only begin when a username is sent, it is a requirement that you

configure subscribers to support PAP and require authentication for PPP (for initial LCP


exchange). No other authentication protocols (such as CHAP) are currently supported by

Basic UBA.

To protect the integrity of the username/password pair, AVP hiding will be enabled on the

L2TP control connection. AVP hiding is defined in RFC 2661.

E.4.3 Subscriber authentication

Authentication of individual subscribers will be your responsibility. Because any

username/password provided by a subscribers will result in an incoming-call-request

(ICRQ), you should implement RADIUS authentication using either proxy authentication

attributes or after renegotiating LCP. We suggest that you implement both - to allow for all

modem types that are currently available in the New Zealand market.

The sequence of events is:


Figure VII-4: Subscriber authentication sequence

E.5 Testing requirements

For testing purposes ICMP ping must be passed by both Chorus and you to allow continuity

testing of the tunnel endpoints.

You should allow the following ports/protocols between POI and LNS.

Ingress (from POI)

Name Source IP Source port Destination Destinatio

n port

L2TP

establishment

LAC Any UDP LNS UDP 1701

L2TP tunnel LAC Any UDP LNS Any UDP

ICMP echo

request

LAC

Remote Linknet

interface

ICMP Type 8

Code 0

LNS

Local Linknet

interface

ICMP type

8

code 0

ICMP echo

reply

LAC

Remote Linknet

interface

ICMP Type 0

Code 0

LNS

Local Linknet

interface

ICMP type

0

code 0

ICMP

destination

unreachable

LAC

Remote Linknet

interface

ICMP Type 3

Codes 0-5

LNS

Local Linknet

interface

ICMP type

0

code 0

ICMP TTL

exceeded

LAC

Remote Linknet

interface

ICMP Type

11 Code 0

LNS

Local Linknet

interface

ICMP type

11

code 0

UDP

Traceroute*

LAC

Remote Linknet

interface

Any UDP LNS

Local Linknet

interface

UDP 33434

incrementin

g per

packet

Note: Traceroute is implementation specific. Many can be made to use ICMP ping for

compatibility.


Egress (to POI)

Name Source IP Source Port Destination Destination

Port

L2TP Tunnel LNS Any UDP LAC Any UDP

ICMP echo

request

LNS

Local Linknet

interface

ICMP Type 8

Code 0

LAC

Remote Linknet

interface

ICMP type 8

code 0

ICMP echo

reply

LNS

Local Linknet

interface

ICMP Type 0

Code 0

LAC

Remote Linknet

interface

ICMP type 0

code 0

ICMP

destination

unreachable

LNS

Local Linknet

interface

ICMP Type 3

Codes 0-5

LAC

Remote Linknet

interface

ICMP type 0

code 0

ICMP TTL

exceeded

LNS

Local Linknet

interface

ICMP Type 11

Code 0

LAC

Remote Linknet

interface

ICMP type 11

code 0

UDP

traceroute*

LAC

Remote Linknet

interface

Any UDP LNS

Local Linknet

interface

UDP 33434

incrementing per

packet

Note: Traceroute is implementation specific. Many can be made to use ICMP Ping for

compatibility.

E.6 IP addressing requirements

A single tunnel-server-endpoint (single IP address) is allowed per ATM handover point.

Ethernet handovers, with increased bandwidth, can support multiple tunnel server endpoints

(although each handover point can only connect to one). A tunnel-server-endpoint

determines where traffic will be routed across our network and delivered to the appropriate

handover point.

The tunnel-server-endpoint IP address must be a globally unique internet address allocated

by the likes of APNIC or another RIR to you. i.e. not RFC1918 address space. A /30 linknet

will be provided by Chorus across the handover ATM interface. This will use RFC1918

address space.

You must route traffic to the originating LAC(s) out the same interface the traffic was

received on. Firewall filters will prevent traffic on ingress when the handover point is not

nominated for the specific tunnel-server-endpoint. The current LAC subnet address ranges

are 222.152.127.32/28 and 222.152.43.0/26.

A RADIUS server is required if authentication of Basic UBA subscribers as desired by you.


Appendix F Unique service identifier

F.1 Introduction

The unique service identifier can be used to uniquely identify the end customer, irrespective

of information submitted by that end customer, and thus can be used for verification. It is

not a replacement for the ASID which is the UBA service identifier for provisioning and

billing.

The unique service identifier is a combination of two identifiers:

The BRAS (LAC) name/identifier

The BRAS (LAC) interface (slot/port) and sub-interface.

These identifiers correlate to a physical DSLAM port and therefore an individual ADSL connection.

In Basic UBA:

The BRAS name is contained in the L2TP field host name (attribute 7).

The BRAS interface and sub-interface details are encoded in the L2TP field calling number

(attribute 22).

These attributes are learned by your LNS at the time of L2TP tunnel and session set up.

F.2 Host name description

The host name supplied will be the LAC host name configured in the LAC. An example host

name is 'WN-RAN-21'.

F.3 Calling number description

We use the Juniper ERX-1410 as the LAC for the delivery of Basic UBA. These routers are

configured to generate the L2TP calling number field as follows:

<interface ID> <delimit> <UID> <delimit> <interface description> <delimit> <connect

info> <delimit> <PPPoE description>

The Basic UBA product footprint encapsulates both ATM-based and Ethernet-based access

networks, and as a result the contents of the L2TP calling number field differ slightly

between Ethernet and ATM delivery as detailed below.

Each field contains:

Delimiter - The delimiter is used to separate one sub-field in this string from another. The

delimiter that we use is a hash (#).

Interface ID - The interface ID contains both the BRAS (LAC) interface and sub-interface. This is

the unique identifier. A breakdown of how this field is generated is contained in the interface ID

detailed description below.

UID - The UID field is an internal Juniper identifier that cannot be relied upon to be either unique

or static.


Interface description - contains information relating to the 7450 EAS interface. This field is

blank for an ATM-based end customer.

Connect info - information relating to the L2TP connection. This field is blank for an Ethernet-

based end customer.

PPPoE description - contains the MAC address of the external interface card on the ISAM. This

field is not included for an ATM-based end customer.

For an Ethernet end customer (i.e. an end customer based off an Alcatel ISAM) an example

of calling number is:

GigabitEthernet 8/0.520333:52-333#587228804#INFA290560:WN-RAN-21 to

WN-ETH51 port 1/2/1##pppoe 00:07:72:1c:fe:a9#

For an ATM end customer (i.e. an end customer based off an Alcatel ASAM, Nokia DSLAM or

Conklin Mini-DSLAM) an example of calling number is:

atm 3/0.7200211:72.211#184556082##speed:UBR#

You’ll only require the interface ID to uniquely identify an end customer on the LAC, and we

make no guarantees that the remainder of the field will not be subject to modification.

Therefore, you should ignore all attributes after the first delimiter (#).

F.4 Interface ID detailed description

The interface ID is similar, but not identical for ATM and Ethernet-based end customer

connections. Therefore this section will describe them individually.

Ethernet end customer connections:

Format: <interface type><space><physical slot>/<physical port>.<sub-interface>:<SVLAN>-

<CVLAN>

Interface type: This will always be Gigabit Ethernet.

Physical slot: The Physical slot on the ERX-1410 that the ISAM traffic is routed to

Physical port: For the ERX-1410 this will always be zero (0).

Sub-interface: This is a variable length field dependant on the VLAN the end customer is

provisioned on. This is the SVLAN (2-4094) followed by the CVLAN where the CVLAN is always

four characters. If the CVLAN is less than four characters, zeros are used to pad the value e.g.:

For SVLAN=52 and CVLAN=333, the sub-interface will be 520333

For SVLAN=152 and CVLAN=333, the sub-interface will be 1520333

SVLAN: The end customer’s SVLAN

CVLAN: The end customer’s CVLAN

ATM end customer connections

Format: <interface type><space><physical slot>/<physical port>.<sub-

interface>:<VPI>.<VCI>

Interface type: This will always be ATM.

Physical slot: The physical slot on the ERX-1410 that the DSLAM traffic is routed to.


Physical port: For the ERX-1410 this will always be zero (0).

Sub-interface: This is a variable length field dependant on the VPI/VCI the end customer is

provisioned on. This is the VPI (16-255) followed by the VCI where the VCI is always five

characters. If the VCI is less than five characters, zeros are used to pad the value e.g.:

For VPI=72 and VCI=211, the sub-interface will be 7200211

For VPI =152 and VCI=32, the sub-interface will be 15200032

VPI: The end customer’s VPI

VCI: The end customer’s VCI

F.5 How you could use the unique service ID

The L2TP attributes that contain the unique service identifier (host name and calling

number) should be available to you to use as desired. An example of how this could be used

is to include the unique identifiers in any RADIUS messages to facilitate AAA. The

mechanism to achieve this may differ depending on your equipment.

For example, a Juniper E-series router (acting as an LNS) encodes the appropriate L2TP

attributes as follows:

The calling number is inserted into radius attribute 31 – Calling-Station-ID

the host name is inserted into radius attribute 90 – Tunnel-Client-Auth-ID

F.6 Provisioning

All Basic UBA requests will include the unique service identifier returned by OO&T.

OO&T will present service details to you, including the UBA ASID and unique service

identifier (LAC Name, and LAC ID).

For the following OO&T order types:

New connection

Transition

Move address

This information will be available when the OO&T order reaches the following order states:

RFS date confirmed;

Service given;

Order complete.

For the following OO&T order types:

Change plan (EUBA to BUBA);

This information will be available when the OO&T order reaches the following order states:

Service given;

Order complete.


F.7 Assure

F.7.1 Unplanned outages

When a port is changed via the assure process, the unique service identifier details will be

advised via the OFM problem report.

The faulty port process will be enhanced, resulting in a You notification of the port change,

including the ASID and the new unique service ID (LAC Name, and LAC ID) via your OO&T

notification queue.

Port change notifications added to your notification queue will be available to you via the

OO&T portal or OO&T B2B.

F.7.2 Planned outages - cabinetisation process

The cabinetisation process involves the migration of services from an exchange to a cabinet.

As a result of cabinetisation the unique service identifier (LAC Name and LAC ID) changes.

The cabinetisation process supplies service details to our service delivery managers - details

will include the old and new unique service ID (LAC ID and LAC name). These will be

distributed to you.

F.7.3 Planned outages - BRAS re-hosting process

The BRAS re-hosting process involves the migration of one or more DSLAMS from one BRAS

to another. As a result of BRAS re-hosting the unique service identifier (LAC Name and LAC

ID) changes, the BRAS re-hosting process will generate a BRAS re-host report to notify our

service delivery managers 7 days in advance of the migration. The report will contain the

old and new unique service ID (i.e. LAC name and LAC ID). These will be distributed to you.

F.7.4 Service performance management (SPM) tool

This tool will allow on demand retrieval of the unique service identifier (i.e. LAC ID and LAC

name) as part of a diagnostics test. SPM can be accessed via the Chorus Gateway

(http://gateway.chorus.co.nz) or visit the Tools and Resources section on our website.

The table of contents is automatically generated and is based on the styles used throughout

the document.

To refresh the table of contents (to update it) by:

1. Selecting the table of contents box

2. Selecting the dropdown arrow

3. Selecting ‘update table of contents’ (it might say ‘update table…’

4. Then select ‘entire table’


If you don’t need the table of content follow steps 1 & 2 then select ‘Remove table of

contents’.

Basic UBA Product User Guide

Documents

Transcript of Basic UBA Product User Guide