Operations and Support Manual for Local and Mobile Number Portability in New Zealand

Transcription

1 New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr Lcal and Mbile Number Prtability in New Zealand Versin Number and Status: ENDORSED Versin Date: 11 February 2015 This dcument frms part f the regulatin fr Number Prtability and is enfrceable thrugh the IPMS Access Agreement The New Zealand Telecmmunicatins Frum Inc. All rights reserved. Cpyright in the material cntained in this dcument belngs t the New Zealand Telecmmunicatins Frum Inc. N part f the material may be reprduced r published fr any purpse and by any means, including electrnic, phtcpying, recrding r therwise, withut the New Zealand Telecmmunicatins Frum Inc written cnsent. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 1 f 127

2 Table Of Cntents Quick Start Guide... 3 Explanatry Statement... 4 Backgrund... 4 Change Cntrl Prcess... 6 Definitins and Interpretatin... 9 Overview f the IPMS Envirnment Security f IPMS Cde f Cnduct Resellers Prting Prcess Special Prjects Service Level Expectatins and Operating Hurs Agency & Special Services Requirements (Emergency Services) Custmer Fault Handling and Testing Prcedures Prting Cntact and Escalatin Pints IPMS Fault Management Capacity Frecasting Prcedures New Participants Prcedures Enfrcement Agency Prcedures Issues Escalatin System and Netwrk Outages Call Readdress Appendix A. Bilateral Agreement Check List Appendix B. IPMS Management Appendix C. Change Request Frm Appendix D. IPMS Parameter Change Frm Appendix E. API Errr Messages Appendix F. Service Level Explanatry Ntes Appendix G. Extract frm TCF Custmer Transfer Cde Appendix H. LMNP - New Entrants and Ptential New Entrant Guidelines Appendix I. Special Prjects Uplad File Structure Appendix J. IPMS Flw Diagram Appendix K. Table 2: Service Levels Appendix L. Accunt Number Lengths and Type Appendix M. QBNR Entries in TEST and DEV Appendix N. Security Plicies fr IPMS New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 2 f 127

3 Quick Start Guide The Number Prtability User Grup (NPUG) has identified the fllwing items f particular imprtance that cause cnfusin r can create delays in the prting prcess if they are nt well knwn and understd. Thugh IPMS users shuld be aware f all aspects f Number Prtability cvered in this Operatins Manual, the fllwing items are highlighted as having particular imprtance: LSP Override Yu can check the LSP fr a number by ding a number enquiry. Smetimes, IPMS will display a different LSP than that prvided by the custmer. This will always happen with third party resellers. If IPMS has the incrrect LSP listed, yu can: Check with the Service Prvider that IPMS lists as the LSP first. This is a curtesy, but it is als efficient at identifying whether yu can prceed submitting the prt t them fr them t actin n behalf f a reseller, r whether there are any ptential issues that might ultimately result in a failed prt. If the GSP is certain that the details they have been given are crrect, r if they are listed as the existing Service Prvider, they can put thrugh a prt request where they are bth LSP and GSP and where they select the crrect GC. IPMS will autmatically reject this prt but nce that happens, the GSP can check the LSP Override bx and resubmit it. This is the nly legitimate time yu can use LSP verride. Emergency Returns Thugh IPMS has an Emergency Return feature if a Prt needs t be reversed, it is usually always mre efficient t cntact the riginal service prvider and agree t d a nrmal Prt Request, including an assciated APC t set the RFS date immediately. This handshake prcess avids the cmplicatins and technical issues f using the inbuilt Emergency Returns prcess and ensures that the LSP is aware f the issue and able t immediately accept the prt. Planned Outages The minimum ntice perid fr a Planned Outage is 5 Business Days. Ntice must be sent t NP.Outages@tcf.rg.nz. Hwever, if the utage will impact a carrier s ability t perfrm Netwrk Updates, the ntice perid is increased t 15 Business Days, with a minimum f 10 Business Days between the riginal planned date and the backup date. This is because incmplete Netwrk Updates halt prting fr all parties and have a substantial impact upn the industry. Mre time is required t plan fr these utages. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 3 f 127

4 1. Explanatry Statement 1.1 The purpse f this Operatins and Supprt Manual fr LMNP (the Manual) is fr the supprt and assurance f Lcal and Mbile Number Prtability in New Zealand. Its intent is t ensure that a cnsistent Custmer experience (same prcesses, same Service Levels) is delivered by LMNP. 1.2 It is intended t prvide detailed prcedures fr peratinal implementatin and management f Prting Prcesses and multi-lateral issues that Service Prviders and Carriers will need t implement t ensure and supprt the prcesses defined in the LMNP Terms and the Netwrk Terms and infrmatin, such as Carrier cntact details, that may vary. 1.3 Whilst this Manual may prpse that sme prcesses be subject t Bilateral Agreement, any such agreement shall nt, in any way, result in a degradatin f the Service Levels and Prt Prcess expectatins as laid ut in either the LMNP Terms r this Manual. 1.4 The Manual applies t all parties t the Number Prtability Determinatin in relatin t either f the designated multi-netwrk services, lcal telephne number prtability service r cellular telephne number prtability service. 1.5 This dcument shuld be read in cnjunctin with the fllwing regulatry dcumentatin prduced by the Cmmerce Cmmissin: (a) The Number Prtability Determinatin Decisin 554 Determinatin n the Multi Party Applicatin fr Determinatin f Lcal Telephne Number Prtability Service and cellular telephne number prtability fr Designated Multi-Netwrk Services and Number Prtability Clarificatin Decisin Clarificatin f the Determinatin n the Multi-party Applicatin fr Determinatin f Lcal and Cellular Telephne Number Prtability Designated Multi-Netwrk Services ; (i) (ii) Terms fr Lcal and Mbile Number Prtability (LMNP Terms); Netwrk Terms fr Lcal and Mbile Number Prtability (Netwrk Terms). A cpy f these dcuments can be fund n the TCF Website 2. Backgrund 2.1 The Prting arrangements fr Lcal Numbers and Mbile Numbers in New Zealand are prvided by the Cmmerce Cmmissin s Determinatin n the multi-party applicatin fr determinatin f lcal telephne number prtability service and cellular telephne number prtability service designated multi-netwrk services, including any amendments and subsidiary determinatins ( Number Prtability Determinatin ). 2.2 The Number Prtability Determinatin includes the fllwing: New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 4 f 127

5 (a) Terms fr Lcal and Mbile Number Prtability (LMNP Terms): (i) The LMNP Terms detail the prcesses that enable Custmers t Prt their Lcal Numbers and Mbile Numbers and sets ut the rights and bligatins f parties t the LMNP Terms in a Lcal and Mbile Number Prtability envirnment. (b) Netwrk Terms fr Lcal and Mbile Number Prtability (Netwrk Terms): (i) The Netwrk Terms is intended t guide participating Carriers in the develpment f their wn Netwrk slutins and specify the ptinal and mandatry requirements necessary between Netwrks fr Lcal and Mbile Number Prtability fr Vice Services and Shrt Message Services. 2.3 Included in the LMNP Terms and Netwrk Terms is the timeline and cnditins fr implementatin and n-ging maintenance f the Lcal Number Prtability and Mbile Number Prtability Services. 2.4 Dcument Precedence Telecmmunicatins Act Cmmerce Cmmissin Determinatin Binding dcuments fr implementatin f LMNP - enfrcable by Cmmissin LMNP Terms Netwrk Terms Operatrs A & C Operatrs B & C Bilateral Agreement peratrs A & B IPMS Technical Specificatin LMNP Operatins and Supprt Manual IPMS Access Agreement Operatr C IPMS user manual Operatr B Operatr A (internal) prcess and peratins guide New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 5 f 127

6 2.5 Further Explanatin (a) The IPMS Technical Specificatin dcument is used t specify the technical implementatin f the IPMS. (b) Each Service Prvider and Carrier is t prduce their wn internal manual f business prcesses and peratinal prcedures. While their manuals are expected t be cnsistent with the LMNP Terms, the Netwrk Terms and the Manual, these internal dcuments have n fficial status in the cntext f LMNP. 3. Change Cntrl Prcess 3.1 Prcess fr changing Operatins Manual Any changes t this Manual must be made in accrdance with the TCF Rules and the IPMS Access Agreement. 3.2 Prcess fr changing IPMS Parameters The table belw describes the prcess fr requesting and implementing a parameter change in IPMS. Step Actin Organisatin/ Persn Respnsible 1 Parties t the Number Prtability Determinatin may Party requesting submit an IPMS parameter change request using the parameter change frm Prpsal fr Parameter Change t IPMS in Appendix D and submit it t the NP C-rdinatr. 2 Assign change number t change request. NP C-rdinatr Check the change, ensure it is cnsistent with desired result and cnfirm cmpleted frm cntains all the required infrmatin fr the prpsed change. Assess whether the change can be expedited r whether it needs t fllw the standard change prcess. number range changes can nrmally be expedited changes in TEST, DEV, r TRAIN can be dne with 24 hurs ntice and the restart is nrmally dne at 4.00pm changes in PROD require a minimum f 48 hurs ntice and the restart is nrmally dne at 6pm restarts fr cnfiguratin changes nrmally require a 15 minute utage Ntify the relevant TCF wrking parties. the change request t the TCF Frum New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 6 f 127

7 Step Actin Organisatin/ Persn Respnsible Administratr (alng with a prpsed timetable fr all the envirnments) wh will update the Cnfiguratin Summary register and uplad the change request n the TCF website. 3 Reprt impact f change n IPMS t NPUG NP C-rdinatr 4 NPUG review: NPUG It is preferred that the change is reviewed at NPUG but fr urgent changes it may be distributed by with at least ne Business Day ntice befre the restart. Any pstpnement shuld be dne with a minimum f half a day ntice. Cnfirm all prerequisites are in place t allw the Party t the Number Prtability Determinatin t request parameter change (e.g. the party has executed the IPMS Access agreement) Agree t rll-ut schedule. 5 Review by the Parties t the Determinatin fr mre cmplex changes, such as a new Party jining: Parties t the NP Determinatin Assess impact f parameter change n Carrier s wn Netwrk and systems. Review tentative rll-ut schedule and request t amend rll-ut schedule if required. Finalise rll-ut schedule. (This may be either by sign-ff by the NPUG r agreed at an NPUG meeting called by the TCF Frum Administratr r the NP C-rdinatr.) 6 Manage rll-ut f change: Update the parameter change request frm with agreed rll-ut dates C-rdinate the rll-ut f parameter change with the System Administratr and Parties t the Determinatin. Advise all NPUG members that the parameter change has been implemented via Publish the new IPMS cnfiguratin n the TCF website n a regular basis r as required. 7 If necessary, mdify Carrier netwrk and systems as a result f the IPMS parameter changes NP C-rdinatr Parties t the NP Determinatin 3.3 Standard r expedited prcess The fllwing IPMS parameter changes can fllw the expedited prcess: 1. An existing Number range allcated by the NAD t the Party t the Determinatin that is already in use r abut t be used that needs t be New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 7 f 127

8 laded int IPMS. (This situatin may arise if a Carrier has mitted t lad ne f their existing Number ranges int IPMS). 2. Number range changes r minr changes t the value f fields in existing recrds fr an existing Service Prvider r Carrier in IPMS Test, IPMS Train, r IPMS DEV envirnments. 3. Other changes in TEST, TRAIN, and DEV that are cnsidered urgent and nt t cmplex (there may be limits t hw quickly the changes can be scripted) can be expedited if the NP C-Ordinatr deems it t be practical. 4. Changes nt requiring restarts f the envirnments impact thers less and are mre easily expedited. 5. Private cnfiguratin changes, such as parameter changes fr a Carrier r Service Prvider that impact nly the party asking fr the change, especially if it is t address smething impacting prtability in general. If the NP C-rdinatr believes that a change culd fllw the expedited prcess and the change is nt listed abve, the NP C-rdinatr will send an t the NPUG requesting t use the expedited prcess. This prcess wuld nly ccur where there is a change which impacts anther Carrier. In these cases unanimus agreement is required by all members f the NPUG t prceed with the expedited prcess. In cases where there is n impact n ther Carriers and the NP C-rdinatr ascertains there is a benefit t prtability in general, the change may be carried ut and the NPUG ntified afterwards. Once actined, the cnfiguratin change wuld be psted n the TCF website and the NPUG advised at the frtnightly NPUG meeting. 3.4 Timings The timings fr key steps in the prcess fllw (Nte these are the time frames fr making changes t the IPMS Prd envirnment): Step Duratin (in Wrking Days) 2 1 day days (depends n NPUG meeting frequency, currently frtnightly) 6 1 day 7 Depends n nature f change New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 8 f 127

9 4. Definitins and Interpretatin 4.1 Terms defined in the Number Prtability Determinatin and the IPMS Access Agreement have the same meaning in this Manual. 4.2 This sectin is intended t prvide examples f the cmmn expressins used fr peratinal purpses. Expressin Bilateral Agreement Clarificatin Explanatry Nte Bilateral Agreements may be established between participants in LMNP may be used t enhance the Service Level bligatins f the Terms r t expedite the Prting Prcess. Care shuld be taken by parties entering int Bilateral Agreements, that the bligatins utlined in the Terms are nt cmprmised. BAU Business Day Carrier Custmer Cntractr Manual NP Crdinatr r TCF Crdinatr Service Prvider Terms A Bilateral Agreement check list is included in Appendix A. Means business as usual. Means a day n which registered banks are pen fr nrmal banking business, excluding Saturdays, Sundays and natin-wide public hlidays. Reginal public hlidays are cnsidered t be Business Days. A Carrier is defined in the LMNP Terms. As at the date f this Manual, the Carriers and their allcated Hand Off Cde (HOC) are available n the TCF website. Unless specifically stated within the Manual a persn that has a bna fide retail billing relatinship with a Service Prvider. Means an nsite technician. Means the Operatins and Supprt Manual fr LMNP. means the party appinted by the by TCF t liaise with the System Administratr and is t be the primary cntact pint fr any queries in respect f matters relating t the IPMS. The name and cntact details f the NP c-rdinatr are available n the TCF website. Service Prvider is defined in the LMNP Terms. The list f Service Prviders bund by the Number Prtability Determinatin as Access Seekers r Access Prviders is available n Means the LMNP Terms and Netwrk Terms (as the cntext requires) New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 9 f 127

10 Overview f the IPMS Envirnment a) The IPMS has three envirnments visible and accessible by IPMS users: i. IPMS TEST The primary purpse f this envirnment is t lad new builds f IPMS s that they can be acceptance tested by IPMS users befre being deplyed int PROD. ii. IPMS DEV This is used fr parties t test their wn systems, APIs and prcesses against a cpy f the system that uses the same versin f IPMS as PROD t ensure that parties wn internal changes will be cmpatible with IPMS. Once a new build is accepted and laded int PROD, it is laded int DEV als. iii. IPMS PROD The live number prtability envirnment. b) References t IPMS in this Operatins Manual refer nly t the PROD envirnment, thugh the prcesses described can be recreated in TEST fr the purpses f new build testing and DEV fr the purpse f internal testing, withut impacting real wrld users and ther parties. c) Develpment by the Applicatin Supprt team is tested n anther envirnment that is inaccessible t all but that team. A fifth envirnment, IPMS TRAIN, is currently inactive. d) Bth TEST and DEV cntain additinal fictinal parties (nt fund in PROD) t make testing easier. The riginal LMNP parties have FBN (Fly By Night) versins f their wn cmpanies (ie Spark and FBN Spark). Parties that were laded int IPMS subsequently all use the Dummy Cmpany, and are given userids fr this cmpany. These fictinal parties can be used t act as the ther party (eg GSP r LSP etc) fr testing wrk because all prting activity requires respnses frm at least ne ther party fr activities t be cmpleted. e) Number ranges in TEST and DEV can be very different t thse in PROD. In particular, because there is n real-wrld call ruting ccurring in these tw envirnments, there are a number f ranges that have a reduced set f netwrks that receive netwrk updates. This facilitates faster testing. A list f these Queue By Number Range (QBNR) numbers can be fund in Appendix M. Security f IPMS a) Given the critical nature f the IPMS system, the TCF recgnises the imprtance in having versight f wh uses the system and ensuring that Parties t the Determinatin and ther authrised entities that use IPMS adhere t gd security practices. b) Access t IPMS is nly granted t users with the apprpriate security credentials. All users, as well as all IPMS related activity, must adhere t the TCF s apprved Security Plicies fr IPMS, as set ut in Appendix N. 5. Cde f Cnduct New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 10 f 127

11 6.1 Gd Faith (a) (b) (c) All parties shall act c-peratively and in gd faith t facilitate Prting Prcesses. All parties must act in a nn-discriminatry manner and must facilitate Prting by acting in cmpliance with principles and prcesses that are cnsistent with sectin 18 f the Telecmmunicatins Act. Each party subject t the LMNP Terms must cmply with the Service Levels. If a party fails t meet the Service Levels, the prvisins set ut in sectins 7.4 t 7.7 f the LMNP Terms will apply. 7. Resellers 7.1 The Service Prvider r Carrier is respnsible fr ensuring, t the best f its abilities, that any f its Resellers d nt withhld Prting cnsent frm a Custmer. This bligatin includes ensuring that apprval fr prting steps is granted in a timely manner s that the Service Prvider r Carrier can cmply with its Service Level bligatins under the LMNP Terms. Each Service Prvider and Carrier shall include a clause in its cntract with its Resellers that binds the Reseller t supprt the Service Prvider r Carrier in their bligatin t supprt Number Prtability in accrdance with the LMNP Terms and this Manual. These terms may include an ability fr the Service Prvider r Carrier t apprve prting steps n behalf f the Reseller if the Reseller s delay is at risk f frcing the Service Prvider r Carrier t breach a Service Level under the LMNP Terms. 8. Prting Prcess 8.1 The Prting Prcess means the prcess described in sectin 8 f the LMNP Terms. 8.2 Frm the Custmer perspective, a prting instance is any case where a change f Service Prvider f a Lcal Service r a Mbile Service 1 is implemented. Refer t sectin 8.4d) f the Manual fr further details. 8.3 There may be ther prting instances that invlve interactin with IPMS capability and are nt directly initiated by Custmers. These instances are t be dealt with as Special Prjects, as described in sectin 0 f the Manual. 8.4 Prt Initiatin Prcess Objectives This sectin f the Manual relates t sectin 5.1 and 5.2 f the LMNP Terms. a) This sectin prvides guidelines t ensure a smth transitin frm a Custmer request t Prt t an industry fulfilment f that request. 1 Refer the Terms dcuments fr Service definitins New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 11 f 127

12 Prt Categries It is t be nted that the Terms sectin 5.2.4, Infrmed Cnsent (iv), specify the GSP s bligatins t advise the custmer f existing bligatins they may have t the LSP. This is t include any and all services the custmer may have that d nt relate t LMNP. An example might be their bradband data services which may r may nt be included in the Terms and Cnditins f their lcal r mbile services. Where nt included, the LSP has n bligatin t relinquish these services part f the prting prcess. b) There are fur Prt categries utlined in the Terms. c) General guidelines fr use f each f the Prt categries set ut in clause f the LMNP Terms are prvided belw. A single Prt Request shall nt exceed 500 Numbers. (a) (b) (c) (d) Simple Lcal - A Prt fr 20 numbers r less will typically be managed as a Simple Prt. Simple Mbile - A single cnsumer cnnectin will typically be managed as a Simple Prt. Cmplex Lcal - A Prt fr mre than 20 numbers and / r ISDN will typically be managed as a Cmplex Prt. Cmplex Mbile - Multi-cnnectin and / r Business cnnectins will typically be managed as a Cmplex Prt. Scenaris / Examples d) A Custmer wishes t change Service Prviders f their Lcal r Mbile Service (a) A Custmer must prvide as a minimum the fllwing infrmatin: their current Service Prvider, their phne number, and their (LSP) accunt number, r handset reference number fr Prepay mbile. Beynd knwing this infrmatin, the Custmer may nt t be able t prvide any additinal infrmatin t assist the Gaining Service Prvider structure the Prt Request. (b) In additin t the Custmer being unlikely t be able t prvide additinal infrmatin beynd the name f the Service Prvider, it is pssible that the Gaining Service Prvider has n knwledge f the identity f the Lsing Carrier. (c) IPMS shuld be used wherever a Custmer submits a valid request t change Service Prvider unless specifically excluded by Bilateral Agreement between the respective parties. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 12 f 127

13 e) A Prted Custmer wishing t mve premises and retain the Lcal Number may be allwed t prvided that the new premises are within the same Dnr Carrier s Lcal Calling Area (a) In this scenari, a Custmer mving wuld nt nrmally represent a change in Service Prvider. It may hwever represent a change in Carrier. (b) An example here may be where ne Carrier des nt have infrastructure in the area a Custmer is mving t, but access can be prvided by reselling anther Carrier s infrastructure. (c) Therefre where there is a change in Carrier in this mve scenari, a Prt shall be initiated thrugh IPMS by the Custmer s Service Prvider t maintain call handling integrity in the Netwrk. A new Custmer Authrisatin is nt required fr this type f scenari Prt Request Phase This sectin f the Manual relates t sectin 8.1 f the LMNP Terms. Objectives a) The bjectives fr the Prt Request phase are t: (a) Start the Prt Prcess (GSP) by submitting the Prt request: (i) Service Levels start upn submitting the Prt Request IPMS tracks prgress f the Prt Request; (ii) The IPMS ensures that n ther Prt Requests fr the same Number can be started while the current Prt is in prgress. (b) Allw the LSP t validate the data check that the details prvided by the GSP match with LSP recrds. The details that are checked depend n the type f Prt Request (see Appendix Table 1 f the LMNP Terms). (i) The LSP respnds t the Request (c) Allw the GSP, based n the LSP respnse, t apprve, reject r resubmit the Prt Request. 2 This assumes the clarificatin has gne thrugh New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 13 f 127

14 (i) If the Prt is apprved, the Apprved Prt is nw scheduled t begin Prt Activatin n RFS date / time (ii) If the Prt is rejected, the Number(s) invlved can be included in anther Prt Request (iii) The GSP has the ptin t make changes t the Prt details and resubmit the Prt in sme circumstances; e.g. Custmer wishes t add / remve numbers r the Custmer / GSP changes the RFS date / time fr Prt Activatin. Guidelines b) Guidelines fr when the Prt Request prcess shuld be used: (a) (b) The Prt Request prcess shuld be used where the Custmer requests that a GSP Prt a Number n their behalf. Please refer t the Scenaris / Examples sectin belw. Nte that in the prt request screen, IPMS allws yu t input a range f numbers with "Frm Number" and "T Number" clumns. These must be numeric with n spaces r ther punctuatin (dashes, dts, cmmas etc). If yu enter a nn-numeric number in the "T Number" field, IPMS may return a nn-descriptive errr and the entire SOM will have t be reentered. The Prt Request prcess may als be used t reverse a Prt that has cmpleted previusly, but since then the LSP and GSP have mutually agreed that the Prt was either a mistake r that the Prt was unauthrised. In rder t bring the Number back t the riginal Service Prvider (i.e. the LSP in the riginal Prt transactin), this Service Prvider will nw act as the GSP and submit a Prt Request. (c) A Prt Request must nly be submitted after Custmer Authrisatin (including infrmed cnsent 3 ) has been btained frm the Custmer. (i) Prt Requests shuld nly be submitted after the GSP has cmpleted all reasnable steps and checks t ensure that the Prt will be able t be cmpleted, frm a GSP and GC pint f view. (ii) Such checks may include (but are nt be limited t) cnfirming with the intended Gaining Carrier that the Number can be activated n the Netwrk, and cmpleting a credit check and ther steps that the GSP typically cmpletes befre accepting a new Custmer. 3 Refer sectin and f the LMNP Terms. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 14 f 127

15 (iii) N Prt Requests shuld be submitted pending the utcmes f any steps n the GSP r GC side that may cause the GSP t withdraw the Prt. The Prt withdrawal prcess (see sectin 8.11 f the Manual) shuld be initiated by the GSP in exceptinal cases nly; nt as a cmmn way t stp a Prt shuld ne f the GSP r GC checks fail. (iv) N Prt Requests must be submitted if there is material dubt abut the cmpleteness r crrectness f the data prvided t the LSP, r if there is dubt abut validity f the Custmer Authrisatin the Prt Request prcess must nt be used n a trial and errr basis. (d) Where the LSP and GSP agree t reverse' a previusly cmpleted Prt as a result f a Custmer cmplaint, bth parties need t agree that the Prt is unauthrised based n a dcumented audit trail, cmplaint, r ther valid evidence. In this case, the Custmers dcumented audit trail r cmplaint cnstitutes an Authrisatin by the Custmer (see als sectins 8.12a) and 8.13b) f the Manual). (e) A Prt Request must be submitted within 30 calendar days f btaining Custmer Authrisatin t Prt the particular number, frm the Custmer. (f) It is recmmended that Prt Requests are nt clustered by the GSP Prt Requests are expected t be submitted as they arise frm a Custmer request. This is t prevent the situatin where a LSP is inundated with Prt Requests. (g) A single Prt Request can include up t 500 numbers fr Lcal Prts, acrss multiple carriers. Despite this technical ability, the GSP shuld avid, wherever pssible: (i) submitting a Prt Request that includes mre than 100 numbers at a time. Since a SOM with 100 numbers is expected t be cmpleted in the same timeframe as a SOM with 1 number, large SOMs can unfairly impact the LSP/LC and swamp their systems. In additin, if a single number in a SOM incurs an errr, the entire SOM will be held up and unable t cmplete. This unfairly impacts numerus numbers. (ii) Submitting a Prt Request where the GSP knws that several LCs will be impacted. This increases the cmplexity f the Prt and increases the risk f errrs hlding up the majrity f the numbers in the SOM. The GSP may nt always be aware what LCs will be impacted, but submitting Prt Requests with a limited vlume f numbers will reduce the risk f invlving multiple LCs. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 15 f 127

16 (h) Fr Mbile Prts, a Prt Request shuld nt mix Prepay and Pstpay LSP numbers unless agreed bilaterally t d s. (i) A Prt shall include ne r mre Pstpay numbers in which case a single LSP accunt reference must be included, r (ii) Shall include ne r mre Prepay numbers in which a handset reference must be included fr each number t be Prted. c) Guidelines fr when the Prt Request prcess shuld nt be used: Scenaris / Examples (a) (b) (c) (d) By the LSP the LSP cannt request a Number t be Prted away. If a Custmer requests t Prt away, they shuld be referred t the apprpriate Gaining Service Prvider. If there is already an pen Prt request in IPMS fr that Number. This will be the case if a Prt fr that Number has previusly been submitted, and that Prt has nt been withdrawn, expired r cmpleted. If details f an apprved Prt Request need t be changed (e.g. change t the RFS date), the Apprved Prt Change prcess shuld be used instead f submitting a secnd Prt Request fr the same Number. If the LSP r GSP determines within 1 Business Day f Prt cmpletin that the cmpleted Prt must be reversed. Instead the GSP shuld use the Emergency Return (see sectin 8.12 f the Manual) prcess. d) The LMNP Terms specifically mentin a c-perative perid, during which either the GSP r LSP can cntact each ther t discuss the Prt Request. Examples f when this may be apprpriate include: (a) (b) (c) During a review f the Prt request by the LSP, the LSP ntices that infrmatin prvided is incrrect r incmplete. Rather than respnd with can nt match, the LSP may cntact the GSP t clarify t facilitate the Prt prcess. The LSP respnse indicates that (sme f) the data prvided is incrrect, and the GSP wants t clarify befre making a decisin t reject the Prt, r t apprve the Prt using either the GSP data r the LSP respnse. While the LSP must act in gd faith it is nt bliged t prvide the infrmatin requested by the GSP. Where the details match n the LSP side, but the LSP has genuine cncerns that Prting that particular Number will cause a prblem r service interruptin fr the Custmer, the LSP shall ntify the GSP by f these cncerns: New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 16 f 127

17 (i) if the request is t Prt away a pilt Number, withut any / all f the ther Numbers; (ii) the LSP has a genuine cncern arund the Custmer Authrisatin f the Prt; (iii) the LSP believes that the Custmer may have intended t Prt ther Numbers as well, but nly requested a sub-set f Numbers; (iv) n additinal Numbers will be ffered fr Prting by the LSP. It is the GSP s respnsibility t ensure that as part f the pre- Prt prcess, all Numbers are captured. (d) The GSP has the bligatin t liaise with the Custmer in crrecting the Prting infrmatin. The LSP has n bligatin t prvide the GSP with specific infrmatin regarding the Prt r Custmer accunt. Explanatry nte e) This sectin aims t clarify sme f the terminlgy and statements in the Terms in the cntext f the Prt Request prcess. f) Categry f Prt changed frm Simple t Cmplex (a) (b) (c) The LSP can, as part f their review f the Prt, request that the Categry f Prt be changed frm Simple t Cmplex (but nt the ther way arund). Changes t the Categry f Prt must be driven by technical r business cmplexity and nt as a default respnse, t extend the allwed respnse time. The verall guideline is that bth the GSP and LSP must make every effrt t allw the Prt t be cmpleted within the timeframes riginally given t the Custmer (the RFS date). g) Validatin and Apprval (a) (b) If the LSP indicated n the Prt Request is incrrect, the LSP will indicate incrrect LSP and send the respnse n data is validated. If the Accunt Number n the Prt Request is invalid r absent when checked against existing Custmer recrd, the LSP will indicate accrdingly n respnse phne numbers are nt validated with regard t frmat, clse matches r mistyping. Fr the assistance f the GSP, the minimum and maximum length f the Accunt Numbers, and the frmat used, is set ut in Appendix L. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 17 f 127

18 (c) (d) (e) (f) If the LSP cannt match the line item details prvided in the Prt Request, they will indicate this n the respnse. If mre than ne Number is included in the same Prt Request, the LSP will validate all the Numbers that d match. The LSP des nt reject a Prt Request; nly the GSP can apprve r reject a Prt upn reviewing the LSP respnse. When the GSP apprves the Prt Request, they may chse t use the details f their riginal request, r use the LSP respnse details. Upn retrieving the Prt Request frm the IPMS queue, the LSP checks the details f the Prt. Only certain details are required t match: 4 h) Fr Mbile Prts, Pstpay (Pstpay with the LSP): (a) (b) Phne Number LSP Accunt Number i) Fr Mbile Prts, Prepay (Prepay with the LSP): (a) (b) Phne Number Handset reference number (i) (ii) The handset reference number fr GSM phnes (used by Vdafne, M2 Cmmunicatins (including Black and White), Tw Degrees Mbile, Vdafne, Cmpass, CallPlus and sme Spark Custmers) is the SIM card number. This number is printed n the actual SIM card. Fr the assistance f the GSP, the relevant number length is set ut in Appendix L. The handset reference f CDMA phnes (used by sme Spark Custmers) is the unique hardware number n the phne (ESN), typically n the back f the phne under the battery. NOTE: When the prepay/prepaid bx is ticked, the handset reference clumn shuld becme available fr text input. This wrks in IE8 in cmpatibility mde, but des nt in Chrme r Firefx brwsers. In these tw brwsers yu must submit the prt request withut entering the handset reference, let IPMS check and reject the request and then the field will be available fr input. Full Chrme and Firefx functinality will be added in a future release. j) Fr Lcal Prts (a) Phne Number 4 Refer Table 5, Appendix 1 f the LMNP Terms. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 18 f 127

19 (b) LSP Accunt Number k) Nt Required flag (a) If the nt-required flag is set t yes, it means that the Number will be relinquished by the LSP (ie the number is n lnger required by the custmer). If yu want t have the number excluded frm the Prt but nt relinquished, then d nt include the Number in the Prt and it will be ignred. Bilateral Agreements may als define additinal specific meaning t the nt-required flag, e.g. triggering a specific prcess at the LSP side. l) Number Blcks (a) If the GSP is Prting a blck f Numbers that cannt be entered as part f a single Prt Request, they will need t split the Numbers ver mre than ne Prt. This will be the case if the Number Blck is bigger than 500 Numbers (limit f the Prt Request) r is split acrss multiple accunts at the LSP side. Nte: in the prt request screen, IPMS allws yu t input a range f numbers with "Frm Number" and "T Number" clumns. These must be numeric with n spaces r ther punctuatin (dashes, dts, cmmas etc). If yu enter a nn-numeric number in the "T Number" field, IPMS may return a nn-descriptive errr and the entire SOM will have t be re-entered. m) Residual Numbers (a) The Custmer may need t cntact the LSP t manage any residual Numbers and / r clse their accunt with the LSP. The LSP may need t cntact the Custmer regarding any residual Numbers that may affect their existing service. Any cntact with the Custmer by the LSP must be in accrdance with Sectin J f the TCF Custmer Transfer Cde (extracted in Appendix G). n) Custmer Infrmatin Field (a) The additinal Custmer infrmatin field in IPMS shuld be used fr the full accunt cde when it is abve the 20 characters allwed fr in the primary Custmer Accunt field when required fr ID reasns (sme Symbi Custmers are mst likely t have accunt numbers greater than 20). The additinal Custmer infrmatin field can als be used fr ther infrmatin as required. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 19 f 127

20 ) Guidelines fr Using the Standard Prt Request Prcess fr Prting Partial Call Readdressed Numbers (a) (b) (c) (d) (e) (f) (g) The GSP is t initiate the prt request with the crrect LSP and Custmer accunt number as identified n the Custmer invice. The GSP is t include all related partial readdressed numbers in the Prt Request. (Due t the linked nature f the numbers the LSP has the right t reject the request if linked numbers are missing.) The GSP is t use the "nt required" checkbx and tick it if specific numbers are nt t be prted. The LSP will interpret and actin this as part f the manual interventin prcess. See sectin k) fr further infrmatin n the nt required checkbx. The prt must be submitted fllwing the standard rules. IPMS will invke its standard LSP validatin and reject the Prt Request giving a reasn that a specific number requested is nt wned by the LSP specified. The GSP re-cnfirms that the LSP is crrect and ticks the "Override Service Prvider" checkbx and resubmits. The LSP will undertake a manual validatin f the Prt Request and will apprve r reject the Prt Request prviding the reasn fr the rejectin is in accrdance with the standard LMNP prcesses. Once apprval has been gained, the standard LMNP prcesses are applicable. 8.6 Prt Activatin Phase This sectin f the Manual relates t sectin 8.2 f the LMNP Terms and sets ut the bjectives where a Custmer Number is being Prted frm ne Carrier t anther including third party updates. The IPMS enfrces rules arund when a SOM is permitted t be activated. The clumn fr Windw belw is the time detailed in the LMNP Terms, the grace perid is added t this time t allw activatins utside f hurs (where agreed, see sectins 8 and 9). The ttal windw is the ttal length f time in which a SOM can be activated withut requiring an Apprved Prt Change (APC) t reschedule it. Objectives Prt Type Windw Grace Perid Ttal Windw Simple Lcal Half Day 4 hurs 8 hurs (mrning) 9 hurs (afternn) Cmplex Lcal Half Day 15 hurs 19 hurs (mrning) 20 hurs (afternn) Simple 10 minutes 230 minutes 4 hurs Mbile Cmplex Mbile Half Day 60 minutes 5 hurs (mrning) 6 hurs (afternn) New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 20 f 127

21 a) Custmer Number is being Prted frm ne Carrier t anther including third party updates. b) Explanatry nte fr clause 8.2 f LMNP Terms Prt Activatin c) Prt Activatin prcess (a) (b) (c) (d) (e) (f) (g) Dne / Undne / Dne Lp Prt Activatin will begin when a GSP mves an apprved Prt t in prgress status. The end-t-end Prt Activatin prcess must be managed within Wrking Hurs as defined in LMNP Terms except where extended hurs are agreed between the GSP and LSP, and GC and LC. Where a Prt Request results in a change f Service Prvider but nt f Carrier it will still prgress thrugh all activatin phases but there will be n changes t Netwrk infrmatin r third party updates. If any cmplexities are present fr a particular Prt Request, impacted parties shall use the c-perative perids t wrk clsely tgether t facilitate the successful Prt rather than relying slely n the autmated prcess. It is recmmended that Prt Activatins are nt clustered by the GSP Prt Activatins are expected t be scheduled as they arise frm a Custmer request. This is t prevent the situatin where a LC is inundated with requests t actin Prt Activatins. If a GSP has requested mre Numbers t be activated than the LSP indicated in their respnse, it is highly prbable that the additinal Numbers will nt be Prted and the GSP shuld expect these Numbers t fail at the activatin stage. If Prting is successful fr nly sme Numbers within a single Prt Request the GC and LC must agree with input frm the GSP t: (i) (ii) reverse successful Numbers, and fail the Prt Request if there are n successfully Prted Numbers, r cmplete the SOM if there are any successfully Prted Numbers. d) While IPMS will allw the GC and LC t update each Number many times, it is agreed that prcedures will nly allw GC Cmplete t be set t Dne" twice nly. If the LC r GC fails the activatin at any stage IPMS will reset these number prgress states in the same functin that the Gaining Carrier uses t restart the prcess fr that number. Fr each number where the Gaining Carrier is set t "Dne" the values f Lsing Carrier fields and Test & Cmplete fields will be set t "Nt Dne" if they are set t anything ther than "Nt Dne". The ther Carrier will need t be aware s that New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 21 f 127

22 they reset their netwrk as if the activatin had nt started. If a Number is left in an Undne state it will nt be updated t the Prted Number Register. Only the Gaining Service Prvider may set the Activatin Status t Reversed. A Prt Request will need t be raised fr any utstanding Numbers. (a) (b) (c) (d) (e) (f) (g) (h) The LC cannt activate a Prt fr a Number until GC sets status t Dne. Hwever, any pre-wrk may be perfrmed up t this pint. Any billing issues arising ut f lengthy Prt Activatin prcesses are t be reslved between the Custmer and the apprpriate Service Prviders directly. There is n bligatin fr Service Prviders t manage the billing in any way ther than business as usual. The LSP and LC have n bligatin t cntinue prcessing activatin wrk if it extends past agreed timeframes but best effrts will be made t cmplete the Prt nce it has cmmenced. It is GSP s respnsibility t ensure that the Prt Activatin prcess is started at a time that means it has a realistic expectatin f being cmpleted within the agreed timeframes (Wrking Hurs, r extended hurs if agreed between the parties). If the start f Prt Activatin is delayed by the GC such that an RFS Date / Time is missed, it will be necessary t raise an APC. Mbile Number Prt Activatin shuld nt result in any lss f service fr utging calls fr the Custmer as bth the ld and new handset can be active n the same Number n each Netwrk, at the same time. Incming calls may r may nt be impacted depending n the call ruting slutins deplyed by Carriers. Lcal Number Prt Activatin may result in lss f service fr utging calls fr the Custmer during activatin. This is due t the need t prvide a physical cnnectin between the new GC s Netwrk and the Custmer s equipment. Incming calls may r may nt als be impacted, depending n the call ruting slutins deplyed by Carriers. The Service Levels fr Lcal Number Prting allw up t within half day fr Prt Activatin t ccur, hwever Carriers will use their best endeavurs t ensure the impact n the Custmers incming and utging calls is likely t be n mre than 15 minutes where thse calls are between the GC and LC, and will be as per agreed update perids fr third party Carriers. 8.7 Apprved Prt Change Prcess Objectives This sectin f the Manual relates t sectin 8.3 f the LMNP Terms. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 22 f 127

23 a) The bjective f the Apprved Prt Change (APC) Prcess is t allw the LSP / GSP and Custmer (via the GSP) t: (a) (b) change the RFS Date and / r change the numbers and t allw the LSP t: Guidelines (c) change the RFS Date b) An APC is nt permitted nce a Prt Request has cmmenced Prt Activatin ( In Prgress ). c) Prvisins f the c-perative perid apply thrughut the APC prcess. d) Based n Table in the LMNP Terms, Apprved Prt Changes have maximum prcess cmpletin times f: Flwchart APC Prcess Respnse Times Simple Lcal Prt Cmplex Lcal/Mbile APC3 APC5 t APC7 and APC8 Respnding Party checks change queue and respnds Gaining Carrier(s) and Lsing Carrier(s) shuld review this queue regularly Tw Wrking Hurs Frequency Every Wrking Hur Prt Fur Wrking Hurs Every Tw Wrking Hurs Simple Mbile Prt Tw Hurs Wrking Every Wrking Hur e) This needs t be factred int any decisins abut the use f APC. Given the shrt timeline fr Simple Mbile Prts the use f APC is nt recmmended if the RFS Date is less than 3 Wrking Hurs in the future. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 23 f 127

24 f) An APC is nt pssible nce a Prt is expired r withdrawn. A Prt expires 5 Business Days after the RFS Date if an APC is nt initiated and the Prt has nt been activated. g) An APC may nt be used mre than five times n a Prt befre the RFS Date but can be raised many times after the RFS Date. h) Once an APC is raised the riginal Prt remains in place and, if the APC is declined, will revert t its riginal status. i) An APC cannt be used t extend the RFS Date beynd the 30 calendar-day maximum when the Prt Request is submitted. Explanatry Nte j) This prcess is nt t be used by the LSP t delay the lss f a Custmer. The LSP must nt raise an APC t add Numbers t the Prt Request after the RFS Date has been agreed. k) An APC can nly be applied t an Apprved Prt. If the Prt Request is still in the Prt Request Prcess the ptins are t wait until the request is apprved r withdraw the request and initiate a new request r re-submit the same request with amendments. 8.8 Prt t Dnr Under sectin 13 f the Netwrk Terms it states that Carriers may enter int Bilateral Agreements n the methd f handing ver calls between their netwrks. In general, attaching a HOC t a call indicates that the Carrier has identified a call t a prted number and that the Carrier is aware f the crrect Hst Carrier. Where a number is prted back t the dnr Carrier, the prvisins f sectin 13 f the Netwrk Terms shall apply and the call shuld nt have a HOC added unless bilaterally agreed t the cntrary and subject t the cnditins utlined sectin 13.3 f the Netwrk Terms. 8.9 Prted Number Relinquishment (including Quarantine) Prcess Objectives Guidelines This sectin f the Manual relates t sectin 8.4 f the LMNP Terms. a) T prvide Prted Number relinquishment prtcl including quarantine prcess. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 24 f 127

25 b) Relinquishment (a) A Service Prvider shall relinquish a Prted Number where: (i) (ii) The Custmer has discnnected the Number A Service Prvider has discnnected the Number as part f BAU. (b) A Prted Number may nt be relinquished where: (i) The Number is part f a cntiguus Number Blck unless it is the last remaining Number in the Number Blck. In this case the whle Number Blck is then relinquished. (c) After the Hst Carrier has relinquished the Number it will be quarantined by the IPMS fr 30 calendar days. During the quarantine check perid, the Hst Carrier terminates the call with an apprpriate call treatment. (d) Cancellatin f Relinquishments Shuld the Custmer change their mind and request the reactivatin f their number nce the number has been relinquished the prcess belw shuld be fllwed if it is within the 30 calendar days. (i) In IPMS Number Enquiry, if the user has the relinquishment cancel ptin enabled in their IPMS user prfile, enter the SOM number f the relinquishment and press the Cancel buttn. (ii) Failing that the Service Prvider must supply the fllwing data t the NP C-Crdinatr: - SOM number f the relinquishment - The affected phne number(s). NB: The requesting Service Prvider must be the Service Prvider that raised the relinquishment in IPMS. Once the details are cnfirmed the NP C-Crdinatr will instruct HP t change the date n the RQ SOM s that it will be relinquished in the vernight prcessing that day. HP will cnfirm this has been cmpleted and the NP C-Crdinatr will advise the requesting Service Prvider the next mrning when it is shwn t be cmpleted. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 25 f 127

26 This allws a Service Prvider t allcate the number t the Custmer. If the requesting Service Prvider des nt have a relatinship with the Dnr Carrier f the number range they must arrange with the Service Prvider that des have a relatinship, t allcate the number and subsequently prt the number if required. (e) Relinquishment Fast Track If the Custmer wants t be activated n the Dnr Netwrk, the relinquishment can be Fast Tracked. The Service Prvider must supply the fllwing data t the NP C-Crdinatr: (i) SOM number f the relinquishment - The affected phne number(s) NB: The Service Prvider that wants the Fast Track is nrmally nt the Service Prvider that requested the Fast Track. Therefre, the Service Prvider wh created the relinquishment must request the Fast Track (ften, a Service Prvider assciated with the Dnr Carrier will riginate this request and be cpied n the request). Once the details are cnfirmed the NP C-Crdinatr will instruct HP t change the date n the RQ SOM s that it will be relinquished in the vernight prcessing that day. HP will cnfirm this has been cmpleted and the NP C-Crdinatr will advise the requesting Service Prvider that the number shuld be available the next mrning when it is shwn t be cmpleted Prt Expiry Prcess This sectin f the Manual relates t sectin 8.5 f the LMNP Terms. Please refer t clause 8.5 f the LMNP Terms fr the Prt Expiry Flwchart and the Service Levels that apply t the Prt Expiry prcess. Apprved r failed prts where the end f the RFS windw was mre than ne Business Day ag will be changed in IPMS t expiring at midnight. An APC can be used t reschedule, and an expiring SOM may stay there until the LC cnfirms if they are cnfigured t require it (in the carrier cnfig field CONFIRMPORTWITHDRAWALIFLC). A Prt Request that is awaiting apprval ges in t an expiring state. Then it is expired five days later, fr example: RFS Date - 13/8 Midnight 14/8 set t Expiring (1 day, as per parameter) Yu can APC it t reschedule New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 26 f 127

27 Midnight 19/8 set t Expired (5 days after, as per parameter) Nw need a new prt request t prt the number NB: Once a prt ges int an expired status in IPMS, Carriers and Service Prviders are respnsible fr cleaning up this infrmatin. If this expired prt is left pen, it leaves a ptential prblem fr ther Service Prviders being able t prt that mbile number in the future. Because f this the SLA t withdraw expired prts will be the next wrking day. Objectives a) The main reasn fr having a Prt Expiry prcess is t clean up verdue Apprved Prts r Prt Requests in IPMS and prevent the situatin where a Number cannt be Prted at sme stage in the future because it s still part f a previusly Apprved Prt. b) The bjectives f the Prt Expiry prcess are: Guidelines (a) (b) (c) Fr IPMS t ntify the GSP that an Apprved Prt has nt been activated within the expected time windw and that, unless the GSP initiates a specific actin, the Prt will expire. T expire Apprved Prts five Business Days after the RFS date has passed, and thus releasing the Number(s) included in the Prt. T cnfirm that bth the Gaining Carrier and Lsing Carrier n lnger have the Prt scheduled t be activated. c) The Prt Expiry prcess is nt triggered by the LSP r GSP it is triggered by the IPMS. As such, there are n user guidelines as t when t use this prcess. d) There are guidelines hwever arund the respnse required frm the GSP. When the GSP is ntified by IPMS that an Apprved Prt will expire in 5 Business Days, the GSP has three ptins fr its respnse: (a) Respnd by initiating a Prt Change Request t schedule a new RFS date. This curse f actin shuld nly be taken after agreeing a new date/time t Prt the Custmer. This respnse must nt be the default respnse t an expiry ntificatin, in rder t allw mre time (e.g. fr discussins with the Custmer) and keep the Number(s) lcked in a Prt Request. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 27 f 127

28 (b) Respnd by withdrawing the Apprved Prt. This actin shuld be taken if the GSP establishes that the Prt is n lnger required t be activated (either cnfirmed by the Custmer, r because f a business r technical issue being experienced by the GSP r GC), r if the GSP cannt agree a new RFS date with the Custmer. (c) D nthing, and let the Prt expire. This apprach shuld be an exceptin: the GSP must make a reasnable effrt t respnd with an APC r a withdrawal, and nt use this third ptin as their default respnse. While the Prt Expiry prcess waits fr the 5 Business Days t elapse, the Number(s) included in the Prt are still prevented frm being included in new Prt requests. e) In general, the guideline is that the GSP shuld withdraw the Prt nce they becme aware that the Prt will nt be activated. The default actin by the GSP must nt be t let the RFS date pass, and wait fr the Prt Expiry prcess t be triggered befre withdrawing the Prt. Scenaris / Examples f) A Prt Request that is nt yet apprved can expire in the same manner as an Apprved Prt. g) N pints f interactin between the GSP and LSP are identified in the Terms in relatin t the Prt Expiry prcess. Pssible scenaris where direct cntact between the GSP and LSP will be beneficial include: (a) (b) Befre requesting a new RFS date (thrugh the APC prcess), the GSP may want t discuss an apprpriate date / time with the LSP, t prevent unnecessary further delays in setting a new RFS date. The LSP may cntact the GSP nce the RFS date has passed, requesting that the GSP withdraws the Prt (prir t the Prt expiring). This may be apprpriate if the Custmer has cntacted the LSP and as a result the LSP wants t perfrm an accunt maintenance activity (e.g. discnnect the Custmer, r transfer the Number) that is typically nt carried ut while a Prt-ut request is in prgress. Explanatry Nte h) Nte that the LSP is expected t refrain frm discnnecting a Custmer while a Prt is in prgress, and charges may cntinue t be incurred by the Custmer fr the duratin f the Prt. If required, a Lsing Service Prvider may bar all services while a Prt Request is In Prgress s that the Custmer can retain wnership f the Number but nt cntinue t accrue charges (in a credit situatin). New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 28 f 127

29 i) All Prts nce apprved, must eventually reach a final status thus making the Number available again fr future Prts. There are three pssible ways that the status is changed t a finalised state: (a) (b) (c) The GSP withdraws the Prt A Prt Activatin ccurs The Prt Expires this prcess ensures that the Prt Request is ended even if the GSP takes n further actin n the Apprved Prt Prt Request Withdrawal Prcess This sectin f the Manual relates t sectin 8.6 f the LMNP Terms. (a) (b) A Prt Request Withdrawal can be requested by the Custmer r initiated by the GSP n behalf f Custmer, in rder t supprt the verall Custmer experience. New Prt Requests cannt be made against the Numbers in a Prt Withdrawal until the Prt Withdrawal has been cmpleted. This prcess may take up t 4 Wrking Hurs Emergency Return Prcess Objectives Guidelines This sectin f the Manual relates t sectin 8.7 f the LMNP Terms. a) This prcess is required t quickly, and at reduced ntice perids, return a Custmer s Number t the Custmer s previus Service Prvider and Carrier and t restre all ruting as if the Prt had nt been perfrmed. b) Emergency Returns may nly be used within ne Business Day f the cmpletin f the Prt Activatin. c) Ideally, a prblem with a prt shuld be identified befre the Prt is cmpleted. The Test and Cmplete phase f the prting prcess, while the Prt status in in prgress is designed specifically fr the purpse f identifying any issue. Autmatin, thugh enabling prts t be cmpleted in a timely manner, can remve the ability t spt errrs befre the Prt is cmplete. d) It is pssible fr parties t agree bilateral prcedures fr handling emergency returns f this nature. These bilateral agreements shuld take preference ver use f the inbuilt IPMS Emergency Return Prcedure. In the absence f a bilateral agreement it is expected that Emergency Returns wuld be used very sparingly. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 29 f 127

30 e) T use the Emergency Return Prcess effectively, parties will need t practively cmmunicate with the frmer LSP t ensure they are ready fr the return Prt and are able t accmmdate the return. It will nrmally be easier and faster t ask the frmer LSP t ldge a new prt request and supply details fr the request t them t facilitate fast cmpletin, rather than use the Emergency Return prcedure. IPMS users shuld cntact the alternate party by phne and remain n the phne while the tw f yu cmplete the prting prcess t ensure that bth sides are aware f what is happening and that the actin is cmplete. IPMS users shuld nte that there is a gd chance that an Emergency Return may be rejected by the new GSP if they are nt fully infrmed abut the situatin thrugh this handhld prcess. f) The Gaining Carrier(s) and the Lsing Carrier(s) must agree that an Emergency Return is required. The Lsing Carrier(s) and Gaining Carrier(s) must crdinate the Emergency Return as mutually agreed. Ntice perids fr RFS Dates d nt apply. g) The Emergency Return must use an existing cmpleted Prt Activatin as a reference. The Emergency Return des nt have t reverse all Numbers in a given Prt. An Emergency Return will be prcessed in exactly the same way as a nrmal Prt Activatin, except that the RFS Date rules are nt enfrced. h) The IPMS will require the SOM Number f a previusly cmpleted Prt. The IPMS will check that the Prt was activated within ne (1) Business Day f the request f the Emergency Return. Numbers that did nt Prt successfully in the riginal Prt Activatin cannt be returned. The riginal Gaining Service Prvider becmes the new Lsing Service Prvider nce an emergency request is initiated. i) Emergency Return can be used if: (a) (b) (c) The Prt was nt authrised by the Custmer and if it is within ne Business Day f the cmpletin f the Prt Activatin The Custmer requests it where the Custmer s level f service is technically impacted due t Carrier prblems. Emergency Return cannt be used if: (i) (ii) A Custmer changes their mind Impacted parties d nt reach agreement. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 30 f 127

31 Scenaris / Examples j) Custmer discvers that they have accidentally Prted a Number, as part f a Number Blck that shuld have been left with the Lsing Service Prvider. k) A Carrier discvers that when they cnnect the numbers invlved in the Prt, the resultant call service delivered is unacceptable. An example might be where althugh the Prt itself has wrked, a recnfiguratin f Custmer premises equipment assciated with the Prt has failed and the nly way t regain service is t regress the Prt Unauthrised Prts Objectives Fr a definitin f what cnstitutes Custmer Authrisatin, Infrmed Cnsent, the Custmer Authrisatin Validity Perid and when a Prt is deemed t be unauthrised, refer t the LMNP Terms sectin 5.2. a) The bjectives f this sectin are t: Guidelines (a) (b) (c) (d) Clarify hw the LSP can query the Custmer Authrisatin fr a particular Prt, and what the expected respnse frm the GSP will be Clarify the interactin and cperatin between LSP and GSP in establishing and agreeing whether a Prt is authrised r unauthrised by the Custmer Describe the prcess t fllw in cases where it is agreed a Prt is unauthrised Describe the prcess t escalate disputes when the LSP and GSP d nt agree whether a Prt is authrised r unauthrised. b) At the time that the Prt Request is submitted by the GSP, the Prt is deemed t be authrised. If subsequently the LSP discvers that the Custmer Authrisatin may nt be valid, they need t cntact the GSP. The general prcess by which a Prt can becme unauthrised is as fllws: (a) (b) The LSP discvers that the Custmer Authrisatin fr the Prt is nt valid (e.g. the wrng persn signed fr the Prt) and the LSP cntacts the GSP t discuss r dispute the Custmer Authrisatin. The GSP and LSP agree that the Prt is unauthrised. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 31 f 127

32 c) Nte that if the GSP becmes aware (r suspects) that the Prt is unauthrised, prir t Prt Activatin, they must reject r withdraw the Prt n agreement frm the LSP is required. d) Once the LSP and GSP agree that a Prt is unauthrised, they must, depending n the phase in the Prt prcess: (a) (b) (c) (d) (e) Cancel the Prt (GSP) - prir t Apprval Withdraw the Prt (GSP) - prir t Prt Activatin GC t stp prcessing (GSP t infrm GC) - during Prt Activatin. GSP t fail the Prt Emergency Return within 1 Business Day f Prt Activatin The riginal LSP submits a Prt request t bring the number back (act as the GSP in this request) mre than 1 Business Day after Prt Activatin. e) If the LSP believes that the Prt is unauthrised, but the GSP des nt agree, the fllwing guidelines must be fllwed: (a) (b) (c) (d) Prcess t agree that a Prt is Unauthrised LSP t respnd a per nrmal; RFS changed (APC by LSP r GSP) t allw time fr investigatin- prir t apprval APC t push back RFS, t allw time fr investigatin prir t Prt Activatin Cntinue Prt Activatin - during activatin. Then wait fr agreement t Prt back r d emergency return Wait fr LSP and GSP t agree any time after Prt Activatin (whether within 1 Business Day r mre than 1 Business Day after Prt Activatin. f) LSP enquiry abut the Prt Authrisatin 5 (a) The LSP can cntact the GSP directly t request a cpy f the Custmer Authrisatin btained fr a specific Prt. (i) (ii) The LSP can request the cpy at any time during the Prt prcess r up t 12 mnths after the Prt Request where the Custmer queries the validity f the Prt. The Service Level defined in the LMNP Terms specifies that the GSP must prvide the cpy within 5 Business Days after the request. Particularly when a Prt has nt been activated yet, the GSP shuld make all reasnable endeavurs t supply the cpy f 5 Shuld CA frms have a disclsure statement n them re: privacy laws New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 32 f 127

33 the Custmer Authrisatin as sn as pssible. In general, it will be less impacting t the Custmer, the GSP and the LSP if a Prt is fund t be unauthrised prir t Prt Activatin (s the Prt can be withdrawn by the GSP), cmpared t the scenari where the Prt is fund t be unauthrised after cmpletin. Guidelines (b) The LSP can cntact the GSP t discuss dubts abut the Custmer Authrisatin fr a specific Prt Request this may r may nt lead t the LSP requesting a cpy f the Custmer Authrisatin. g) As a general guideline, the LSP must nly enquire abut the authrisatin f a Prt and / r request a cpy f the Custmer Authrisatin in cases where the Custmer queries the validity f the Prt the prcess must nt be used by the LSP t try and delay r prevent a Prt. Bth the LSP and GSP must act in gd faith. The LSP must act n specific infrmatin prvided by the Custmer ( the bill payer ) that suggests that the Prt may nt be authrised. Gd Faith h) If, in rder t verify the authrisatin f a Prt, mre time is required, i.e. the validity f the Custmer Authrisatin can nt be established befre the RFS date arrives, either the GSP r the LSP can initiate the Apprved Prt Change (APC) prcess. If, as a result f a Custmer query regarding the validity f the Prt, the LSP and GSP shuld agree t reschedule the Prt (change RFS), and the GSP must infrm the Custmer f the delay. i) As a general guideline, if there are material dubts abut the Custmer Authrisatin (after the Prt Request has been submitted), and mre specifically, abut whether the persn wh requested the Prt is authrised t d s, the GSP and LSP will wrk tgether t establish the validity f the Custmer Authrisatin. The bjective is t prevent an unauthrised Prt frm being activated in the first place, as there is a significant impact n the legitimate wner f the number if the Prt des prceed, and then needs t be reversed. j) Given the typical timing fr cmpleting a Prt, if the GSP and LSP intend t establish if a Prt is unauthrised during the available time between the GSP submitting the Prt Request, and Prt Activatin being triggered (n RFS date), the parties will need t cperate and exchange infrmatin. The prcess mentined in the Terms where the LSP requests a cpy f the Custmer Authrisatin is mre suitable t prve authrised / unauthrised after the Prt has cmpleted. Due t the nature f the Prt prcess (GSP led prcess), each party has part f the infrmatin required; the LSP New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 33 f 127

34 nly has visibility f the Custmer s current accunt structure, and therefre is mre likely t knw wh is authrised t Prt a number (the Custmer / bill payer; nt necessarily the cnnectin hlder); the GSP nly has visibility f the Custmer Authrisatin and nly the GSP has direct cntact with the Custmer during the prcess. Escalatin prcess t establish if a Prt is Unauthrised k) If after discussing the Prt and exchanging infrmatin, the LSP and GSP cannt agree n whether the Prt is unauthrised r nt, the fllwing prcess will be fllwed: Reversal f an Unauthrised Prt l) The GSP and LSP agree that the Prt is unauthrised. An audit trail must be kept by bth parties; bth parties shuld send an t cnfirm that they are satisfied that the Prt is unauthrised, and shuld be reversed. If nly certain numbers in a Prt are deemed t be unauthrised, the specific numbers must be listed in the . m) The new GSP will nt have a Custmer Authrisatin frm the Custmer in this case; the cnfirmatin by LSP and GSP will serve as prf f Authrisatin, and must be kept fr a minimum f 12 mnths. The new GSP must be able t reprduce the cnfirmatin (agreement) frm the LSP upn request; either when audited r if the LSP asks fr a cpy. n) The new LSP will cnfirm the details f the Prt prvided that nly numbers agreed t be reversed are included. The LSP will apprve as sn as pssible priritising apprval fr this type f Prt reversal ver BAU Prt ut requests. ) The GSP will Apprve the Prt. Apprval will be given as sn as pssible - priritising apprval fr this type f Prt reversal ver BAU Prt in requests. p) The GSP will initiate Prt Activatin nce the Prt is apprved. q) During the Prt reversal prcess, cmmunicatin t the Custmer will be as fllws: The riginal GSP (the SP that requested the Prt that is nw deemed t be unauthrised) will cmmunicate with their newly acquired Custmer their number(s) are being Prted back, but at the start f the Reversal prcess, the riginal GSP has the billing relatinship with this persn. The riginal LSP will cmmunicate with their Custmer the persn wh has legitimate wnership f the number that is being Prted back. 9. Special Prjects 9.1 In additin t the fur types f Prts listed abve, there may be a need t update IPMS and / r third party Carriers utside the prvisins f the standard Simple and Cmplex prting prcess. This update will require the IPMS manager t New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 34 f 127

35 generate a prted number change file which is t cmply with the structure shwn in Appendix H, Special Prjects Uplad File Structure. (a) (b) (c) (d) A Special Prject necessitating update f IPMS wuld invlve a direct lad f Numbers r changes t the IPMS database, bypassing the Prt prcesses (i.e. the messages and SLA s) as they exist fr Simple and Cmplex Prt types. A Special Prject may invlve any cmbinatin f change f Service Prvider, change f Carrier and change f Dnr Carrier r any instance where IPMS needs t knw abut changes in rder t either maintain netwrk call handling integrity, r allw future Prts n the affected Numbers 6 This type f update must nt be used fr Custmer initiated Prts. Special prjects shuld be clearly defined upfrnt by means f a terms f reference. This dcument shuld clearly utline and include the scpe f the prject, impacted stakehlders, rles and respnsibilities and a schedule f events. The scpe shuld be agreed prir t the start f the prject. It will be the rle f the NP C-rdinatr t ensure the Terms f Reference template is cmpleted and t manage the prject frm start t end. 9.2 All LMNP parties have a respnsibility t fully disclse t the NPUG, any planned wrk n internal systems which interface t IPMS r as may enable third parties, such as resellers, t prvide prting capabilities. The NPUG has a respnsibility t ensure a cnsistent custmer experience (ref clause 1.1 f this Manual). T ensure this cnsistency, they may implement gvernance in a manner similar t that f a Special Prject. 9.3 Third party updates may be implemented: (a) Updates shall be implemented thrugh the Special Prject migratin file. Obligatins 9.4 As the SLA s defined in the LMNP Terms d nt apply t the Special Prject event, the fllwing bligatins shall apply: (a) (b) The initiating party must prvide a minimum ntice perid f 20 Business Days prir t the generatin f the Terms f Reference ntificatin t all parties t the Number Prtability Determinatin. Special Prject timelines are t be develped with all parties impacted by the Special Prject, wrking in gd faith n an individual prject basis. This ntwithstanding, any party unable t fulfil the requirements f the Terms f Reference within 40 Business Days f its frmal ntificatin shall frmally ntify the NP C-rdinatr f this. 9.5 The additin f new Parties t IPMS will be cmpleted in accrdance with the 3 mnth timeframe in the LMNP Terms. The additin f a reseller, r a change t 6 Per line set-up csts may be applicable New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 35 f 127

36 an existing Party s cnfiguratin, is nt subject t the same timeframe requirements in the Terms. All Parties will act in gd faith t implement a requested change in a timely manner. The Party requesting the change shuld have a reasnable expectatin f the time it will take t implement such changes. The fllwing is a guideline t help set expectatins fr cmmn changes, nting that each situatin will be different and will need t be reviewed n its wn merits: Apprximate Actin Required f ther Parties Time t Cmplete 2 weeks New Carrier-Service Prvider relatinship t be created between existing Carrier and existing Service Prvider 4 weeks New Service Prvider created within an existing Party, and an assciated new Carrier-Service Prvider relatinship created in a service area where the Party already perates (eg an additinal mbile Service Prvider added t an existing mbile Carrier) 6 weeks New Service Prvider created within an existing Party, and an assciated new Carrier-Service Prvider relatinship created, in a service area where the Party des nt already perate (ie adding a mbile service t a Party that has previusly been lcal nly). 8 weeks New Carrier created fr an existing Party, using existing intercnnectin methds 10 weeks New Carrier created fr an existing Party using new intercnnectin methds (eg new lcatins) 10. Objectives Service Level Expectatins and Operating Hurs 10.1 T prvide an understanding f the perating hurs fr each f the parties t the LMNP Terms and hw this impacts the Service Levels. Guidelines 10.2 The Service Level prvisins in Table 2, Appendix 1 f the Terms, in respect t Simple Prts and Cmplex Prts apply These are the guidelines fr Service Prvider and Carrier Extended Hurs f Business fr Simple and Cmplex Prt Categries. (a) (b) Extended Hurs During Wrking Hurs the Service Levels defined in the LMNP Terms shall apply. Fr Prt Request activities prcessed during hurs utside f Wrking Hurs the same Service Level timeframes stated in the Terms are applicable but the level f cmmitment t meet these Service Levels may be reduced. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 36 f 127

37 10.4 Any Prting activity between GSP s and LSP s may be perfrmed utside Wrking Hurs, as agreed t in Bilateral Agreements. Examples include: (a) (b) Simple Mbile Prts carried ut in stres that are pen during weekends and late nights Large business Custmers requesting after hurs cutver t reduce business risk Relaxed Service Level bligatins may be agreed between parties fr Extended Hurs f Business The fllwing cnstraints shall apply t any Bilateral Agreements fr Extended Hurs f Business (a) (b) (c) The "Simple Mbile" prt categry Prts wuld have RFS windws set within standard hurs f business as specified in the Terms i.e. 8 and 5 but the IPMS is set up with a 3 hur 50 minute grace perid which wuld allw prt activatins t take place up t, but nt beynd, 5pm unless mutually agreed. (The grace perid increases the windw in which the prt can be activated.) Cmplex Mbile Prts wuld be prvisined in a similar manner but a 15 hur IPMS grace perid will allw any "Cmplex" prt categry t have RFS windws set 24 x 7. These cnstraints may be subject t review as a result f the current PCR Change Prcess. Third Party Update Phase 10.7 By definitin, third party updates are required by all participating Carriers. They are required nce a Prt is deemed by the GSP, GC and LC t be cmplete The synchrnisatin f third party updates is critical t ensure the Custmer experience during the Prt is nt adversely impacted Parties t the Determinatin are t use best endeavurs t implement 3rd party updates at least hurly, between the hurs f 05:00 am and 03:00 am, seven days per week. Scenaris / Examples Even thugh Service Levels / Wrking Hurs gvern respnse time maximum perids, IPMS will be available and will prcess requests n a 24 x 7 basis, except in agreed dwntimes allwed within the cntract agreed between the Systems Administratr and the TCF The Prt Request phase is t establish agreement between the GSP and LSP and Custmer t allw Prting t ccur, s there is n Netwrk dependency, therefre there is n issue with Service Level spanning multiple calendar days. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 37 f 127

38 10.12 Prt Activatin has a Netwrk dependency and therefre the Service Level shuld nt span mre than ne single Wrking Day. Explanatry nte The RFS Date / Time will be the start f the Prt Activatin windw Fr a Simple Mbile Prt the expectatin t be set with the Custmer shuld be that the Prt will be cmpleted within 30 minutes fllwing the RFS Date / Time The activatin windw will be 4 Wrking Hurs fr all ther Prts Parties must adhere t the Service Levels at all times; this includes prts invlving third party resellers. If a third party reseller is slw t respnd t a Prt Request r ther prting step, the party acting n their behalf inside IPMS must still take the apprpriate actin required within the time allwed by the Service Level. It is up t the party acting within IPMS t manage their third parties and ensure that prting cntinues in accrdance with the Service Levels, regardless f delays r cmplexities caused by third parties Fr further explanatin f the Service Levels, refer t Appendix F. Agency & Special Services Requirements (Emergency Services) 11. Agencies requesting infrmatin under legal cmpulsin 11.1 "Legal Cmpulsin" is defined as any legal bligatin t prvide call tracing services, Custmer infrmatin, call recrds, r technical data fr Gvernment Agencies r where necessary in public safety situatins It is each Service Prvider/Carriers respnsibility t have internal prcesses in place t satisfy any legally cmpelling request that is served n that Service Prvider r Carrier. Public Safety - Emergency Services 11.3 The Plice r ther gvernment agencies may require urgent access t Custmer details frm the Service Prvider r Carrier under certain circumstances (e.g. threat t life, public safety). The Service Prvider and Carrier must have internal prcesses in place t prvide cverage t deal with these requests in a timely manner t cmply with its wn bligatins Where there is any impact t 111 as a result f wrk undertaken - ensure that the 111 emergency service is always prtected by alternative rute. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 38 f 127

39 Access t the IPMS by Gvernment Agencies 11.5 Sectin 4.5 f the LMNP Terms states that: Gvernment agencies (including withut limitatin emergency services such as the Plice and Fire Service) and third parties will be entitled t access the IPMS fr infrmatin purpses nly in the cnduct f their lawful peratins. The terms n which these parties will be granted access will be specified by the TCF and set ut in an IPMS access agreement between the TCF and the party seeking access Currently, this requirement has been satisfied by allwing Gvernment agencies and third parties t access IPMS using the reprt dwnlad web service and dwnlad IPMS reprts such as the Full Prted Number register reprt. As at June 2007, n Gvernment agency had taken advantage f this capability. 12. Objectives Custmer Fault Handling and Testing Prcedures 12.1 T identify hw Carriers / Service Prviders will act in the event f a Prted Number fault and prvide prcesses and requirements fr the management/reslutin f Netwrk faults invlving Number Prtability. Guidelines 12.2 Each Carrier will prgress their wn fault handling within their wn Netwrk. Each Service Prvider is respnsible fr their Custmer base and as such will have cntrl f any service fault reprts The specific inter-carrier prcess fr Number Prtability fault handling and reslutin are t be develped by Carriers as amendments t existing Bilateral Agreements regarding fault handling If the lcatin f the fault is determined t be in the Hst Carrier netwrk then respnsibility fr management and repair f the fault shall be with the Hst Carrier If the lcatin f the fault is determined t be in the Dnr Carrier netwrk then respnsibility fr management and repair f the fault shall pass t the Dnr Carrier The party respnsible fr the fault shall repair the fault within the clearance times given in the tables at sectins t (inclusive) unless the fault has n impact n services prvided t the ther party under this agreement. If temprary repairs are made, the ther party shall be infrmed and agree t the estimate f the timescale t full repair and the expected impact n the service. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 39 f 127

40 12.7 The party respnsible fr fault repair shall infrm the ther party using an agreed cmmunicatin frmat as sn as the fault is reslved The Hst Carrier and the Dnr Carrier will agree all service cntacts (refer TCF Website Standard Testing / Fault Analysis 12.9 Befre reprting a fault t anther Carrier, each Carrier must ensure that the: (a) (b) (c) (d) (e) Prt Activatin time fr Prting has expired Custmer Equipment is crrectly terminated Dial tne r an utging call capability is available n the Gaining Carrier service Test calls frm within the Gaining Carrier telecmmunicatins Netwrk are successful; and Test calls frm ther Carrier Telecmmunicatins Netwrk are unsuccessful Each Carrier whilst diagnsing a fault must use sufficient analysis t identify which Carrier Telecmmunicatins Netwrk may be causing the fault and then direct the fault reprt t the nw identified Carrier in the first instance. Additinal Testing / Analysis fr Cmplex Prts In the case f a fault with a Cmplex Prt, the Gaining Carrier must cnduct the Standard Tests hwever the Gaining Carrier des nt need t test all Numbers if there are mre than 10 Numbers assciated with a service which are in a sequential Number range In the case where there are mre than 10 sequential numbers, the Gaining Carrier must apply Standard Tests fr the fllwing Numbers: (a) (b) (c) the first Number in the range the last Number in the range a selectin f Numbers in the range representing an even spread f the range, such that five Numbers r 3% f the range (which ever is greater) are tested, ensuring that testing includes a minimum f three Numbers in each 100 Number Blck. Guide t LMNP Fault Management Timetable Further evaluatin f the impact n existing BAU fault management prcesses. Each needs t be checked against existing Bilateral Agreements This sectin is intended t prvide guidelines fr inter-cmpany fault reslutin Service Level Agreements. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 40 f 127

41 12.15 Fault pririty levels are defined as fllws: (a) Upn initial cntact between the parties invlved in the fault prcess, the party receiving the fault will set the initial pririty, and cnfirm status and pririty t the ther parties, bserving respnse times as specified in the Service Level table in this sectin. Pririty Fault 1 Critical impact, e.g. Cmplete utage f a service r lss r severe degradatin f inter-carrier exchange capability. 2 One r mre Custmers are experiencing partial lss f service t access either inbund r utbund calling (nt bth) impacted 3 All ther faults Either party may request reclassificatin f a pririty 2 fault t pririty 1- this reclassificatin must be agreed between the parties The quality f service parameters apprpriate t the fault management prcedure is specified belw. Perid Title Respnse Time Reslutin Time First Escalatin Time Secnd Escalatin Time Value Time between an intercmpany fault reprt and the first respnse frm the Service Prvider/Carrier that clearly indicates expected reslutin time, prgress infrmatin and fault diagnses. Time between fault reprt and fault reslutin. Time between the Fault initially being reprted and the relevant escalatin cntact pint first being infrmed. Time between an intercmpany fault being reprted t the first escalatin pint and the relevant secnd escalatin pint cntact first being infrmed. Nte: a fault may be escalated if the agreed reslutin time is nt met, r updates are nt received within the agreed timeframes The service parameter values fr all services are specified belw: (a) The Service Levels in the table belw relate t Business Days and Wrking hurs. After hurs fault Service Level timeframes t be checked thrugh Bilateral Agreement prcess. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 41 f 127

42 Respnse Time Reslutin Time First Escalatin Time Secnd Escalatin Time Pririty 1 Pririty 2 Pririty 3 < 30 min < 120 min < 2 days 4 hurs 8 hurs 3 days 2 hurs 8 hurs 3 days 4 hurs 2 days 5 days New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 42 f 127

43 13. Prting Cntact and Escalatin Pints This sectin prvides guidelines n hw and when t cntact ther parties in regards t Prting. Cntact Prcedures 13.1 Cmmunicatin (i) Cmmunicatin shuld include: Initiatr f the cntact Cntact at ther prvider Methd f cntact Minimum infrmatin t supply (requestr) Optinal infrmatin t share Respnse time First level cntact (refer t cntact list) First level cntact (refer t cntact list) shall be the primary methd f cntact between parties Phne calls shuld be used where Service Levels are shrt (e.g. simple mbile) r the issue is critical (e.g. emergency return) Phne cntact shuld be fllwed up by the initiatr with an t cnfirm the issue discussed and the agreed utcme. SOM Phne number Reasn fr cntact and actin requested Pririty f request Cpy f Custmer Authrisatin frm Custmer name, address Further infrmatin as apprpriate Reslutin during initial cntact where pssible. Otherwise respnse within 2 hurs by the cntacted party t prvide an update n the request, and an estimated time fr reslutin where applicable. Different respnse times may apply utside f Wrking Hurs 13.2 Escalatin pints (ii) Escalatin pints fr Prting will be maintained n the TCF web site at New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 43 f 127

44 IPMS Fault Management 14.1 In the case f IPMS issues r faults, refer t Appendix B - IPMS Management. Capacity Frecasting Prcedures 15.1 If activity is planned utside the nrmal perating levels, reasnable ntice shuld be given t all ther parties Refer t sectin 18 f the Netwrk Terms fr further detail. Capacity frecasting shall be agreed in Bilateral Agreements, as required fr exceptinal Prting vlumes. New Participants Prcedures 16.1 The Number Prtability Determinatin identifies a limited number f Access Seekers and Access Prviders; cmpanies that have been determined t be bund by that Determinatin. Appendix H f the Manual describes hw new parties wh wish t participate in Number Prtability need t wrk with the TCF and the parties t the Number Prtability Determinatin t prvide a satisfactry Prting experience fr Custmers The TCF may, at their discretin, appint a third party t manage the intrductin f the new entrant as a prgramme f wrk and the existing participants and new entrant will wrk in gd faith t facilitate the new entrant being able t Prt Numbers Existing Parties t the Number Prtability Determinatin must review internal Prting prcesses and systems t incrprate the new Service Prvider. 17. Enfrcement Agency Prcedures 17.1 The Enfrcement Agency (a) (b) The Enfrcement Agency is a persn nminated by the TCF and apprved by the Cmmerce Cmmissin r, where the TCF has failed t nminate a persn, a persn appinted by the Cmmerce Cmmissin. The Enfrcement Agency is envisaged in clause 14.5 f the Netwrk Terms and clause 7.4 f the LMNP Terms. The Enfrcement Agency is nt a specifically cnstituted bdy, but rather will be appinted n an ad hc basis and will perfrm its functins in accrdance with the pwers and prcesses set ut in this part f the Manual. (c) The rle f the Enfrcement Agency under the Netwrk Terms and the LMNP Terms (cllectively the Terms ) is t mnitr and as required by the Terms measure and enfrce cmpliance with: New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 44 f 127

45 (i) (ii) the Equivalent Service prvisins in accrdance with clause 14.4 f the Netwrk Terms (the Equivalent Service Criteria); and the specified service levels set ut in clause 7.4 and Table 2 f the LMNP Terms (the LMNP Service Levels). (d) Where necessary, the Enfrcement Agency will cnduct audits f Carriers (Audit Carriers) t assess cmpliance with the Equivalent Service Criteria and/r the meeting f LMNP Service Levels. Fr the purpses f sectin 0 where the cntext requires, Audit Carrier shall include reference t an Audit Carrier under the Netwrk Terms and an Audit IPMS Client under the LMNP Terms. (e) The Enfrcement Agency may cnduct such audits itself, r appint an independent expert t cnduct the audit n its behalf. Reference t Enfrcement Agency shuld be read t include any duly appinted independent expert. (f) An expert appinted by the Enfrcement Agency is t be independent f bth the Audit Carrier and any Carrier whse cmplaint t the Enfrcement Agency initiated the Audit. An expert will be deemed independent f a Carrier if they have nt (and n member f their staff invlved with the audit have) been retained by that Carrier n any matter within the previus three (3) year perid. (g) The pwers and prcesses set ut here are additinal t, and nt exclusive f, any ther rights a Carrier may have under the Telecmmunicatins Act, at law r in equity. In particular, nthing in this part in any way prevents a party frm, in accrdance with sectin 61 f the Telecmmunicatins Act 2001: (i) (ii) exercising its right t enfrce cmpliance with the Equivalent Service Criteria; exercising its right t enfrce cmpliance with the LMNP Service Levels; r. (iii) exercising its right t generally enfrce the Cmmerce Cmmissin LMNP Determinatin. Pwers f the Enfrcement Agency 17.2 Carrier Nn Cmpliance (a) Where a Carrier cmplains in writing t the Enfrcement Agency that anther Carrier is either nt cmplying with the Equivalent Service Criteria r nt meeting the required LMNP Service Levels, the Enfrcement Agency may initiate an audit f the Carrier in questin. The Enfrcement Agency New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 45 f 127

46 may nly cmmence an audit where a cmplaint is supprted with evidence that, in the view f the Enfrcement Agency, establishes reasnable grunds f nn-cmpliance t cmmence an audit. The Enfrcement Agency has the discretin t decline t cnduct an audit if it reasnably cnsiders that the breach cmplained f is nt f a significantly material nature t warrant an audit f the relevant Carrier r if the relevant Carrier satisfies the Enfrcement Agency that it has remedied the breach. (b) The purpse f undertaking an audit is fr the Enfrcement Agency t assess and determine whether, as the case may be, the Audit Carrier has: (i) (ii) cmplied with the Equivalent Service Criteria; r met the LMNP Service Levels; subject t any exemptins granted t the Audit Carrier in respect f the Equivalent Service Criteria r the LMNP Service Levels. (c) If, prir t the cmmencement f an audit an Audit Carrier accepts that it has nt cmplied with the Equivalent Service Criteria r the LMNP Service Levels, the Audit Carrier may request that the Enfrcement Agency waive the requirement fr an audit and mve directly t whatever enfrcement actin is apprpriate under the Terms. (d) A Carrier wh having been audited is fund t cmply with the Equivalent Service criteria cannt be subject t anther Enfrcement Agency audit t assess cmpliance with the same Equivalent Service Criteria within the six (6) mnth perid fllwing the cmpletin f that audit. (e) A Carrier wh having been audited is fund t cmply with the LMNP Service Levels cannt be subject t anther Enfrcement Agency audit t assess whether it has met the same LMNP Service Levels within the six (6) mnth perid fllwing the cmpletin f that audit. (f) Where the Enfrcement Agency has cmmenced r prpses t cmmence an audit f a Carrier, that Carrier must advise the Enfrcement Agency f any exemptin granted t it by the Cmmerce Cmmissin relevant t the cmmenced r prpsed audit. (g) Where the Audit Carrier is exempted frm cmplying with sme f its bligatins either under the Netwrk Terms in respect f the Equivalent Service Criteria r under the LMNP Terms in respect f the LMNP Service Levels and it is thse bligatins that wuld be the subject f the audit the Enfrcement Agency will suspend any audit r sanctin f the Audit Carrier. Any such suspensin will be: New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 46 f 127

47 (i) (ii) fr as lng as, and t the extent that, the exemptin exempts cmpliance with the Equivalent Service Criteria r the meeting f LMNP Service Levels; and ntified t all interested parties by the Enfrcement Agency Where requested by the bard f the TCF the Enfrcement Agency may perfrm an investigatry and reprting functin in respect f the enfrcement f Carriers and Service Prviders bligatins under the IPMS Access Agreement prvided t thse parties by the TCF. Audit Prcedures 17.4 Ntice Perid t any Carrier f Audit (a) (b) (c) (d) (e) The Enfrcement Agency shall give nt less than five (5) Business Days prir written ntice t any Carrier f a decisin t undertake an audit f the Audit Carrier. The Enfrcement Agency shall specify in reasnable detail thse aspects f the service and dcumentatin it prpses t audit and will advise the Audit Carrier wh is t undertake the audit. Any written ntice f the Enfrcement Agency s intentin t cnduct an audit must be addressed t the General Cunsel/Chief Legal Advisr f the Carrier in questin. The Audit Carrier shall have five (5) Business Days t agree t the audit, accept the allegatin f nn-cmpliance with the LMNP Service Levels r the Equivalent Service Criteria and request that the audit nt be undertaken, r submit in writing t the Enfrcement Agency why the audit shuld nt be undertaken. The Enfrcement Agency will cnsider any submissin made in gd faith and will then advise the Audit Carrier within five (5) Business Days whether r nt an audit will be undertaken. If n submissin is received frm the Audit Carrier, r the Audit Carrier advises that it agrees t the audit, the Enfrcement Agency may, but is nt required t, undertake the audit. If the Enfrcement Agency decides t undertake an audit then the Enfrcement Agency shall: (i) (ii) prvide t the Audit Carrier, nt less than five (5) Business Days ntice f the date f the cmmencement f the audit; prvide the Audit Carrier a written list f thse dcuments, r such descriptins f the type f dcuments, it wishes the Audit Carrier t prvide t it. Such dcuments must in the Enfrcement Agency s view be necessary t assess whether the Audit Carrier has cmplied with, as the case may be, the Equivalent Service Criteria r the LMNP Service Levels. Withut limitatin, this may include dcumentatin pertaining t thse dcuments, recrds, written practices, data and ther dcumentatin within its cntrl that is reasnably necessary t cmplete an audit; and New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 47 f 127

48 (iii) use its reasnable endeavurs t cnduct the audit in a manner s t prvide minimal disruptin t the day-t-day business activities f the Audit Carrier. (f) Within 10 Business Days f receiving a written request frm the Enfrcement Agency fr dcuments r such lnger perid as is reasnably required by the Audit Carrier given the nature and vlume f the dcuments requested, the Audit Carrier must supply the Enfrcement Agency with the requested dcuments within its cntrl and that are reasnably necessary t cmplete an audit. (g) The Audit Carrier will c-perate fully with the Enfrcement Agency t facilitate a timely audit prcess. Such c-peratin extends t an Audit Carrier respnding t any reasnable written questins frm the Enfrcement Agency seeking clarificatin n any f the dcuments supplied t the Enfrcement Agency. (h) Where an Audit Carrier fails t supply any requested dcument(s) it must prvide reasns t the Enfrcement Agency. (i) An Audit Carrier is under n bligatin t prvide the Enfrcement Agency with any dcumentatin fr which privilege is claimed r in respect f which the Audit Carrier wes bligatins f cnfidentiality t a third party and that third party des nt cnsent t the disclsure. (j) Failure by an Audit Carrier t supply the Enfrcement Agency with requested dcumentatin r respnd t written questins clarifying such dcumentatin will be deemed t cnstitute a nn-cmpliant audit, unless such requests and/r questins are nt reasnably necessary t cmplete an audit. Within 20 Business Days f receiving such requested dcuments, the Enfrcement Agency will prvide a cpy f the Audit Reprt t the Audit Carrier setting ut its determinatin (being nly a psitive r a negative determinatin) n whether the Audit Carrier has either cmplied with the Equivalent Service Criteria r met the Service Levels in the LMNP Terms. Such an Audit Reprt will detail the reasns behind the Enfrcement Agency s determinatin. (k) The Enfrcement Agency will prvide the Audit Carrier five (5) Business Days t cmment n any audit reprt prvided t it befre a final audit reprt is issued. The Enfrcement Agency will frward a cpy f the final audit reprt t all Carriers wh were a party t the Number Prtability Determinatin. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 48 f 127

49 17.5 Cnfidentiality (a) All cnfidential infrmatin btained by the Enfrcement Agency in cnducting an audit must be kept cnfidential t the Audit Carrier and the Enfrcement Agency. Audit Cst Allcatin 17.6 Audit Csts (a) The Audit Csts assciated with cmpleting an Audit Reprt will cmprise f bth: (i) (ii) The Enfrcement Agency s reasnable direct csts in respect f the audit (including auditing and legal fees); and Such csts f the Audit Carrier in respect f time invlved in assisting the audit as submitted by the Audit Carrier t the Enfrcement Agency and determined by the Enfrcement Agency t be fair and reasnable. (b) The Enfrcement Agency is respnsible fr determining and ntifying the csts assciated with cmpleting an Audit Reprt ( Audit Csts ) within 10 Business Days frm when it determines the csts f the Audit Carrier as submitted are fair and reasnable. (c) Such Audit Csts as determined by the Enfrcement Agency will be payable by: (i) (ii) the Audit Carrier, where an Audit Reprt cncludes that the Audit Carrier has nt cmplied with the Equivalent Service Criteria set ut in the Netwrk Terms r the LMNP Service Levels set ut in the LMNP Terms, (whichever were alleged t have been breached) irrespective f whether r nt the Audit Reprt was undertaken due t a request frm anther Carrier; r the Carrier at whse request the Audit Reprt was cmpleted, where the Audit Reprt cncludes that the Audit Carrier has cmplied with the Equivalent Service Criteria set ut in the Netwrk Terms r the LMNP Service Levels set ut in the LMNP Terms (whichever were alleged t have been breached). (d) Where an Audit Reprt was cmpleted therwise than due t a request f a Carrier, each f the Enfrcement Agency and the Audit Carrier will bear their wn csts in the event the Audit Reprt cncludes that the Audit Carrier has cmplied with the Equivalent Service Criteria set ut in the Netwrk Terms. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 49 f 127

50 (e) An Audit Carrier is entitled t be reimbursed its csts by the Enfrcement Agency where: (i) (ii) The Audit Reprt cncludes that it has cmplied with the Equivalent Service Criteria set ut in the Netwrk Terms r the LMNP Service Levels set ut in the Terms(whichever were alleged t have been breached) ; The Enfrcement Agency has received payment in full f the Audit Csts frm the Carrier at whse request the Audit Reprt was cmpleted; and (iii) The Enfrcement Agency has determined that the csts f the Audit Carrier are fair and reasnable. (f) All amunts payable t the Enfrcement Agency under this part must be paid in full t the Enfrcement Agency within 30 days frm when the Service Prvider r Carrier (as applicable) is ntified f the amunt payable. Failure t pay mnies due will be treated as a breach f the Terms. (g) Any reimbursement due f an Audit Carrier s csts must be received within 30 days frm receipt in full f the Audit Csts by the Enfrcement Agency. (h) Where a payment is due and nt received in full by the Enfrcement Agency by the due date, the Enfrcement Agency is entitled t interest n the amunt utstanding n a daily basis at the rate f the current 90 day bank Bill Rate plus 4% Appendix J utlines which service levels are actively mnitred by the Enfrcement Agent. 18. Issues Escalatin 18.1 All issues raised are t be entered int the NP Issues Register. The Issues Register will be reviewed mnthly at the regular meetings held by the Number Prtability User Grup and the Issue Register updated where necessary. If the issue is unable t be reslved by the NP User Grup r a party feels the issue is taking t lng t reslve, the issue can be escalated t the TCF Bard fr reslutin and if necessary further escalated t the Cmmerce Cmmissin. 19. System and Netwrk Outages 19.1 The Netwrk Terms utline the prcesses surrunding Netwrk Outages and an amendment t the LMNP Terms is prpsed t include the same fr system utages. Sectins a) t e) apply t system utages and Netwrk Outages. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 50 f 127

51 a) Subject t item (c) belw, in the event that a Carrier identifies that they require an utage in the Carrier s Netwrk r system that may affect LMNP, that Carrier must advise all Parties t the Determinatin via at least 5 Business Days befre the Planned Outage ccurs. Cntact details fr all Parties t the Determinatin in relatin t utages can be fund n the private sectin f the TCF website under Number Prtability. Parties t the Determinatin are given access t this webpage by cntacting the TCF Frum Administratr. If there is any change t the Planned Outage date r time the change must be advised t all Parties t the Determinatin via phne call and as sn as pssible. b) Carriers must prvide details f all Planned Outages (including any change t thse Planned Outages) t the TCF via 5 days prir t the Planned Outage and the TCF must ensure thse details are prvided n the TCF website and updated when there is any change. c) Ntwithstanding the abve, if a Carrier identifies that they require an utage in the Carrier s Netwrk r system that will impact their ability t perfrm Netwrk Updates, that carrier must advise all Parties t the Determinatin via at least 15 Business Days befre the Planned Outage ccurs. The backup date fr the Outage must be at least 10 Business Days after the riginal planned date. This is because: (i) (ii) This impact is greater than merely ne party being able t prcess their wn prting activity. An inability t perfrm Netwrk Updates will stp prting fr all parties as n Prts can be marked cmplete withut all Netwrk Updates being cmpleted. Prts cannt be started during the Planned Outage because an inability t cmplete Netwrk Updates will risk the custmer being withut a fully peratinal service while Netwrk Update remains utstanding. (iii) Other parties will have t reschedule third party cntractrs, internal service prvisining and reset custmer expectatins t wrk arund the utage. This takes extensive time and planning, requiring mre ntice. (iv) (v) Once the Planned Outage is cmplete there will be a surge in activity as parties catch up n the backlg; this activity needs t be prperly anticipated and managed. The backup date shuld be scheduled at least 10 Business Days after the riginal Planned Outage date t allw fr a large enugh windw fr prts t be mved frm the riginal Planned Outage date and nt caught by any slippage t the backup date. d) A TCF LMNP Outage address has been set up which shuld be used by Parties t the Determinatin t advise ther Parties f any New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 51 f 127

52 Planned r Unplanned Outages. When an regarding an utage is sent ut the subject line f the shuld indicate which envirnment the utage relates t ie. TEST, TRAIN, DEV r PROD. The TCF address will be ntified t the Parties frm time t time. At the date this peratins Manual was last amended the address was NP.Outages@tcf.rg.nz. e) Parties t the NP Determinatin are required t prvide the TCF with an address (and any changes t that address) t be used by ther Parties t the Determinatin t ntify that Party f any Planned r Unplanned Outages. Details f individual Carriers utage cntacts can be fund n the LMNP Outages/Faults Cntacts page which is n the private sectin f the TCF website. Parties t the Determinatin are given access t this webpage by cntacting the TCF Frum Administratr. These individual addresses are t be used fr any utage ntificatins if fr any reasn the TCF address is nt perating crrectly. 20. Call Readdress 20.1 Call Readdress is a netwrk capability between tw wrking numbers, each n a different Service Prvider s netwrk that allws ne t be diverted t anther. Call Readdress is n lnger available fr new cnnectins t Custmers and therefre ver time the numbers shuld diminish with the Prting alternative. There are tw types f Call Readdress that exist: Full Call Readdress and Partial Call Readdress. a) Full Call Readdress Full Call Readdress, is effectively an alternative name fr a dnr re rute scenari. Dnr re rute is a valid call frwarding service whereby endusers call the Custmer by dialling the listed number which is ruted t the dnr Carrier. The dnr Carrier then Call Frwards t the recipient netwrk with Called Party Number equal t HOC + Call Readdressed Number as shwn in the diagram belw. Scenari 1 Spark Custmer (A) dials Spark number that is diverted t VF Call frwarded t VF as HOC Spark Number New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 52 f 127

53 VF Terminates Call t (B) Spark Number cnfigured n VF switch t map t (B) Scenari 2 VF Custmer (A1) dials Spark diverted number VF intercepts call and terminates t (B) via Spark # mapped n switch When a Full Call Readdress Custmer riginates a call, their CLI is set t the Call Frwarded Number. Whilst this was a pre-number Prtability mechanism, Full Call Readdress required all calls nt prted t the riginating Carrier 7 t be sent t the dnr Carrier. As this scenari maps simply t the riginating Carrier lkup scenari, with its inherent advantages, Full Call Readdressed numbers have been migrated ver t the LMNP Prt prcess. b) Partial Call Readdress Fr Partial Call Re-address, the call frwarded Custmer is assigned tw numbers: ne number is their riginal number frm the dnr netwrk (the Call Frwarded Number ); the secnd number is a number frm the call frwarded r recipient Carrier netwrk (the Recipient Netwrk Number ). End Users can call the Partial Call Readdress Custmer by dialling either the Call Frwarded Number r the Recipient Netwrk Number. If the End User dials the Recipient Netwrk Number, the call is ruted directly t the recipient netwrk bypassing the dnr switch. The diagram belw illustrates tw call scenaris when an End User dials the Call Frwarded Number f a Partial Call Readdress Custmer: Scenari 1 Spark Custmer (A) dials Spark number prted t VF Call frwarded t VF as HOC VF# VF terminates call t (B) VF# e.g. 912 xxxx Scenari 2 7 Interceptins are in place t trap calls t numbers prted t the carrier riginating the call New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 53 f 127

54 VF Custmer (A1) dials Spark number prted t VF VF intercepts call and terminates t VF 912xxxx (B) c) Call Readdress Prcedures The Gaining Service Prvider (GSP) is t prvide all Custmer details including the number t be prted and the Partial Call Readdress number assciated t it. The LMNP Terms state it is the respnsibility f the GSP t prepare the Prt Request. The Prt Request must include the data required as per Appendix 1, table 1 f the LMNP Terms. Subject t clause f the LMNP Terms, the Lsing Service Prvider (LSP) is nt bliged t advise the GSP f additinal Numbers beynd thse included in the Prt Request (see clause (c) f the LMNP Terms). Hwever, when the LSP checks the Prt Request, subject t clause 8.1.7(e) f the LMNP Terms, the LSP enters its understanding f the details if they differ frm the infrmatin presented by the IPMS and this can include the additin r remval f Numbers fr a Multiple Number Prt (see clause 8.1.7(d) f the LMNP Terms). d) GSP Rules fr Partial Call Readdress The fllwing rules MUST then be adhered t by the GSP fr the successful apprval f Partial Call Readdress numbers t be prted via LMNP prcess. (a) (b) (c) (d) (e) Lad prt request with crrect LSP and Custmer a/c number. All Call Readdress assciated numbers t be prted must be shwn including numbers that may nt be required (i.e. bth VF and Spark); 8 Use checkbx and tick if specific numbers are "nt required"; Submit as per standard rules; IPMS will reject giving a reasn that a specific number requested is nt wned by the LSP specified. When this ccurs recnfirm that the LSP is crrect and tick the "Override Service Prvider" checkbx and resubmit; and In "Additinal Custmer Infrmatin" field please add "Call Readdress". 8 Where Partial Call Readdress numbers are nt knwn by the custmer, the custmer shuld in the first instance, seek the infrmatin frm the LSP. The custmer may als authrise the GSP t seek this infrmatin n their behalf frm the LSP wh is t assist in prviding it thrugh an agreed escalatin prcess. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 54 f 127

55 Scenari 1 Custmer has a call re addressed number and a dnr number. They want t prt the readdressed number and relinquish the dnr number. IPMS Prt Request Structure GSP LSP Lsing Service Prvider (eg TCL) Prt request ut accunt number (TCL) Lsing CarrierA PCRA Dnr Number Nt Required (Relinquished)* Prt request t IIOMS Gaining Service Prvider(eg ihug) Lsing CarrierB PCRA number Prting Business Relatinships Lsing CarrierA Carrier (TCLnnn) Call Frward Lsing CarrierB (eg TNZPSTN) Gaining Carrier (eg ihug ) Dnr Number eg TCL Call Readdressed Number eg TNZPSTN Custmer lines accessed by Dnr carrier numbers and call re addressed numbers Pst Prt Status Service Prvider TCL IPMS Prted Number Register Number Prted > IHug Service Prvider ihug Carrier (TCLnnn) * Carrier ihug N Billing Relatinship with custmer Number 1 Prted New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 55 f 127

56 e) Custmer has requested that ne number remain with the existing netwrk? If Custmer requests t remain with bth GSP and LSP by splitting the Call Readdress related numbers this must be cmmunicated thrugh standard escalatin prcess befre submitting request fr validatin Scenari 1 Custmer has three Call Readdressed numbers and three dnr numbers. They want t prt tw f the readdressed numbers and retain the three dnr numbers and ne f the call readdressed numbers. GSP advises LSP that prt request requirres 3rd call readdressed number t remain with LSP IPMS Prt Request Structure GSP NOTE: If a line is t be retained yu simply d nt include the number in the Prt request Lsing Service Prvider (eg TCL) Prt Request ut f IPMS LSP accunt number Lsing CarrierB (eg TNZPSTN) Prting Call Readdressed numbers 1&2 - Prt Request t IPMS Gaining Service Prvider(eg ihug) Business Relatinships Carrier (TCLnnn) Retained Retained Retained Call Frward Lsing CarrierB (eg TNZPSTN) Retained Prting Prting Number 3 Number 2Call Readdressed Number 1 Call Readdressed Call Readdressed Gaining Carrier (eg ihug ) Custmer lines accessed by 3 Dnr carrier numbers and 3 call re addressed numbers New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 56 f 127

57 Pst Prt Status Service Prvider TCL IPMS Prted Number Register Number 1 Prted > IHug Number 2 - Prted > ihug Service Prvider ihug Carrier ihug Carrier TCLnnn Lsing CarrierA (eg TNZPSTN) Call Frward Number 3 Call Readdressed Number 1 Prted Number 2 Prted Custmer lines accessed by 3 Dnr carrier numbers and call re addressed number 3 f) Call Readdressed prts invlving resellers Where the LSP is a reseller and the prt request includes the prting ut f resld Partial Call Readdressed numbers, the whlesaling cmpany is t ensure that business prcesses are in place whereby the reseller is able t gain access t the Partial Call Readdress number infrmatin. This is applicable t tw scenaris: Where the GSP has tld the Custmer t apprach the LSP (reseller) t gain the necessary Call Readdress infrmatin. Where the reseller is bth LSP and GSP ie change f Carrier, n change f Service Prvider fr prts invlving Call Readdressed numbers. Where the LSP is a reseller, the apprpriate IPMS Carrier/Service Prvider relatinships are t be in place such that Prt Request f the call readdressed number is validated by IPMS withut the need fr invking the SP Override functin in IPMS. g) Custmer has requested t prt numbers that are Call Readdressed and nn-call Readdressed? IPMS SOM requests must nt cntain bth Call Readdressed and Nn- Call Readdressed lines. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 57 f 127

58 New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 58 f 127

59 Appendix A. Bilateral Agreement Check List The purpse f this sectin is t prvide an indicative list f the items which, eventually, wuld need t be discussed and apprved in the Bilateral Agreement between tw Service Prviders wh are parties t the LMNP Terms. LMNP BILATERAL DISCUSSION KICK-OFF QUESTIONNAIRE OVERVIEW In a Number prtability envirnment changes are required t the traditinal way in which calls are ruted frm riginating Carriers t terminating Carriers. Fr vice services, this applies t lcal, natinal, fixed-t-mbile, mbile-t-fixed, mbile-tmbile, incming and utging internatinal and ther calls invlving lcal r mbile numbers....pg 4 f Netwrk Terms fr Lcal & Mbile Number Prtability in New Zealand [ ] This dcument is intended t be used by New Zealand telecmmunicatins netwrk peratrs t initiate bilateral technical negtiatins with ther netwrk peratrs aimed at facilitating agreement abut the call handling interwrking arrangements t be used in the Lcal and Mbile Number Prtability (LMNP) envirnment. Interwrking arrangements between netwrks will need t specify which f the several ptins allwed fr in the Netwrk Terms will be implemented by netwrk peratrs fr handling calls passed acrss the bundaries between their netwrks when Number Prtability is peratinal. Specifically, each netwrk that riginates calls, r transits tll bypass calls, must either: Perfrm a call-by-call lkup f a Number Prtability database t determine whether a called number is Prted, and if it is Prted, determine the Recipient Netwrk (identified by the 011xn7 Handff Cde (HOC) that nw hsts the number, and then rute the call twards that netwrk by appending the HOC t the Called Party Number, OR Pass the call t anther netwrk which is delegated t perfrm all r part f the abve functin n its behalf. In this case there are further ptins allwed by the Netwrk Terms that must be selected. These cver the frmat f the Called Party Number signalled with the call, and whether the call is t be nward-ruted by the delegated netwrk, r released fr Query n Release (QOR) actin r fr Redirectin actin by the riginating (r transit) delegating netwrk. In additin, netwrk peratrs need t cnfirm ther aspects f LMNP call handling such as default call ruting under abnrmal circumstances such as database failure, and methds f prtecting the netwrk against call recirculatin. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 59 f 127

60 USING THE TEMPLATE This template is designed as a tl t help netwrk peratrs implement LMNP. It has been drafted as a guideline nly and is nt cmpulsry. The infrmatin cllected frm this questinnaire will be treated as cnfidential between the parties and will nt be disclsed t any ther party, unless such disclsure: is agreed t by the parties; r is required by law. The infrmatin is intended t be used as an input t bilateral negtiatins t determine the necessary changes t call handling functinality required t implement LMNP. The agreed netwrk arrangements will then be dcumented and included in a revised intercnnectin agreement between the netwrk peratrs. Terminlgy used in this dcument is in accrdance with the reprts LMNP Terms and Netwrk Terms dated NOTES ABOUT THE QUESTIONNAIRE Q1 Q4: relate primarily t yur netwrk acting as a Recipient Netwrk hsting numbers Prted frm ther netwrks, and will nly be applicable if yu prvide a (terminating and riginating) lcal service t Custmers. The infrmatin will enable ther netwrks t set up call ruting data required t deliver calls t numbers Prted int yur netwrk. Q2: Actual allcatin f HOCs is dne via the Number Administratin Deed (NAD Mst Carriers are expected t have a single 011xnt (t=7, 8, r 9) value assigned, hwever sme are prpsing t use multiple cdes where they supprt tw r mre distinct netwrks. Separate HOCs are expected fr fixed and mbile applicatins perated by the same carrier. Q3 & Q4: This infrmatin will assist with cnfirming that call recirculatin cannt ccur in abnrmal situatins. Q5 & Q6: indicate whether yur netwrk will cnsult a Number Prtability database itself t determine call ruting [case (a)], r will delegate this functin t anther netwrk by ruting calls t that netwrk withut first cnsulting a database [case (c)]. Case (b) is a mixed case where yur netwrk checks sme number ranges, and delegates checking ther number ranges t anther netwrk. Fr cases (b) and (c) this infrmatin in cnjunctin with Q7 will enable ther netwrk peratrs t ffer t act as a delegated netwrk t cnsult their Number Prtability databases n yur behalf. Nte that nly Custmers lcal (fixed netwrk) and mbile numbers are able t be Prted under LMNP. Therefre n changes are required t the ruting f calls t numbers delivered n the intercnnect bundary in ther frmats (e.g. 0800, 0900, 010, 111 etc.). Q7 & Q8: This infrmatin will enable the netwrk(s) with which yu are directly intercnnected t set up call ruting data t transit t the relevant Recipient Netwrks calls destined t Prted (and nn-prted) numbers that have been received frm yur netwrk. NOTE that the descriptins 0a(2-8) and 0A9 are typical f the ranges described, but nt exhaustive. Q9: cvers the details f call handling in the situatin where yu intend t delegate Number Prtability database cnsultatin t anther netwrk. It will need t be cmpleted as an New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 60 f 127

61 iterative prcess in cnjunctin with the delegated netwrk; therefre it may nt be pssible t cmplete sme parts f Q8 n the initial pass. Nte that the delegated netwrk [identified in Q9(c)] des nt necessarily need t be directly intercnnected with yur netwrk. By using the 011xn8 and 011xn9 HOCs t identify the delegated netwrk, calls can be ruted via a transit netwrk [identified in Q9(a)] (which will nt cnsult the database) t the specified delegated netwrk (which will). Where the delegated netwrk is directly cnnected t yur netwrk the use f a HOC is ptinal if the default actin is fr the delegated netwrk t cnsult the database fr all incming calls n a given incming rute (as will be the case fr internatinal incming calls, fr example, because they will never include a HOC). In this situatin there is n need t change the existing called party number frmat passed between the delegating and delegated netwrks. 9(d) is used t identify which f three call ruting mechanisms allwed fr by the LMNP Terms (Onward Ruting, Query n Release [QOR] r Redirectin) yu wish t perate in cnjunctin with the delegated netwrk. If QOR r Redirectin are t be used there will need t be further detailed technical discussins as these functins are nt supprted in the PTC331 N.7 Signalling standard currently used fr netwrk intercnnectin in New Zealand. Q10: This infrmatin will assist with cnfirming that recirculatin cannt ccur in abnrmal situatins. Q11 & Q12: This infrmatin will advise ther netwrks whether yur netwrk can act as a delegated netwrk and cnsult a Number Prtability database n anther netwrk s behalf, and if s, the specific methd(s) f call ruting available. Q13 & Q14: This infrmatin can be used t prgress the reslutin f issues cncerning gegraphic-rigin based ruting in the LMNP envirnment. Carrier Name Cntact Persn Cntact address/telephne Date questinnaire cmpleted Q QUESTION ANSWER (please as apprpriate) 1 Will yur netwrk act as a Recipient Netwrk fr Prted numbers (i.e. will yu be, r hst, ne r mre Gaining Service Prviders)? 2 What 011xn7 Hand-ff Cde(s) (HOC) will yur netwrk accept as a prefix t the called party s natinal number with incming calls t Prted Custmers hsted n yur netwrk? Please insert HOC values and descriptin if mre than ne HOC is used NOTE: The 011XN7 HOCs are allcated by the NAD (a) NO g t Q4 (b) YES g t Q2 HOC Cmment New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 61 f 127

62 Q QUESTION ANSWER (please as apprpriate) - g t Q3 3 What actin will yur netwrk take if it receives a call frm anther netwrk with the called party number prefixed with ne f yur 011xn7 HOCs (frm Q2), but cannt terminate the call because the number range is nt installed r the number is nt allcated t a Custmer n yur netwrk? (i.e. ther netwrk s database is nt up-t-date) (a) always release the call (Cause Value = ) (b) ther (please describe) NOTE: T prevent any pssibility f recirculatin yur netwrk must NOT change r delete the received HOC and nward-rute the call! - g t Q4 NB the Cause Value in questin 3(a) is the Cause Value sent ver the intercnnect bundary. 4 What actin will yur netwrk take if it receives a call frm anther netwrk with the called party number in the frmat 0+NN, where NN is a number range allcated t yur netwrk, but cannt terminate the call because the number is nt allcated t a Custmer n yur netwrk? (a) always release the call (Cause Value = ) (b) determine if the number has Prted t anther netwrk & if s, attach 011xn7 HOC and nward rute the call. Otherwise release the call (Cause Value = ) (c) ther (please describe) NN= Natinal Number - g t Q5 NB the Cause Values in questin 4(a) and (b) are the Cause Values sent ver the intercnnect bundary. 5 Fr calls t NZ lcal netwrk Custmers numbers riginated by Custmers (if any) n yur netwrk, and/r transited by yur tll bypass netwrk (if any) will yur netwrk check a Number Prtability database t determine the Prted status f the called number, and, if Prted, determine the HOC identifying the Recipient Netwrk (befre ruting the call t anther netwrk)? (a) YES fr ALL called lcal netwrk numbers (b) YES fr sme called lcal netwrk numbers (c) NO - g t Q6 New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 62 f 127

63 Q QUESTION ANSWER (please as apprpriate) 6 Fr calls t NZ mbile netwrk Custmers numbers riginated by lcal Custmers (if any) n yur netwrk, and/r transited by yur tll bypass netwrk (if any) (a) YES fr ALL called mbile netwrk numbers (b) YES fr sme called mbile netwrk numbers (c) NO will yur netwrk check a Number Prtability database t determine the Prted status f the called number and, if Prted, determine the HOC identifying the Recipient Netwrk (befre ruting the call t anther netwrk)? - g t Q7 7 Fr which Custmers number ranges will yur netwrk cnsult a Number Prtability database t determine prting status and, where Prted, determine the HOC identifying the Recipient Netwrk? (A=area cde digits 3,4,6,7,9) (Please split the number ranges if required t differentiate) Nt applicable as Q5(c) and Q6(c) bth apply. - g t Q9 021 Vdafne mbile range 027 Spark mbile range 029 Vdafne mbile range 02x Other nn-spark mbile ranges 0A(2-8) Spark lcal ranges ranges Yur netwrk s wn ranges 0A9 Other nn-spark lcal (fixed line) ranges - g t Q8 Other netwrk s number ranges as apprpriate Other netwrk s number ranges as apprpriate 8 T which netwrk(s) will yu deliver calls t NZ lcal and mbile netwrk Custmers number ranges whse prting status has been determined by yur netwrk and fund t be either (i) Prted t Recipient Netwrks identified by 011xn7 HOCs as fllws; r (ii) nt prted? New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 63 f 127

64 Q QUESTION ANSWER (please as apprpriate) Recipient HOC Netwrk Fr example Big Netwrks Fr example Spark Bird 2Degrees Mbile Call Plus Calls will be ruted n direct rutes t the fllwing Netwrk: Calls will be ruted n alternate/verflw rutes t the fllwing Netwrk: Internally Ruted Nt applicable Spark N verflw ruting via ther netwrks Cmpass Link Telecm NOW (frmerly NOW) Orcn Symbi Netwrks Spark (lcal) Spark (mbile) Vdafne (TCL) lcal b7 b=0-9 Vdafne (lcal) Vdafne (mbile) Wsh a7 a=6-9 WrldxChange g t Q9 9 Hw & where will yu deliver calls t thse NZ fixed and mbile netwrk Custmers number ranges whse prting status is NOT checked by yur netwrk? New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 64 f 127

65 Q QUESTION ANSWER (please as apprpriate) Nt applicable as Q5(a) and Q6(a) bth apply. - g t Q10 (a) Calls will be ruted n direct rutes t the fllwing Netwrk(s).: (b). with the called party number parameter sent n the direct rute in the fllwing frmat: (c) Database lkup will be perfrmed by the fllwing Netwrk(s) delegated t d this n yur behalf (d) What actin d yu want the delegated netwrk t take if it determines that a number is Prted? 10 What actin will yur netwrk take if it attempts t cnsult a Number Prtability database t determine the Prted status f a called number, but finds that the database is unavailable? (please specify netwrk. NB this netwrk will be referred t as Netwrk x in Q 9[c]) either: r: r: 0+NN 011xn8+NN (xn= ) 011xn9+NN (xn= ) (please specify xn value if used) (if 0+NN frmat is used in 9[b], then this netwrk must be the same as Netwrk x) either: attach 011xn7 HOC t called party number and nward rute r: release call with Cause Value 14 (fr QOR treatment in yur netwrk) r: release call with Cause Value 23 & Redirecting Number (fr Redirectin treatment in yur netwrk) - g t Q10 Nt applicable as Q5(c) and Q6(c) bth apply. - g t Q13 (a) always release the call (b) rute the call based n the called number (i.e. assume that the called number is nt Prted) (c) ther (please describe) g t Q11 11 Is yur netwrk able t act as a delegated (a) NO g t Q13 New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 65 f 127

66 Q QUESTION ANSWER (please as apprpriate) netwrk and cnsult a Number Prtability (b) YES g t Q12 database n behalf f ther netwrks? 12 Which methd(s) f call handling des yur netwrk ffer when acting as a delegated netwrk, when a called number is fund t be Prted? 13 Is yur netwrk able t supprt the sending f the ITU-T ISUP Lcatin Number parameter with calls made by Prted numbers hsted n yur netwrk (t identify the gegraphic lcatin f the Custmer t ther netwrks receiving the calls? 14 Is yur netwrk able t receive the ITU-T ISUP Lcatin Number parameter with incming calls frm ther netwrks and use the infrmatin cntained in the parameter in gegraphic-rigin based call ruting (e.g. typically fr 0800/0808 & 0900 calls)? 15 Other Cmments: (a) will attach 011xn7 HOC t called party number and nward rute (b) will release call with Cause Value 14 (fr QOR treatment in the delegating netwrk) (c) will release call with Cause Value 23 & Redirecting Number (fr Redirectin treatment in the delegating netwrk) g t Q13 (a) Nt Applicable (as Q1(a) applies) (b) NO (c) YES g t Q14 (a) Nt Applicable (as gegraphic-rigin based ruting is nt used) (b) NO (c) YES end f questinnaire New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 66 f 127

67 Appendix B. IPMS Management This sectin, and the definitins it cntains, relate exclusively t the IPMS. "Fault" means the failure, in whle r in part, in the supply f, r a material degradatin in the quality f, the IPMS r a failure t prvide any data, reprt r dcument t TCF r Service Prviders r Carriers as required by the IPMS Agreement and the Number Prtability Determinatin; "Fault Severity" means the level f severity f any Fault, as determined by TCF, in accrdance with the fllwing: Severity Definitin Critical IPMS is unavailable t TCF r Service Prviders r Carriers; r severe peratinal impact degrading the perfrmance r utputs f the IPMS; r the IPMS (r any utput frm the IPMS including TCF Data) is affecting the integrity r crrect peratin f any telecmmunicatins netwrk used by any Service Prviders r Carriers. High Significant peratinal impact affecting prtins f the IPMS r impacts n the ability f the IPMS t perfrm effectively. Medium Allws the IPMS t cntinue t perate (pssibly with a wrk-arund in place (at n additinal cst t TCF, unless agreed therwise with TCF in writing)) but a minr part f it is unavailable r nt wrking as cntemplated under this Agreement. Lw Nn critical t TCF r Service Prviders r Carriers. Help Desk" means System Administratrs Help Desk which is cntacted by telephne r as set ut in sectin 5 f Appendix B, r such alternative phne number r address as the TCF may, frm time t time, advise Service Prviders r Carriers in writing; IPMS Planned Outage means the temprary unavailability f the IPMS in rder fr the System Administratrs t carry ut any testing, repair r maintenance which is reasnably required in respect f the IPMS; Perfrmance Levels means the perfrmance criteria t which the System Administratr will prvide the management services as described in sectin 4 f Appendix B; Reslutin Time" means the perid frm the time a Fault is discvered by the System Administratr r is lgged by the TCF r a Service Prvider r Carrier (in accrdance with this Manual) (whichever is the earlier) until the time that Fault has been Reslved (inclusive); New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 67 f 127

68 "Reslved" means that a Fault has been rectified and the IPMS has been returned t nrmal perating cnditins as reasnably determined by TCF r a Service Prvider r Carrier (and "Reslutin" shall have a crrespnding meaning); "Respnse Time" means the perid frm the time a Fault is discvered by the System Administratr r is lgged by TCF r a Service Prvider r Carrier (in accrdance with this Manual) (whichever is the earlier) until the time the System Administratr has advised TCF and Service Prviders and Carriers that it has cmmenced actin t diagnse and rectify the Fault (inclusive); System Administratr means the party appinted by the TCF frm time t time t maintain and perate the IPMS. TCF Crdinatr means the persn appinted by TCF and ntified t the Service Prviders and Carriers frm time t time t liaise with the System Administratr and/r Service Prviders and Carriers n matters relating t the IPMS; TCF Data means data wned r supplied by TCF r a Service Prvider r Carrier t which the System Administratr is supplied access and data which may be generated, cmpiled, arranged r develped in prviding the IPMS; TCF Facilitatr means the persn appinted by TCF and ntified t Service Prviders and Carriers frm time t time t liaise with the System Administratr and/r Service Prviders and Carriers n matters relating t the IPMS fr escalatin purpses. 2 Supprt Services The fllwing supprt services shall be available: The TCF will prcure that the System Administratr shall make available the Help Desk t the Service Prviders and Carriers n a 24 hur 7 day per week basis, fr the purpse f reprting and reslving Faults and peratinal issues r enquires that arise in relatin t the IPMS. The TCF shall ntify Service Prviders and Carriers in writing f any changes that ccur t the relevant telephne r address f the Help Desk set ut in sectin 5 f Appendix B. (i) The Help Desk will maintain: a receptin pint fr lgging Faults and enquires; Fault prgress tracking and reprting; IPMS utage tracking; fr the duratin f any Fault, direct cntact, as reasnably required by the relevant Service Prvider r Carrier, between the System Administratr and that Service Prviders r Carrier s specialist peratins grups; and a c-rdinatin pint fr the restratin f the IPMS. The TCF shall prcure that the System Administratr shall, thrugh the Help Desk and after becming aware f any Fault in respect f Service Prviders and Carriers: New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 68 f 127

69 take all actin reasnably necessary in rder t rectify that Fault, with as little disruptin t Service Prviders and Carriers as is reasnably pssible and in any event in accrdance with the Perfrmance Levels; advise the TCF C-rdinatr and the relevant Service Prviders and Carriers f any actins being taken in rder t rectify the Fault; prvide the TCF C-rdinatr and the relevant Service Prviders and Carriers with an estimate f the time required t rectify the Fault; prvide the TCF C-rdinatr and the relevant Service Prviders and Carriers with nging prgress reprts in respect f the actins being taken t rectify the Fault in accrdance with the times fr the relevant update frequency specified in the Perfrmance Levels as set ut in sectin 4 f Appendix B. The Service Prviders and Carriers shall be respnsible fr managing its wn staff training in relatin t the use f the IPMS and shall nt call the Helpdesk fr this unless agreed therwise with the TCF C-rdinatr. A breach f the Perfrmance Levels specified in sectin 4 f Appendix B shall exclude any breach which arises: due t an event f frce majeure; r due t a material default by the Service Prviders and Carriers f any f its bligatins under its Agreement with the TCF; r due t a material default by the TCF f any f its bligatins under the agreement with the System Administratr r any ther supprt prvider ther than the bligatin t make payment t thse parties; r due t any material default under any IPMS Access Agreement with the Service Prvider r Carrier r between the TCF and any ther Service Prvider r Carrier; r frm any act r missin by a the Service Prvider r Carrier, their fficers, emplyees, agents, Cntractrs r cnsultants r any ther persn fr whm the Service Prvider and Carrier is respnsible ther than any act r missin taken r nt taken (as the case may be) at the directin f the TCF, its fficers, emplyees, agents, Cntractrs, sub-cntractrs; r as a direct result f the malfunctin f a Service Prvider r Carrier cnnectin r equipment r any ther cnnectin r equipment which is nt under the cntrl f the TCF; r during any Planned Outage. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 69 f 127

70 3 Faults Nthing in this Agreement shall require the TCF t prvide cntinuus r fault free access t the IPMS. The Service Prviders and Carriers shall cmply with such specific prcedures and bligatins in relatin t the management f Faults as reasnably required by the TCF. The TCF shall prcure that the System Administratr shall mnitr the IPMS n a 24 hur per day / 7 day per week basis fr the purpse f early identificatin f any Faults, r any circumstances that might reasnably give rise t a Fault. On becming aware f any Fault, Service Prviders and Carriers agree that they shall check that the Fault relates t the IPMS prir t ntifying the Help Desk. If, after such checking, the Service Prvider r Carrier still believes (acting reasnably) that the Fault is with the IPMS System, the Service Prviders r Carrier shall ntify the Help Desk by phne (at any time) r by (nly recmmended during Wrking Hurs) as sn as reasnably practicable. Each such ntice shall specify: 4 Respnse Time details f the nature f the Fault; and the Fault Severity f that Fault. Upn becming aware f any Fault in the IPMS, the TCF shall ensure the System Administratr shall cmply with the Respnse Times and Reslutin Times in relatin t rectificatin f that Fault and will use its best endeavurs t respnd t all Faults within a shrter timeframe. Only Faults with Critical r High Fault Severity Level will require a Respnse utside f Wrking Hurs unless therwise apprved by the TCF C-rdinatr r the TCF. The TCF shall prcure that the System Administratr will prvide an incident reprt t the Service Prviders and Carriers affected by the incident, within 1 Wrking Day f Reslving a Fault, fr all Faults with a Critical r High Fault Severity Level plus any ther lgged Faults specifically requested. IPMS Planned Outages Subject t sectins 3.6 and 3.7 f Appendix B, the TCF shall use its best endeavurs t ensure that all IPMS Planned Outages ccur between 12.00am and 04:00am n the first Sunday f each mnth, and that the IPMS Planned Outage des nt exceed these hurs. Subject t sectins 3.6, 3.7 and 3.8 f Appendix B, the TCF shall prcure that the System Administratr shall give the Service Prviders and Carriers and the TCF Crdinatr a minimum f 2 Business Days prir written ntice f any IPMS Planned Outage. Each such ntice shall include the fllwing infrmatin: the reasn fr the IPMS Planned Outage; New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 70 f 127

71 the prpsed date and time f the IPMS Planned Outage; the estimated duratin f the IPMS Planned Outage; and the name and cntact details f the apprpriate persn whm the Service Prviders and Carriers shuld cntact fr further infrmatin in relatin t the IPMS Planned Outage. Where the prpsed date and time fr the IPMS Planned Outage is utside f the timeframe specified in sectin 3.4 f Appendix B and is: utside Wrking Hurs, the ntice perid referred t in sectin 3.5 f Appendix B fr the IPMS Planned Outage shall be a minimum f 1 Business Day; r within Wrking Hurs, the ntice perid referred t in sectin 3.5 f Appendix B fr the IPMS Planned Outage shall be a minimum f 10 Business Days, and in either case, the ntice t the Service Prviders and Carriers shall include the infrmatin referred t in sectin 3.5 f Appendix B and the reasn why the IPMS Planned Outage is ccurring at that time. If the TCF cnsiders (acting reasnably) that any IPMS Planned Outage requires the Service Prviders and Carriers t: undertake staff training; r assist with the IPMS Planned Outage, then if the date and time f the IPMS Planned Outage is within the timeframe specified in sectin 3.4, the TCF shall, subject t sectin 3.8 f Appendix B, prcure that the System Administratr gives the Service Prviders and Carriers a minimum f 10 Business Days ntice r a shrter ntice perid if agreed by all Service Prviders and Carriers. Where: the IPMS Planned Outage is as a result f a majr enhancement t the IPMS (as reasnably determined by the TCF), then the TCF will endeavur t cnsult with each Service Prvider and Carrier prir t the System Administratr giving ntice t agree the length f the ntice perid, and the TCF shall prcure, ntwithstanding sectin 3.7 f Appendix B, that the ntice perid shall be a minimum f 20 Business Days r such lnger perid as agreed t by the TCF; the circumstances giving rise t a IPMS Planned Outage are such that an immediate, temprary suspensin r restrictin f the IPMS is required and the System Administratr is nt able t give ntice as set ut abve, the TCF shall prcure that the System Administratr shall use its best endeavurs t prvide the TCF C-rdinatr and the Service Prviders and Carriers with such prir ntice as is reasnably pssible in the circumstances. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 71 f 127

72 5 IPMS Perfrmance Levels The TCF shall endeavur t meet the fllwing Perfrmance Levels: Subject t sectin 1.5 f Appendix B, the TCF shall use reasnable endeavurs t ensure the IPMS is available 99% (at all times) per quarter. The maximum Respnse Times and Reslutin Times are: Fault Severity Respnse Time Reslutin Time Update Frequency Critical 30 minutes 4 hurs Every 45 minutes High 1 hur 8 hurs Every 2 hurs Medium 10 hurs (1 day) 50 hurs (5 days) Every secnd day Lw 20 hurs (2 days) 100 hurs (10 days) Every Week Fr Faults with a Critical Fault Severity Level, the Respnse and Reslutin Times are based n elapsed hurs, all ther Fault Respnse and Reslutin Times are based n Business Hurs. Critical and High Fault Severity Respnse Times and Reslutin Times will nly be applied t the prductin envirnment. The test and training envirnment is expected t have a lwer pririty under nrmal circumstances. 6 IPMS Mnitring The TCF shall prcure the cntinual practive (24 hurs per day 7 days per week) mnitring f the IPMS t enable early ntificatin f failures Faults r issues. Escalatin If a Fault is unable t be reslved by the System Administratr within a reasnable timeframe then the relevant Service Prvider r Carrier may escalate the prblem in accrdance with the timeframes identified in the Perfrmance Levels t the System Administratr persnnel identified in the Table belw. The Service Prvider and Carrier /the TCF Interface Each Service Prvider and Carrier, by written ntice t the TCF and the TCF Crdinatr, shall appint a user administratr ("User Administratr") and shall maintain the appintment f a User Administratr thrughut the term f this Agreement. The relevant Service Prvider and Carrier may replace, frm time t time, by written ntice t the TCF and the TCF C-rdinatr, their User Administratr. The principal functin f the User Administratr shall be t manage the relatinship between the relevant Service Prvider and Carrier and the TCF Crdinatr and the relatinship between the relevant Service Prvider and Carrier and the System Administratr, in each case, in accrdance with this Manual. IPMS Escalatin Rles and Respnsibilities Level 1 Cntact Pints: New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 72 f 127

73 System Administratr Help Desk Respnsibility: Cntact Details: Management f Call Centre, initial lgging f events and escalatin f issues. TBA prir t cmmencement fr Management Services TCF member cntacts Respnsibility: Escalatin/ Level Vendr Assistance t System Administratr, Future surcing as required, and liaisn with users. Rle Respnsibility Cntact Details Level 2 Site/Client Manager Mnthly Reprting TBA prir t Change Cntrl cmmencement fr Escalatin f issues Management Services Level 3 Manager Managed Escalatin f issues TBA prir t Services cmmencement fr Level 4 NZ Directr f Vendr Prfessinal Services Management Services Escalatin f Issues TBA prir t cmmencement fr Management Services TCF Level 2 TCF Crdinatr Escalatin f issues Level 3 TCF Facilitatr Escalatin f issues nt able t be reslved with TCF Crdinatr Parties t the NP Determinatin Representative User Administratrs f each Party t the Number Prtability Determinatin NP C-rdinatr. Refer fr cntact details. TCF Frum Administratr. Refer fr cntact details. Refer fr cntact details. The TCF may add, amend, delete infrmatin in sectin 5.5 and 5.6 f Appendix B, frm time t time by ntice in writing t the Service Prviders and Carriers. 7 Managing the Lad n IPMS The perfrmance f IPMS is impacted primarily by the fllwing factrs: the plling frequency f API calls; the number f Carriers; New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 73 f 127

74 the number f utstanding prts f a given status; the amunt f time that SOMs spend in-prgress; and the number f SOMs being prcessed per mnth. As IPMS is slely a reactive system, it cannt cntrl the lad and is cmpletely dictated t by the users f the system. The fllwing frequencies were set by HP in the interests f keeping IPMS running smthly. Recmmended API Plling Frequency (frm sectin 4.5 f the IPMS Technical Specificatin) Operatin Cnditins Max Frequency getrequestedprts getapprvedprts Filter My SP Actin + Date Filter My Carrier Actin + statuslist + Date 5 mins fr mbile Service Prviders 10 mins fr lcal Service Prviders May be called nce fr each pssible Status in the statuslist filter within the fllwing perids: 2 mins fr mbile Service Prviders 10 mins fr lcal Service Prviders getprtprgress SOM Once every 5 minutes fr each prt during activatin getnetwrkupdates getapprvedprtchangereq uests CarrierIdList filter set t null My SP Actin Once every 10 mins. Set CarrierIdList filter t null t return netwrk updates fr all Carriers assciated with the user/cmpany. 15 mins APIs called by autmated prcesses can inflict cnsiderable lad n the system. Where a Carrier s system is ding mre than what is cnsidered safe, they may be asked t reduce the lad. Basic methds t d this include: slwing dwn the frequency f calls; reducing the frequency f plling fr given events after a certain amunt f time (eg reduce frequency f getprtprgress after half an hur fr a given prt and again after fur hurs); and escalating repeated failures (especially security failures, such as 620, PASSWORD_EXPIRED). New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 74 f 127

75 Appendix C. Change Request Frm TCF Reference: Prject Name: Mdule: Change Title: Submitted by: Change Type: Severity: Descriptin: Reference: Date: Phne: Specify ne f prblem, enhancement r ther Specify serius, mderate, minr r csmetic New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 75 f 127

76 Appendix D. IPMS Parameter Change Frm IPMS Parameter Change Specificatin Outline Change Number Cx IPMS envirnments Nte: where wrk invlves change in Dnr Carrier, Hst Carrier r Service Prvider, a Special Prject may be required IPMS Dev Date f N/A change IPMS Test Date f N/A change IPMS Prd Date f TBA change IPMS Train Date f N/A change Prpsed by Date f request Cmpany Telephne N: NPUG Status Internal Status Table: Cmpany (Technical Specificatin Reference 3.5.3) Actin Cmpany ID Cmpany Name [Create Delete] Table: Service Prvider (Technical Specificatin Reference 3.5.4) Recrd 1 Recrd 2 Recrd 3 Actin [Create Mdify Delete] [Create Mdify Delete] [Create Mdify Delete] Service Prvider ID Service Prvider Name Cmpany ID Min Accunt Length Max Accunt Length Aut-Apprve Prt Requests within Service Prvider Aut-Apprve Prt Requests within Cmpany Aut-Accept APC within Service Prvider Aut-Accept APC within Cmpany AccuntNumberType Table: Carrier (Technical Specificatin Reference 3.5.5) Recrd 1 Recrd 2 Recrd 3 Actin [Create Delete] [Create Delete] [Create Delete] Carrier ID Carrier Name Cmpany ID Carrier Type Min Handset Ref Length Max Handset Ref Length GC Receive Own Prts LC Receive Own Prts Receive Own RQs GC Cnfirm Prt Withdrawal LC Cnfirm Prt Withdrawal GC Cnfirm Prt Expiry LC Cnfirm Prt Expiry Table: Carrier-Service Prvider (Technical Specificatin Reference 3.5.8) Actin Service Prvider ID Carrier ID Read Only New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 76 f 127

77 [Create Delete] [Create Delete] Table: Number Range (Technical Specificatin Reference 3.5.2) Actin [Create Delete] [Create Delete] [Create Delete] IPMS Dnr Range Phne Number Prefix Dnr Name Dnr ID Descriptin (Lcal/Mbile) LICA (See Nte i) Nte i: The LICA field is nt used by IPMS. It has been included as carriers require this infrmatin t set up their netwrk ruting tables. Appendix 1 lists valid LICAs. Table: Queuing By Number Range Technical Specificatin Reference ) Actin Carrier ID Carrier Name Enabled Number Range Netwrk Type Dnr Name [Create Delete] [Create Delete] Nte: This table is used t verride the rules fr ppulating the Queuing By Number Range Table specified in Appendix 1. Table: Queuing By Netwrk Type (Technical Specificatin Reference ) Actin Netwrk Type Netwrk Updates Enabled Carrier ID Carrier Name [Create Delete] [Create Delete] Table: Service Level (Technical Specificatin Reference 3.5.7) Recrd 1 Recrd 2 Recrd 3 Actin Mdify [Create Delete] [Create Delete] PORTCATEGORY NETWORKTYPE ACTIVATIONGRACEMINUTES ACTIVATIONWINDOWSIZE APCRESPONSEBUSINESSHOURS GSPAPPROVALBUSINESSHOURS LSPRESPONSEBUSINESSHOURS MAXNOTICECALENDARDAYS MINNOTICEBUSINESSHOURS Table: Parameter (Technical Specificatin Reference ) Actin IPMS API versin System Identifier Max APCs per Prt Hme Page HTML Minimum passwrd length Maximum Prt resubmissins Relinquishment quarantine calendar days Expiring usiness days Expired business days Emergency return business days Rejected and Cancel appear in getrequestedprts business days Withdrawn Expired and Clsed appear in getapprvedprts business days Accepted and Rejected appear in getapprvedprtchangerequests business days Maximum phne numbers per prt Maximum Errrs returned Maximum Netwrk Updates returned [Create Delete] Ntes: 1. T mdify a recrd in IPMS, delete the ld recrd and create a new recrd. This prcess will make the nature f the change visible. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 77 f 127

78 1 Appendix 1 Queuing By Number Range Rules When a carrier creates a new number range in the Number Range Table, all ther carriers need an entry in the Queuing By Number Range Table fr the new number range. The fllwing default rules shuld be used by HP t ppulate the Queuing By Number Range Table fr new number ranges. HP shuld apply these default rules if a carrier has nt made an entry in the Queuing By Number Range Table abve fr the new number range. If there is an entry in the Queuing By Number Range Table n this frm, the entry will verride the default rules specified belw. Default Rules: Carrier NOW CALLPLUS COMPASS IHUG LINKTEL ORCONLOCAL TCLA SPARKLOCAL SPARKMOBILE VFNZ WOOSH WXCLOCAL NZCL New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 78 f 127

79 2 Appendix 2 LICAs Akara Kurw Stratfrd Alexandra Lawrence Taihape Amberley Levin Takaka Ashburtn Lumsden Taumarunui Auckland Martn Taup Balclutha Mastertn Tauranga Blenheim Matamata Te Anau Chevit Maungaturt Te Awamutu Christchurch Miltn Te Kuiti Crmwell Mkau Thames Culverden Mrrinsville Timaru Dannevirke Mtueka Tkanui Darfield Mt Ck Twizel Dargaville Murchisn Waihi Dunedin Napier Waimate Edendale Nelsn Waiuru Fairlie New Plymuth Waipukurau Featherstn Oamaru Waira Fx Glacier Ohakune Waitangi (Chatham Islands) Franz Jsef Optiki Wanaka Geraldine Opunake Wanganui Gisbrne Otautau Warkwrth Gre Otrhanga Wellingtn Great Barrier Island Paera Westprt Greymuth Pahiatua Whakatane Haast Palmerstn Whangamata Hamiltn Palmerstn Nrth Whangarei Hawera Paraparaumu Wintn Helensville Pukekhe Hibiscus Cast Putaruru Hkitika Queenstwn Huntly Ranfurly Invercargill Rangira Kaikhe Rivertn Kaikura Rtrua Kaitaia Rxburgh Kawakawa Ruatria New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 79 f 127

80 Appendix E. API Errr Messages Extracted frm Tech Spec Sectin 9 Appendix A Errr Cde ACCEPT_STATE ACCESS_DUPLICATED ACCESS_INVALID ACCOUNT_FORMAT ACCOUNT_REQUIRED ACTION_INVALID ACTIVATE_APC ACTIVATE_GC ACTIVATE_STATE ALREADY_APC ALREADY_CONFIRMED ALREADY_EMERGENCY_RETURNED APC_ACCEPT_STATE APC_EMPTY APC_LSP_GSP Errr Text The Apprved Prt Change cannt be accepted because the Prt is nt in Apprved, Expiring r Failed state. The access value is repeated. The access value is invalid. The accunt number is nt f a valid length. The accunt number is required when the Prt is nt PrePay/PrePaid r the Prt is PrePay/PrePaid and all nt all numbers are PrePay/PrePaid (nt all numbers have a Handset Reference). Actin must be I fr Insert, D fr Delete r U fr Update. the Prt cannt be activated because there is an Apprved Prt Change in Awaiting APC Apprval state. The Prt cannt be activated because the user is nt f the Gaining Service Prvider. The Prt cannt be activated because the Prt is nt in Apprved State. The Apprved Prt Change cannt be requested because there is already an Apprved Prt Change in Awaiting APC Apprval state. This Netwrk Update has already been cnfirmed. The Prt has already been Emergency Returned. The Apprved Prt Change cannt be accepted because there is n Apprved Prt Change in Awaiting APC Apprval state. Either numbers r a Prt start date/time must be specified in an Apprved Prt Change. The Apprved Prt Change cannt be accepted because the user is nt f the Lsing Service Prvider r Gaining Service Prvider. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 80 f 127

81 Errr Cde APC_LIMIT APC_NUMBER_MISMATCH APC_PORT_VERSION APC_REJECT_STATE APC_RESPONDER APC_STATE APPROVAL_FIELD APPROVAL_GSP APPROVAL_STATE CANCEL_GSP CANCEL_STATE CANNOT_APPROVE CANNOT_COMPLETE CANNOT_CONFIRM CARRIER_INVALID CARRIER_RELATIONSHIP Errr Text The Apprved Prt Change cannt be accepted because there have already been t many Apprved Prt Changes. Phne numbers d nt match thse awaiting apprval. The versin specified in the Apprved Prt Change des nt match that f the Prt. The Apprved Prt Change cannt be rejected because there is n Apprved Prt Change in Awaiting APC Apprval state. The user is nt f the respnding Service Prvider fr the Apprved Prt Change. The Apprved Prt Change cannt be requested because the Prt is nt in Apprved, Expiring r Failed state. The apprved field must be the same as that f the Prt Request r the same as that f respnse frm the Lsing Service Prvider. The Prt cannt be apprved because the user is nt f the Gaining Service Prvider. The Prt cannt be apprved because it is nt in Awaiting GSP Apprval state. The Prt cannt be cancelled because the user is nt f the Gaining Service Prvider. The Prt cannt be cancelled because it is nt in Awaiting LSP Respnse r Request Expired state. This Prt cannt be apprved because the Lsing Service Prvider indicated that: they are nt the crrect Lsing Service Prvider r the accunt number is incrrect. The Prt cannt be cmpleted because all the numbers failed t prt. The Netwrk Update cannt be cnfirmed because there is nt such Netwrk Update. The Carrier specified is nt a valid Carrier. The Gaining Service Prvider is nt authrized t utilize the specified New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 81 f 127

82 Errr Cde CATEGORY_INVALID CLIENT_VERSION_INVALID (n lnger used) COMPANY_INVALID COMPLETE_GSP COMPLETE_NUMBER COMPLETE_STATE CONFIRM_CARRIER CONFIRM_NETWORKUPDATES_STATE CUSTOMER_NAME_REQUIRED CURRENT_PASSWORD_INVALID DETAIL_NOT_ALLOWED FAIL_GSP FAIL_NUMBER FAIL_STATE FIELD_REQUIRED FIELD_LENGTH FILTER_INVALID FILTER_PROFILE GC_NOT_SUPPORTED GSP_GC_READONLY Errr Text Gaining Carrier. The categry must be Simple r Cmplex. The specified Cmpany is invalid. The Prt cannt be cmpleted because the user is nt f the Gaining Service Prvider. The Prt cannt be cmpleted because the number is neither cmplete nr failed. The Prt cannt be cmpleted because it is nt in In Prgress state. The Netwrk Update cannt be cnfirmed because user is nt f the Carrier. Can nt cnfirm netwrk update. Netwrk Updates d nt apply t the current state f the Prt. A Custmer Name must be entered, unless a Prt Request is fr prepay/prepaid mbile numbers nly. The passwrd cannt be changed because the ld passwrd specified is incrrect. Detailed infrmatin is limited t single prt requests nly. The Prt cannt be failed because the user is nt f the Gaining Service Prvider. The Prt cannt be failed because the number has nt failed. The Prt cannt be failed because it is nt in In Prgress state. The field is mandatry. String r text field exceeds maximum length. The filter value specified is invalid. The filter value specified is nt allwed by user s prfile: Prting frm the Netwrk Type f the Lsing Carrier t that f the Gaining Carrier is nt supprted. The Prt cannt be requested because the cmbinatin f Gaining Service Prvider and Gaining Carrier is set New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 82 f 127

83 Errr Cde HANDSET_FORMAT HANDSET_REFS_NOT_UNIQUE LOCAL_RFS_FORMAT LOGIN_INVALID LSP_INCORRECT LSP_LC_READONLY Errr Text Read-nly. The Handset Reference is nt f a valid length. The Handset Reference fr the prepayprepaid number in the set f prted numbers is nt unique. Fr a Lcal-Lcal Prt, the time part f the Prting Date must be 08:00 r 12:00. The specified cmbinatin f user id, cmpany id and passwrd d nt represent an active user with an active prfile. If yu indicate that yu are nt the Lsing Service Prvider then n ther data may be specified. This actin cannt be perfrmed because the cmbinatin f Lsing Service Prvider and Lsing Carrier is set Read-nly. MAX_PHONE_NUMBERS_PER_PORT_EXCEEDED Maximium number f phne numbers per prt exceeded. MAXIMUM_ERRORS_EXCEEDED NONPORTED_NUMBER_LSP NOT_AUTHORISED NUMBER_FORMAT NUMBER_NOT_PORTED NUMBER_PORTING NUMBER_RANGE NUMBER_RANGE_DUPLICATED NUMBER_RANGE_IN_USE NUMBER_RANGE_INVALID NUMBER_RELINQUISHING Exceeded maximum number f errrs. The Lsing Service Prvider specified des nt have a relatinship with the Dnr Carrier fr the nn-prted number. Yu are nt permitted t perfrm this peratin. The number des nt have a valid frmat. The number cannt be Relinquished because it has nt been prted. The number cannt be Prted because it is already invlved in an nging Prt. The number is in a number range unknwn t IPMS. The number range cannt be inserted because it already exists. The number range cannt be deleted because it is referred t by ther recrds in the IPMS database. The number range specified is nt a valid number range. The number cannt be Prted because New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 83 f 127

84 Errr Cde NUMBER_REPEATED (bslete NUMBERS_LC) OVERRIDE_INVALID PASSWORD_ALREADY_USED PASSWORD_EXPIRED PASSWORD_LENGTH PORT_RESUBMIT_LIMIT PORTED_NUMBER_LSP PREPAYPREPAID _NO_HANDSET PROFILE_COMPANY_CHANGE PROFILE_DUPLICATED PROFILE_IN_USE PROFILE_INVALID PROFILE_IPMS_ADMIN PROFILE_NOT_EXISTS PROFILE_USER_ADMIN PROGRESS_GC_LC_GSP PROGRESS_GC_LC Errr Text it is already invlved in an nging Relinquishment. This number has been specified mre than nce. (This errr cde n lnger used since change request CR0003) Yu cannt verride Lsing Service Prvider unless IPMS has been shwn t cntradict the Lsing Service Prvider specified. Yu cannt use this new passwrd because it is a passwrd that has been recently used. The passwrd has expired and a new passwrd was nt specified. The new passwrd specified is nt f the minimum length. The Prt has already been resubmitted t many times. The Lsing Service Prvider specified is invalid fr the Prted number. Yu cannt specify PrePay/PrePaid when n numbers have Handset References. The Cmpany f a prfile may nt be changed. The prfile cannt be inserted because it already exists. The prfile cannt be deleted because it is referred t by ther recrds in the IPMS database. The user s prfile has been made inactive. An IPMS System Administratr can nly maintain User Administratr prfiles. The Prfile specified is nt a valid Prfile. An User Administratr can nly maintain prfiles fr their Cmpany that are nt IPMS System Administratr prfiles r User Administratr prfiles. The user cannt get Prt prgress infrmatin because they are nt f the Gaining Service Prvider, Gaining Carrier r Lsing Carrier. The user cannt set Prt prgress New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 84 f 127

85 Errr Cde PROGRESS_NUMBER PROGRESS_STATE PROGRESS_STATUSES PROGRESS_VERSION REJECT_GSP REJECT_STATE RELINQUISHMENT_LC REPORT_NOT_FOUND RESPONSE_LSP RESPONSE_STATE RETURN_GSP RETURN_NUMBERS RETURN_SOM RFS_NOTICE_PERIOD RFS_WINDOW Errr Text infrmatin because they are nt f the Gaining Carrier r Lsing Carrier. Yu cannt specify Prt prgress infrmatin fr a number that is nt part f the Prt. Yu cannt get r set Prt prgress infrmatin because the Prt is nt in In Prgress state. The prgress update specified is nt valid fr the current state f the number. The prgress update cannt be cmpleted fr the number because anther user has changed the data since it was read. Re-read the data and try again. The Prt cannt be rejected because the user is nt f the Gaining Service Prvider. The Prt cannt be rejected because it is nt in Awaiting GSP Apprval state. The relinquishment cannt be requested because the user is nt current Carrier fr prted number. Reprt nt fund. The Prt cannt be respnded t because the user is nt f the Lsing Service Prvider. The Prt cannt be respnded t because it is nt in Awaiting LSP Respnse state. The Emergency Return cannt be requested because the user is nt f the Gaining Service Prvider. The Emergency Return cannt be requested because the number (including Handset Reference) is nt a cmpleted number in the riginal Prt. The Emergency Return cannt be requested because the Prt was made GC and LC Cmplete t lng ag. The Prt Date/Time specified is nt within the minimum and maximum ntice perids. The Prt cannt be activated utside the Ready Fr Service DateTime windw (grace perid taken int accunt). New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 85 f 127

86 Errr Cde SERVICE_PROVIDER_ACCESS SERVICE_PROVIDER_INVALID SESSION_INVALID SOM_INVALID SOM_NOT_ZERO STATUS_INVALID STATUS_PROFILE UPDATES_CARRIER USER_COMPANY_CHANGE USER_DUPLICATED USER_IN_USE USER_INVALID USER_IPMS_ADMIN USER_NOT_EXISTS USER_USER_ADMIN VALUE_INVALID WITHDRAWAL_STATE WITHDRAWAL_GSP Errr Text The user is nt f the specified Gaining Service Prvider. The specified Service Prvider is invalid. The specified sessin is invalid r has expired. N such SOM exists. If a SOM is specified, it must be the SOM f an Invalid prt r a valid prt resubmissin. The status specified is nt valid. The status is nt allwed by the user s prfile: The user is nt f the Carrier specified by the supplied Carrier id. The Cmpany f a user may nt be changed. The user cannt be inserted because it already exists. The user cannt be deleted because it is referred t by ther recrds in the IPMS database. The user has been made inactive. An IPMS System Administratr can nly maintain User Administratr users. The User specified is nt a valid User. An User Administratr can nly maintain users fr their Cmpany that are nt IPMS System Administratr users r User Administratr users. The value specified is invalid. The Prt cannt be withdrawn because it is nt Apprved, Expiring r Failed state. The Prt cannt be withdrawn because the user is nt f the Gaining Service Prvider. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 86 f 127

87 Errr Cde Descriptins Cde IPMS Errr Mnemnic Descriptin 0 SUCCESS "The Apprved Prt Change cannt be accepted because the Prt is nt in Apprved Expiring r Failed 10 ACCEPT_STATE state." 20 ACCESS_DUPLICATED "The access value is repeated." 30 ACCESS_INVALID "The access value is invalid." "The accunt number is nt f a 40 ACCOUNT_FORMAT valid length." "The accunt number is required when the Prt is nt prepay/prepaid r the Prt is prepay/prepaid and nt all numbers are prepay/prepaid (nt all numbers have a handset 50 ACCOUNT_REQUIRED reference)." "Actin must be I fr Insert D fr 60 ACTION_INVALID Delete r U fr Update." "The Prt cannt be activated because there is an Apprved Prt Change in Awaiting APC Apprval 70 ACTIVATE_APC state." "The Prt cannt be activated because the user is nt f the 80 ACTIVATE_GSP Gaining Service Prvider." "The Prt cannt be activated because the Prt is nt in Apprved 85 ACTIVATE_STATE state." "The Apprved Prt Change cannt be accepted because there is already an Apprved Prt Change in 90 ALREADY_APC Awaiting APC Apprval state." "This Netwrk Update has already 100 ALREADY_CONFIRMED been cnfirmed." "The Apprved Prt Change cannt be accepted because there is n Apprved Prt Change in Awaiting 110 APC_ACCEPT_STATE APC Apprval state." "Either numbers r a Prt start date/time must be specified in an 120 APC_EMPTY Apprved Prt Change." "The Apprved Prt Change cannt be accepted because there have already been t many Apprved 130 APC_LIMIT Prt Changes." "The Apprved Prt Change cannt be accepted because the user is nt f the Lsing Service Prvider r 140 APC_LSP_GSP Gaining Service Prvider." "The versin specified in the 150 APC_PORT_VERSION Apprved Prt Change des nt New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 87 f 127

88 match that f the Prt." "The Apprved Prt Change cannt be rejected because there is n Apprved Prt Change in Awaiting 160 APC_REJECT_STATE APC Apprval state." "The user is nt f the respnding Service Prvider fr the Apprved 170 APC_RESPONDER Prt Change." "The Apprved Prt Change cannt be requested because the Prt is nt in Apprved Expiring r Failed 180 APC_STATE state." "The apprved field must be the same as that f the Prt request r the same as that f respnse frm the Lsing Service Prvider." NOTE: Culd be the 50 character 190 APPROVAL_FIELD custmer name prblem. "The Prt cannt be apprved because the user is nt f the 200 APPROVAL_GSP Gaining Service Prvider." "The Prt cannt be apprved because it is nt in Awaiting GSP 210 APPROVAL_STATE Apprval state." "The Prt cannt be cancelled because the user is nt f the 220 CANCEL_GSP Gaining Service Prvider." "The Prt cannt be cancelled because it is nt in Awaiting LSP 230 CANCEL_STATE Respnse r Request Expired state." "This Prt cannt be apprved because the Lsing Service Prvider indicated that: they are nt the crrect Lsing Service Prvider r 240 CANNOT_APPROVE the accunt number is incrrect." "The Prt cannt be cmpleted because all the numbers failed t 250 CANNOT_COMPLETE prt." "The Netwrk Update cannt be cnfirmed because there is n such 260 CANNOT_CONFIRM Netwrk Update." "The Carrier specified is nt a valid 270 CARRIER_INVALID Carrier." "The Gaining Service Prvider is nt authrised t utilize the specified 280 CARRIER_RELATIONSHIP Gaining Carrier." "The categry must be Simple r 290 CATEGORY_INVALID Cmplex." 310 COMPANY_INVALID "The specified cmpany is invalid." "The Prt cannt be cmpleted because the user is nt f the 320 COMPLETE_GSP Gaining Service Prvider." "The Prt cannt be cmpleted 330 COMPLETE_NUMBER because the number is neither New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 88 f 127

89 cmplete nr failed." "The Prt cannt be cmpleted because it is nt in In Prgress 340 COMPLETE_STATE state." "The Netwrk Update cannt be cnfirmed because user is nt f the 350 CONFIRM_CARRIER Carrier." "The passwrd cannt be changed because the ld passwrd specified 360 CURRENT_PASSWORD_INVALID is incrrect." "A custmer name must be entered unless a Prt request is fr prepay/prepaid mbile numbers 365 CUSTOMER_NAME_REQUIRED nly." "The Prt cannt be failed because the user is nt f the Gaining Service 370 FAIL_GSP Prvider." "The Prt cannt be failed because 380 FAIL_NUMBER the number has nt failed." "The Prt cannt be failed because 390 FAIL_STATE it is nt in In Prgress state." "String r text field exceeds 395 FIELD_LENGTH maximum length." 400 FIELD_REQUIRED "The field is mandatry." "The filter value specified is 410 FILTER_INVALID invalid." "The filter value specified is nt 420 FILTER_PROFILE allwed by user's prfile:" "Prting frm the netwrk type f the Lsing Carrier t that f the 425 GC_NOT_SUPPORTED Gaining Carrier is nt supprted." "The Prt cannt be requested because the cmbinatin f Gaining Service Prvider and Gaining Carrier 430 GSP_GC_READONLY is set read-nly." "The handset reference is nt f a 440 HANDSET_FORMAT valid length." "The user t be impersnated is nt a user in the same cmpany as the 445 IMPERSONATE_USER requesting user." "Fr a Lcal-Lcal Prt the time part f the prting date must be 450 LOCAL_RFS_FORMAT 08:00 r 12:00." "The specified cmbinatin f user id cmpany id and passwrd d nt represent an active user with an 460 LOGIN_INVALID active prfile." "If yu indicate that yu are nt the Lsing Service Prvider then n 470 LSP_INCORRECT ther data may be specified." "This actin cannt be perfrmed because the cmbinatin f Lsing Service Prvider and Lsing Carrier is 480 LSP_LC_READONLY set read-nly." New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 89 f 127

90 "The Lsing Service Prvider specified des nt have a relatinship with the Dnr Carrier 490 NONPORTED_NUMBER_LSP fr the nn-prted number." "Yu are nt permitted t perfrm 500 NOT_AUTHORISED this peratin." "The number des nt have a valid 510 NUMBER_FORMAT frmat." "The number cannt be prted because it is already invlved in an 520 NUMBER_PORTING nging Prt." "The number is in a number range 530 NUMBER_RANGE unknwn t IPMS." "The number range cannt be 540 NUMBER_RANGE_DUPLICATED inserted because it already exists." "The number range cannt be deleted because it is referred t by 550 NUMBER_RANGE_IN_USE ther recrds in the IPMS database." "The number range specified is nt 560 NUMBER_RANGE_INVALID a valid number range." "The number cannt be prted because it is already invlved in an 570 NUMBER_RELINQUISHING nging Relinquishment." "The number cannt be Relinquished 575 NUMBER_NOT_PORTED because it has nt been prted." "This number has been specified 580 NUMBER_REPEATED mre than nce." "Yu cannt verride Lsing Service Prvider unless IPMS has been shwn t cntradict the Lsing Service 600 OVERRIDE_INVALID Prvider specified." "Yu cannt use this new passwrd because it is a passwrd that has 610 PASSWORD_ALREADY_USED been recently used." "The passwrd has expired and a 620 PASSWORD_EXPIRED new passwrd was nt specified." "The new passwrd specified is nt 630 PASSWORD_LENGTH f the minimum length." "The Prt has already been 635 PORT_RESUBMIT_LIMIT resubmitted t many times." "The Lsing Service Prvider specified is invalid fr the prted 640 PORTED_NUMBER_LSP number." "Yu cannt specify prepay/prepaid when n numbers have handset 650 PREPAYPREPAID_NO_HANDSET references." "The cmpany f a prfile may nt 655 PROFILE_COMPANY_CHANGE be changed." "The prfile cannt be inserted 660 PROFILE_DUPLICATED because it already exists." "The prfile cannt be deleted because it is referred t by ther 670 PROFILE_IN_USE recrds in the IPMS database." 680 PROFILE_INVALID "The user's prfile has been made New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 90 f 127

91 690 PROFILE_IPMS_ADMIN 700 PROFILE_NOT_EXISTS 710 PROFILE_USER_ADMIN 715 PROGRESS_GC_LC 720 PROGRESS_GC_LC_GSP 730 PROGRESS_NUMBER 740 PROGRESS_STATE 760 PROGRESS_STATUSES 765 PROGRESS_VERSION 770 REJECT_GSP 780 REJECT_STATE 790 RELINQUISHMENT_LC 800 RESPONSE_LSP 810 RESPONSE_STATE 820 RETURN_GSP 830 RETURN_NUMBERS inactive." "An IPMS system administratr can nly maintain user administratr prfiles." "The prfile specified is nt a valid prfile." "A user administratr can nly maintain prfiles fr their cmpany that are nt IPMS system administratr prfiles r user administratr prfiles." "The user cannt set Prt Prgress infrmatin because they are nt the Gaining Carrier r Lsing Carrier." "The user cannt get Prt Prgress infrmatin because they are nt the Gaining Service Prvider Gaining Carrier r Lsing Carrier." "Yu cannt specify Prt Prgress infrmatin fr a number that is nt part f the Prt." "Yu cannt get r set Prt Prgress infrmatin because the Prt is nt in In Prgress state." "The prgress update specified is nt valid fr the current state f the number." "The prgress update cannt be cmpleted fr the number because anther user has changed the data since it was read. Re-read the data and try again." "The Prt cannt be rejected because the user is nt f the Gaining Service Prvider." "The Prt cannt be rejected because it is nt in Awaiting GSP Apprval state." "The Relinquishment cannt be requested because the user is nt the current Carrier fr prted number r number is nt prted." "The Prt cannt be respnded t because the user is nt f the Lsing Service Prvider." "The Prt cannt be respnded t because it is nt in Awaiting LSP Respnse state." "The Emergency Return cannt be requested because the user is nt f the Gaining Service Prvider." "The Emergency Return cannt be requested because the number New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 91 f 127

92 840 RETURN_SOM 850 RFS_NOTICE_PERIOD 860 RFS_WINDOW 870 SERVICE_PROVIDER_ACCESS 880 SERVICE_PROVIDER_INVALID (including handset reference) is nt a cmpleted number in the riginal Prt." "The Emergency Return cannt be requested because the Prt was made GC and LC Cmplete t lng ag." "The Prt date/time specified is nt within the minimum and maximum ntice perids." "The Prt cannt be activated utside the ready fr service datetime windw (grace perid taken int accunt)." "The user is nt f the specified Gaining Service Prvider." "The specified Service Prvider is invalid." "The specified sessin is invalid r has expired." 890 SESSION_INVALID 900 SOM_INVALID "N such SOM exists." "If a SOM is specified it must be the SOM f an Invalid Prt r a valid Prt 910 SOM_NOT_ZERO resubmissin." 920 STATUS_INVALID "The status specified is nt valid." "The status is nt allwed by the 930 STATUS_PROFILE user's prfile:" "The user is nt f the Carrier 940 UPDATES_CARRIER specified by the supplied Carrier id." "The cmpany f a user may nt be 945 USER_COMPANY_CHANGE changed." "The user cannt be inserted 950 USER_DUPLICATED because it already exists." "The user cannt be deleted because it is referred t by ther 960 USER_IN_USE recrds in the IPMS database." 970 USER_INVALID "The user has been made inactive." 980 USER_IPMS_ADMIN "An IPMS system administratr can nly maintain user administratr users." "The user specified is nt a valid 990 USER_NOT_EXISTS user." "A user administratr can nly maintain users fr their cmpany that are nt IPMS system administratr users r user 1000 USER_USER_ADMIN administratr users." 1010 VALUE_INVALID "The value specified is invalid." 1020 WITHDRAWAL_STATE 1030 WITHDRAWAL_GSP "The Prt cannt be withdrawn because it is nt Apprved Expiring r Failed state." "The Prt cannt be withdrawn because the user is nt f the Gaining Service Prvider." New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 92 f 127

93 "Detailed infrmatin is limited t 1140 DETAIL_NOT_ALLOWED single prt requests nly" "Maximum number f phne 1150 MAX_PHONE_NUMBERS_PER_PORT_EXCEEDED numbers per prt exceeded." "Phne numbers d nt match thse 1160 APC_NUMBER_MISMATCH awaiting apprval." "Exceeded maximum number f 1170 MAXIMUM_ERRORS_EXCEEDED errrs." "Can nt cnfirm Netwrk Update. Netwrk Updates d nt apply t the 1220 CONFIRM_NETWORKUPDATES_STATE current state f the Prt." 1300 REPORT_NOT_FOUND "Reprt nt fund" "Unexpected errr n IPMS server. Errr diagnstic infrmatin has IPMS_SERVER_ERROR been lgged n the IPMS server." New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 93 f 127

94 API Calls changepasswrd getcurrentuserdata getcmpanies getserviceprviders getcarriers getaccess requestprt getrequestedprts submitprtrespnse apprveprt rejectprt cancelprt getapprvedprts activateprt getprtprgress updateprtprgress cmpleteprt failprt getnetwrkupdates cnfirmnetwrkupdates requestapprvedprtchange getapprvedprtchangerequests acceptapprvedprtchange rejectapprvedprtchange withdrawprt requestemergencyreturn requestrelinquishment numberenquiry SOMEnquiry getusers maintainusers getprfiles maintainprfiles getnumberranges maintainnumberranges New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 94 f 127

95 Prt Activatin Apprve d wait Request Appendix F. Service Level Explanatry Ntes Table 1: Simple Mbile Prt Service Levels Nr Phase Event Service Level Ttal time Earliest IPMS status Cmment t apply elapsed start after event 1 Custmer N/A N/A N/A N/A The Custmer cntacts the GSP and requests Prt 2 GSP submits Prt in IPMS 3 LSP respnds t Prt request 4 GSP respnds and updates status 5 6 N/A Within 30 minutes f step 2 (Terms) Within 30 minutes f cmpletin f step 3 (Terms) RFS date arrives N/A wait until RFS arrives GC signals intentin t start Prt Activatin t IPMS Within 10 minutes f the RFS (IPMS measured) 0 the clck starts nw Up t 30 minutes Up t 60 minutes Between 60 minutes and up t 30 days RFS date (minimum 60 minutes) plus up t 10 minutes New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 95 f 127 N/A Immediately after step 2 Immediately after step 3 60 minutes after step 2 Immediately fllwing step 5 Awaiting LSP Respnse Awaiting GSP Apprval Apprved Apprved In Prgress request the number Prt. The start f the Prt prcess is captured in IPMS. A prpsed RFS is set. This step shuld be cmpleted within 30 days f Custmer authrisatin. The 30 minutes applies t the status in IPMS changing frm Awaiting LSP respnse t Awaiting GSP Apprval, and includes any IPMS prcessing time and time intervals fr plling the queue. Once apprved, the Prt is scheduled t start Prt Activatin n RFS date. If step 3 cmpletes in less than 30 minutes, step 4 can still nly take up t 30 minutes. RFS is interpreted here as the start f Prt Activatin. The minimum ntice perid is 60 minutes frm step 2 fr a Simple mbile Prt. The GC updates IPMS t indicate that they will start t Activate the number n their netwrk.

96 Clsing Nr Phase Event Service Level t apply 7 GC advises IPMS Within 10 f GC Prt minutes f step Activatin 6 (Manual: prpsed) 8 LC advises IPMS f ruting update 9 GC cnfirms Prt line by line 10 Other Carriers cnfirm ruting update Within 10 minutes f step 7 (Manual: prpsed) Within 10 minutes f step 8 (Manual: prpsed) Within 1 hur f step 9 (Manual: prpsed n a best endeavurs basis) Ttal time elapsed RFS date (minimum 60 minutes) plus up t 20 minutes RFS date (minimum 60 minutes) plus up t 30 minutes RFS date (minimum 60 minutes) plus up t 40 minutes RFS date (minimum 60 minutes) plus up t 1 hur and 40 minutes. Earliest start Immediately fllwing step 6 Immediately fllwing step 7 Immediately fllwing step 7 Immediately fllwing step 9 IPMS status after event In Prgress In Prgress GC and LC Cmplete Clsed Cmment GC has Activated: trigger fr LC t change Ruting Anywhere between steps 6 and 7, the Custmer will start t receive service frm their new SP (the GSP). When the LC cmpletes the re-ruting, the LSP handset stps wrking. Frm a Custmer pint f view, Prting is cmplete. Once the status changes t Cmplete, the Prt is put n the IPMS queue fr third parties t update their netwrks. Any IPMS prcessing time is included in the Service Level. Unless the Prt is undne, the Custmer will nt ntice this step. The Prt is clsed the number can nw be part f a new Prt Request. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 96 f 127

97 Ntes 1. IPMS status after event clumn reflects the status during a successful Prt. 2. The clumn Service Level t apply indicates the surce f the Service Level a. The Terms the (maximum) duratin f the Activity is prescribed in the Terms. b. IPMS the (maximum) duratin f the Activity is measured by IPMS in additin t Service Levels specified in the Terms c. Manual: prpses the Business Prcess wrkstream has identified that in rder t guarantee a satisfactry Custmer experience, the duratin f the Activity shuld be subject t a Service Level. Key messages 1. The minimum ntice perid fr a simple mbile Prt is ne hur and the activatin windw is up t 30 minutes. Therefre, a Custmer wh wants t Prt as sn as pssible shuld be given an expectatin fr cmpletin f the Prt (i.e. new phne wrks and ld phne stps wrking) between 60 and 90 minutes, t allw fr steps 6, 7 and 8 in the table abve. 2. If a Custmer wants t Prt at a specified time in the future, fr example next Friday at 4pm, then the GSP representative has t set a RFS date (fr IPMS) wrking backwards frm that time s fr Simple Mbile, set the RFS at 3.30pm. The rep als shuld infrm the Custmer that their Prt will be cmpleted between 3.40pm and 4pm. 3. The RFS used in IPMS shuld NOT be cmmunicated t the Custmer. Rather, the Custmer shuld instead be given an expectatin f when step 7-8 will take place. The suggestin is t call this Cut-ver date/time. 4. During the time elapsed between steps 7 and 8, the Custmer will have (partial) service n bth handsets: bth handsets can be used fr utbund calling/sms, and depending n where the incming call riginates frm, may receive calls n bth handsets. a. Nte: this scenari assumes a Prt between Spark and Vdafne. 5. During the time elapsed between steps 8 and 10, the Custmer may nt receive calls riginated frm third party netwrks, unless the tw Carriers invlved in Prting have an arrangement in place fr Carrier re-ruting. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 97 f 127

98 Appendix G. Extract frm TCF Custmer Transfer Cde J. APPROPRIATE CUSTOMER CONTACT AND ACCESS TO AND USE OF INFORMATION 38. The bjective f this sectin is t facilitate best practice in terms f Service Prvider etiquette and hw Custmer infrmatin is accessed and used. 39. Privacy and Use f Infrmatin (this is cvered sectin f the LMNP Terms) 39.1 Infrmatin relating t Custmer Transfer will be kept cnfidential at all times by the parties t the Cde except as set ut in this clause r as required by law. Infrmatin prvided as part f the Transfer prcess can nly be used r disclsed fr the purpse f Custmer Transfers, in assciatin with the delivery f Telecmmunicatins Services, and fr Custmer and netwrk fault management and cmplaint handling. Infrmatin prvided in the Transfer Prcess must nt be used fr any ther purpse (including winback and marketing purpses) A Service Prvider r the Carrier t whse netwrk an access line is directly cnnected and ver which services are supplied ( ASD ), which receives any type f infrmatin relating t the Transfer f a Custmer, may nly use r disclse such infrmatin in accrdance with Privacy Act 1993, the Telecmmunicatins Infrmatin Privacy Cde 2003, and any Bilateral Agreement in place between the parties If there is any incnsistency between this Cde, the Privacy Act 1993, and the Telecmmunicatins Infrmatin Privacy Cde 2003, the Privacy Act and the Telecmmunicatins Infrmatin Privacy Cde prevail. 40. Cntact with the Custmer 40.1 N Party t this Cde will undertake telemarketing, direct mail marketing, face t face marketing r ther marketing activities specifically targeted at the relevant Custmer where thse activities are based n, and are in direct respnse t, the LSP receiving a Validatin Request r the ASD receiving a Transfer Request The ASD may cntact the Custmer abut any prcessing/technical issues but may nt use this pprtunity t attempt t win the Custmer back r refer the Custmer t any ther persnnel within the ASD that engages in retail sales activity Fr the avidance f dubt nthing in clause 40.1 will prevent the LSP frm undertaking marketing activities, which are based n r utilise retail billing r Custmer infrmatin generated within the LSP Fr the avidance f dubt, the GSP may cntact the Custmer at any time. 41. Custmer Initiated cntact 41.1 If the Custmer cntacts the GSP r the LSP, there are n restrictins n the Cmmunicatin that either Service Prvider can have with the Custmer. Hwever, if the Custmer has a cmplaint, then the Service Prvider must cmply with the prvisins f the Telecmmunicatins Carriers Frum Cnsumer Cmplaints Cde If the Custmer cntacts the ASD abut the Transfer, and the ASD is nt the GSP, then the ASD must refer the Custmer t the GSP. 42. Cnduct f Parties t this Cde When interacting with any Custmer: New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 98 f 127

99 42.1 All Parties and their representatives will act in a prfessinal and curteus manner; 42.2 N Party may make any cmment r statement abut any ther Party that wuld r may be likely t bring the ther Party s reputatin int disrepute, particularly where that Party des nt knw the cmplete facts t the situatin (fr instance when there has been an Invalid Transfer); 42.3 Parties must ensure that their representatives, if referring t anther Party s Telecmmunicatins Service(s): i. D nt mislead Custmers in any frm r manner r engage in any cnduct that is likely t mislead; ii. Refer nly t cmparisns that are relevant t the Transfer being made r attempted Parties must ensure that their representatives d nt: Harass r cerce a Custmer; r Engage in uncnscinable cnduct. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 99 f 127

100 Appendix H. LMNP - New Entrants and Ptential New Entrant Guidelines 1. Intrductin 2. Definitins The Cmmerce Cmmissin and the TCF wish t encurage New Entrants and Ptential New Entrants t participate in Lcal and Mbile Number Prtability (LMNP). The purpse f this dcument is t utline the prcedures and steps that New Entrants and Ptential New Entrants will need t undertake in rder t begin Prting. New Entrants are required t participate in Number Prtability and cmply with the Number Prtability Determinatin. New entrant and existing Carrier respnsibilities are cvered in the Netwrk Terms Sectin 20, New Entrant Prcedures. Agreed Business Test Scenaris means a suite f tests designed t test the cmpliance f Lcal and Mbile Number Prtability functins with the LMNP Terms Carrier as defined in the LMNP and Netwrk Terms means an entity that perates a public switched telephne netwrk (r a functinally equivalent system) that riginates, transits r terminates vice calls r shrt messages. The same persn may be bth a Carrier and a Service Prvider. Cmmn Csts means the New Entrant s share f the Capital Cst Payment and the Operatinal Cst Payment, as specified in the Number Prtability Determinatin. End-t-End Testing means a suite f tests designed t prve the integrity f intercmpany LMNP business and netwrking functins. IPMS r Industry Prtability Management System as defined in the LMNP and Netwrk Terms means the sftware, hardware and ther shared facilities used t give effect t the LMNP Terms. Netwrk as defined in the LMNP and Netwrk Terms means a system cmprising telecmmunicatins links t permit telecmmunicatins. New Entrant means the Carrier r Service Prvider whm the Cmmerce Cmmissin has recently determined t be an Access Seeker r Access Prvider in relatin t Lcal Numbers r Mbile Numbers r bth, wh wishes t cnnect t the IPMS t Prt Numbers. This includes Carriers r Service Prviders wh had previusly been determined by the Cmmerce Cmmissin t be an Access Prvider r Access Prvider under the Determinatin fr Lcal Numbers r Mbile Numbers (but nt bth) and wh have recently been determined by the Cmmerce Cmmissin t be an Access Seeker r Access Prvider in relatin t Mbile Numbers r Lcal Numbers (as the case requires) and they wish t Prt thse Numbers using IPMS. NP C-rdinatr means the party appinted by the by TCF t liaise with the System Administratr and is t be the primary cntact pint fr any queries in respect f matters relating t the IPMS The name and cntact details f the NP c-rdinatr are available n the TCF website. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 100 f 127

101 Number Prtability Determinatin means the Cmmerce Cmmissin s Determinatin n the multi-party applicatin fr determinatin f lcal telephne number prtability service and cellular telephne number prtability service designated multinetwrk services Decisin 554, dated 31 August 2005, including any amendments and subsidiary determinatins. Fr the avidance f dubt, unless therwise specified, this includes the Operatinal and Supprt Manual fr LMNP. Operatins and Supprt Manual fr LMNP means a multilateral agreement between Carriers that cvers peratinal issues that are nt dealt with by the LMNP Terms r the Netwrk Terms. Ptential New Entrant means the Carrier r Service Prvider wh wishes t participate in LMNP and wh has nt currently been determined by the Cmmerce Cmmissin t be an Access Seeker r Access Prvider in relatin t either Lcal Numbers r Mbile Numbers r bth Lcal and Mbile Numbers. Service Prvider as defined in the LMNP and Netwrk Terms means any persn prviding a lcal service r mbile service t a Custmer System Administratr means the party appinted by the TCF frm time t time t maintain and perate the IPMS. TCF Frum Administratr means the party appinted by the by TCF t prvide all analytical, secretariat, cmmunicatins, accunting services and website supprt t the TCF. The name and cntact details f the NP c-rdinatr are available n the TCF website. Technical Specificatin means and can be btained frm the NP C-rdinatr. TCF means the Telecmmunicatins Carriers Frum. Fr further infrmatin cntact the TCF Frum Administratr. 3 Current Participants The parties defined by the Cmmerce Cmmissin as Access Seekers and Access Prviders are listed n the TCF Website. The definitins f Access Seeker and Access Prvider are defined in Cmmissin Decisin 554, and subsequently clarified by Decisin 579, which fr cnvenience are prvided belw: An Access Prvider means every persn wh perates- a PSTN t which numbers have been allcated; and a telephne service that relates t that number prtability service Access Seeker means any persn wh- perates a PSTN t which numbers have been allcated; and perates a telephne service that relates t that number prtability service; and seeks access t that number prtability service New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 101 f 127

102 4 Pre-Requisites In rder t begin discussins with the existing parties t the Determinatin (whether is a Carrier and/ r Service Prvider) the fllwing pre-requisites must be in place t facilitate participatin int Prtability: The pre-requisites are: Applicatin t the Cmmerce Cmmissin All Ptential New Entrants must have applied t the Cmmissin t becme party t the Determinatin. Upn acceptance by the Cmmissin, that party will be deemed a New Entrant. On 22 June 2007 the Cmmerce Cmmissin signed ff decisin 605 which was a further clarificatin t the NP Determinatin. The clarificatin stated that the new entrant implementatin timeframe was defined as a 3 mnth windw frm the qualifying date. The qualifying date is defined as the date a party is declared eligible as an access prvider r the date f the decisin whatever is the later. The Cmmerce Cmmissin cnsiders that new parties must have physically intercnnected with at least ne ther Determinatin party, have tested that intercnnectin t the satisfactin f bth intercnnecting parties, and must be affrded an pprtunity t implement and test their systems befre being required t prt lcal r mbile numbers in accrdance with the Determinatin. On receipt f the Cmmissin s acceptance, the TCF Frum Administratr will: Ensure the New Entrant executes the IPMS Access Agreement; Outline the New Entrant s bligatins in respect f the Number Prtability cst allcatin relating t Cmmn Csts. Infrm the NP C-rdinatr that a New Entrant will be applying t participate in LMNP; and Advise the ther parties t the Determinatin f the existence f the New Entrant. Understanding f Number Prtability It is the respnsibility f the Ptential New Entrant and/r the New Entrant t ensure it r its agents have read and, where necessary, sught apprpriate advice n the fllwing: LMNP Terms; Netwrk Terms; Operatins and Supprt Manual; New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 102 f 127

103 IPMS Technical Specificatin; ipms-reprtdwnladclient-src.zip; TCF_IPMS_Technical_Manual_1_2.dc; Number Prtability - IPMS reprt dwnlad web servicev2.1.dc; TCF_IPMS_User_Guide_1_0.dc; and IPMS_Reprting_Web_Service_User_Guide_1_1.dc. The abve dcuments can be btained frm the NP C-rdinatr. All bligatins specified in the dcuments fr Ptential New Entrants and New Entrants must be cmplied with. If the New Entrant r Ptential New Entrant requires clarificatin f any terms in the abve dcuments, it shuld cntact the NP C-rdinatr in the first instance. 5 Bi Lateral Agreements All Ptential New Entrants and New Entrants must cntact any prpsed Carrier(s) and/r Service Prvider partners t ensure that the fllwing have been dcumented and agreed where apprpriate : Technical Inter Cnnect Agreements; and Bi Lateral LMNP Operatinal Agreements, as apprpriate. Bi-Lateral Testing The New Entrant must successfully cmplete bi-lateral testing f the fllwing Agreed Business Test Scenaris belw in rder t mve t the frmal Inter Carrier testing: 1 Prcessing a Simple Successful Prt; 2 Rejecting a Simple Prt; 3 Prcessing an Apprved Prt Change Request (Apprved); 4 Withdrawing a Prt (Apprved); 5 Cancelling a Prt (Awaiting LSP Respnse); 6 Failing a Prt; 7 Emergency Return; 8 Relinquishment; 9 Activate prt that which has an utstanding prt change request; 10 Try t Fail a Prt where Carriers have passed sme f the numbers; and 11 Third party Netwrk Updates Prcess. If the New Entrant is a Carrier, it must als undertake the successful testing f its Netwrk in rder t mve t frmal End-t-End Testing. These test scenaris need t be frmally agreed and dcumented with the Carrier (s). New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 103 f 127

104 Testing f any bilaterally agreed prting prcesses, fr example after hurs prting, is t be dne at the discretin f thse bilateral partners. In any case, the prvisins f the LMNP Terms and the Netwrk Terms are nt t be cmprmised. Inter-Carrier Testing After successful bi-lateral testing has been cmpleted the New Entrant will need t c-rdinate an apprpriate test date/schedule with the NP Crdinatr t cmplete an agreed set f End-t-End Tests with the ther Carriers wh are parties t the Determinatin. Testing shuld be carried ut n an as required basis. It is nt necessary fr all tests t be carried ut with all Carriers hwever every test shuld be carried ut with at least ne Carrier. Testing shuld be dne by agreement with the Carrier they will be testing with t ensure that prting will wrk with all impacted participants (End-t-End Inter-Carrier Test Plan). Entry Criteria The NP C-rdinatr will have use the fllwing as guidelines fr Inter- Carrier Testing: (ii) The fllwing entry criteria are required t have been cmpleted / implemented prir t the start f Inter-Carrier Integratin Testing: All static data must be set up within IPMS as specified in sectin 5.3 f the Technical Specificatin; The IPMS envirnment in which testing will take place must be available and a test date agreed; The New Entrant must have cnnectivity t IPMS; and Exit Criteria All Carriers testing staff are available and familiar with hw t use the IPMS. (iii) The fllwing exit criteria must be met befre IPMS Inter-Carrier Integratin testing can be signed ff: All planned tests have been cmpleted; N pririty 1 r 2 defects remain utstanding; and A test cmpletin reprt is created and agreed by the New Entrant and the NP C-rdinatr. Agreed Business Test Scenaris (iv) As agreed in the End-t-end Inter-Carrier Test Plan, the Carriers/Service Prviders must perfrm the fllwing scenaris where required: Prcessing a Simple Successful Prt; Rejecting a Simple Prt; New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 104 f 127

105 6 Other Prcessing an Apprved Prt Change Request (apprved); Withdrawing a Prt (apprved); Cancelling a Prt (Awaiting LSP Respnse); Failing a Prt; Emergency Return; Relinquishment; Activate prt that which has an utstanding prt change request; Try t Fail a Prt where Carriers have passed sme f the numbers; and Third party Netwrk Updates Prcess. In additin t any Carrier ne-ff certificatin f cmpliance f Equivalent Service, the New Entrant must submit an implementatin plan t the TCF fr apprval. This plan must include key dates (inter carrier testing, bi-lateral agreements etc.) fr their transitin t IPMS which all parties t the Determinatin must have agreed n. Once all parties have agreed t the key dates they cannt be changed unless 75% r mre f the parties t the Determinatin agree t it. The prcedures set ut in this dcument are a guide t New Entrants and Ptential New Entrants as t what needs t be cmpleted in rder t participate in Number Prtability. A detailed checklist must be cmpleted by all New Entrants. The checklist includes the fllwing actins: Applicatin t Cmmerce Cmmissin Understanding f Number Prtability thrugh the NP Operatins & Supprt Manual, LMNP Terms, Netwrk Terms, IPMS Technical Spec. Bi-lateral agreements in place Bi-lateral testing (including agreed business test scenaris Inter-Carrier testing Entry criteria Exit criteria Parties t the Determinatin are required t give apprval fr the New Entrant t g live n IPMS. This apprval can be a verbal apprval given during the regular Number Prtability User Grup meeting which will then be recrded in the minutes. Alternatively, written apprval must be prvided within 3 days. If n New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 105 f 127

106 respnse is received frm the apprval party, a further 2 days will be given fr a respnse t be frthcming and if n respnse is received after this perid the party is deemed t have apprved. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 106 f 127

107 7 Inter-Carrier Test Plan fr Phased Integratin f New Entrants int IPMS T meet the requirements f New Entrants (hereafter referred t as the entrant) fr testing f IPMS usage and inter-carrier peratins, a phased prcess fr testing and integratin int the live IPMS envirnment has been develped. The fllwing dcument shuld be cmpleted with apprpriate details and distributed t all parties as the basis fr new entrant testing. Each phase wuld generally run fr 1 2 weeks depending n resurce scheduling, and wuld nt be deemed cmpleted until all Carriers advise the Frum Administratr that they are happy fr the entrant t prceed t the next phase (this wuld nrmally be dne at an NPUG meeting) Clarificatins: 1. Carriers/Parties: The terms Carriers and parties are used thrughut this dcument. They are intended t include Carriers and Service Prviders as necessary 2. Dates listed are sft and may change fr any reasn as required. Examples f such requirement are: a. Failure t pass a phase sufficiently by the listed End date b. Early cmpletin f a phase where sme parties are willing t mve tests frward t get underway earlier. 3. Date ranges are listed giving ther Carriers a chance t specify a time within that perid that best suits them. The entrant will wrk with all parties t lessen the peratinal impact f testing n thse parties by wrking t their schedule as much as pssible. Technical Data: While this data may nt be f direct use t Carriers fr initial testing it is included fr all parties wh find it f interest r use fr any reasn. Number Blcks: Fllwing is a list f number blcks and LCAs that have been apprpriately btained thrugh the NAD that the entrant will be using initially: Prefix(s) LCA Cntact Details: BAU and First Cntact fr faults will be: Name: Phne: Mbile: Escalatin f faults: New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 107 f 127

108 Name: Phne: Mbile: Phase 1: IPMS prcesses testing Summary: Phase 1 will be simple testing between the new-entrant and ther Carriers t ensure that the new-entrant fllw prcesses with the use f IPMS that matches the expectatins and peratinal understanding f existing Carriers. Lading the cnfiguratin data fr the new entrant in TEST, DEV, and TRAIN is the first step in using IPMS. The new entrant can cmplete test prts internally by using the Dummy Cmpany as the ther party (the NP C-rdinatr can supply user IDs and passwrds fr Dummy Cmpanies). It can be useful t cnfigure sme private number ranges in TEST, that dn t require 3 rd party netwrk updates fr all Carriers befre the SOM is clsed (a gd technique can be t use sme small ranges visible nly t the new entrant and Dummy Cmpany and the new entrant and each f their key intercnnect partners). Testing at this phase may be as simple as ne inbund and ne utbund prt between the entrant and each Carrier; hwever if any Carrier wishes r it is deemed necessary by any suitable party the entrant will need t underg ther testing actins (failing/withdrawing/etc) as necessary. System: Cmmencing: Ending: Outputs: IPMS-TEST <insert date> (This shuld be at least 1 t 2 weeks frm the date that this plan wuld be presented t the NPUG t allw time fr ther Carriers t prepare resurces. Individual times will still need t be rganized with each party) <insert date> Acknwledgement frm Carriers that they are sufficiently happy that the entrant is making use f the IPMS system in a way that cnfrms t predefined prcesses and pre-existing IPMS usage. Phase 2: Dummy Number Testing Summary: Phase 2 will cmmence fllwing successful cmpletin f Phase 1, and lading f the entrants data int IPMS-PROD and is likely t take arund tw weeks. It is imprtant t ensure that all Carriers can have the entrants number ranges and Carrier and Service Prviders ID s setup ready fr this phase as the ptential 6 week lead time needed by sme Carriers wuld slw testing dwn significantly. It is imprtant t nte that the entrant will be required t cmmence prcessing Netwrk Updates generated by the IPMS-PROD envirnment (failure t prcess within acceptable timeframes will slw dwn prting cmpletin fr all Carriers and ptentially lead t issues at a system level) s the entrant shuld nt be enabled in IPMS-PROD until the entrant advises the Frum Administratr that they are able t handle this task. Feasibly, this will require an autmatin system t prcess the ptentially high number f updates generated. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 108 f 127

109 During this phase, the entrant will prt test numbers t and frm ther Carriers. These prts will verify nt nly that crrect IPMS prcedure is fllwed, but that end t end ruting f prted numbers is being handled crrectly fr inbund t and utbund frm the entrants netwrk. Testing at this stage may be as simple as ne inbund and ne utbund prt fr mst Carriers, hwever t ensure that all prcesses are perating crrectly, it is prpsed that the fllwing tests are carried ut with at least ne Carrier (nt all tests wuld necessary need t be with the same Carriers, reducing the burden n any given Carrier) t meet the End-t-End inter-carrier test requirements fr New entrants. Rejecting a simple prt Prcessing an apprved prt change (Apprved) Withdrawing a prt (Apprved) Canceling a prt (Awaiting LSP Respnse) Failing a prt Emergency Return Relinquishment Activate a prt that has an utstanding APC request Try t fail a prt where Carriers have passed sme f the numbers Third party netwrk update prcess System: Cmmencing: Ending: Outputs: IPMS-PROD <insert date> (date phase 2 wuld be apprved cmplete) <insert date> Acknwledgement frm Carriers that they are sufficiently happy that the entrant is accurately handling ruting f prted numbers. Phase 3: Sft Launch Summary: Upn successful cmpletin f Phase 2, the entrant will d live prts f sme test users. The prts fr these will be carried ut as sn as pssible fllwing Phase 2, and will be used fr testing fr n less than ne week. During this time ne f these test numbers will be tied t a phne line at the ffice, allwing trial phne calls t be made t and frm that number if s desired. System: Cmmencing: Ending: Outputs: IPMS-PROD <insert date> (date phase 2 wuld be apprved cmplete) <insert date> Successful active prts. Phase 4: Live Summary: Once Phase 3 has been cmpleted it will be cnsidered that all test scenaris and requirements will have been met allwing full live prting t cmmence. System: IPMS-PROD Cmmencing: <insert date> (date phase 3 wuld be apprved cmplete) Ending: NA Outputs: Nne New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 109 f 127

110 8 Appendix 1 Cnfiguratin Data fr IPMS Cmpany The items that say Prvided by IPMS require the use f lkup tables that will be supplied. Entity names may be sufficient but in the case f Carriers the ID is required. (v) The Cmpany entity is used fr users and security and any Service Prvider r Carrier entities need t refer t this Cmpany in the setup. Cmpany Infrmatin Unique numeric identifier fr Cmpany Name f Cmpany, e.g. Spark NZ Prvided by IPMS Service Prvider (vi) The Service Prvider is the entity defined in the LMNP Terms as: any persn prviding a Lcal Service r Mbile Service t a Custmer and wh has the Billing Relatinship with the Custmer fr that service. The same persn may be bth a Carrier and a Service Prvider. Service Prvider Infrmatin Unique numeric identifier fr Service Prvider Name f Service Prvider, e.g. Vdafne ID f Cmpany that perates this Service Prvider Minimum characters/digits in Custmer accunt number when this Service Prvider is the Lsing Service Prvider in a Prt Maximum characters/digits in Custmer accunt number when this Service Prvider is the Lsing Service Prvider in a Prt Aut-Apprve Prt Requests N = N, S = Service Prvider, C = Cmpany (Fr internal prting style events) Aut-Accept APC within Service Prvider Y = Yes, N = N. If set t Yes, Apprved Prt Change requests will autmatically g t Accepted status if the Prt is nly a change f Carrier (Service Prvider staying the same). Aut-Accept APC within Cmpany Y = Yes, N = N. If set t Yes, Apprved Prt Change requests will autmatically g t Accepted status if the Prt is between Service Prviders within the same Cmpany. Prvided by IPMS Prvided by IPMS Carrier See Technical Specificatin Sectin fr additinal infrmatin A Carrier is the entity defined in the LMNP Terms as: an entity that perates a public switched telephne netwrk (r a functinally equivalent system) that riginates, transits r terminates calls. The same persn may be bth a Carrier and a Service Prvider. If a party t the LMNP Terms has mre than ne Netwrk, it can be classified as mre than ne Carrier. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 110 f 127

111 Hwever, the Carrier entity in the IPMS is really a Netwrk, as a Carrier may have a PSTN that cmprises mre than ne identifiable element. The Carriers in IPMS may represent different parts f a Carriers PSTN, and may represent different gegraphical areas, technlgies, and r pints f intercnnect. Carrier Unique numeric identifier fr a Carrier. This shuld be set t the number prtability netwrk Hand Off Cde (HOC) fr the Carrier, e.g r 11227, allcated by the NAD with a 7 suffix and withut the leading zer. Carrier IDs and Carrier Names will be returned by API functins. Name f Carrier, e.g. Spark Mbile Unique numeric identifier f the Cmpany that wns this Carrier One f the pssible Carrier Types frm the Carrier Type table, e.g. Lcal, Mbile Minimum characters/digits in prepay/prepaid handset reference when this Carrier is the Lsing Carrier in a Prt Maximum characters/digits in prepay/prepaid handset reference when this Carrier is the Lsing Carrier in a Prt GC Receive Own Prts Y = Yes, N = N. Fr Prts where this Carrier is the Gaining Carrier, shuld the SOM als be added t this Carrier s netwrk updates queue and require cnfirmatin LC Receive Own Prts Y = Yes, N = N. Fr Prts where this Carrier is the Lsing Carrier, shuld the SOM als be added t this Carrier s netwrk updates queue and require cnfirmatin Receive Own RQs Y = Yes, N = N. Fr relinquishments where this Carrier was the Hst Carrier (and nt Dnr Carrier) fr the Numbers, shuld the relinquishment be added t the netwrk updates queue fr the Carrier (will happen 30 days after relinquishment). GC Cnfirm Prt Withdrawal Y = Yes, N = N. Fr Prts that have been Withdrawn, where this Carrier was the Gaining Carrier, shuld the withdrawal be added t the Carrier s netwrk updates queue and require cnfirmatin LC Cnfirm Prt Withdrawal Y = Yes, N = N. Fr Prts that have been Withdrawn, where this Carrier was the Lsing Carrier, shuld the withdrawal be added t the Carrier s netwrk updates queue and require cnfirmatin GC Cnfirm Prt Expiry Y = Yes, N = N. Fr Prts that have Expired, where this Carrier was the Gaining Carrier, shuld the expiry be added t the Carrier s netwrk updates queue and require cnfirmatin Prvided by IPMS New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 111 f 127

112 LC Cnfirm Prt Expiry Y = Yes, N = N. Fr Prts that have been expired, where this Carrier was the Lsing Carrier, shuld the expiry be added t the Carrier s netwrk updates queue and require cnfirmatin See Technical Specificatin Sectin fr additinal infrmatin Carrier Service Prvider (vii) The IPMS is cnfigurable in terms f the relatinships between Carriers and Service Prviders. This infrmatin allws Service Prviders t Prt t and frm Carrier entities that may r may nt be wned by the Cmpany they are a part f (ie sme frm f resale). Carrier Service Prvider Unique identifier fr ne f the Service Prviders frm Service Prvider table Unique identifier fr ne f the Carriers frm Carrier table Read-Only Y = Yes, N = N. See Technical Specificatin Sectin fr additinal infrmatin It is wrth nting that Read-Only shuld be set t N fr mst relatinships. A setting f Y wuld indicate an Service Prvider can nly prt ut frm a given Netwrk and might be used during the phasing ut f a Netwrk. 9 Additinal Data Number Ranges (viii) The IPMS stres a list f Number Ranges and Dnr Carriers. Any new entrant with Number Ranges allcated t them by the NAD must supply details fr inclusin t enable Prting in thse ranges. Number Range, e.g Unique identifier fr ne f the Carriers frm Carrier table, e.g Users and User Prfiles (ix) A super user fr the new Cmpany will be added. The new Cmpany can then add User Prfiles and Users as apprpriate. User Prfiles must have Carriers and/r Service Prviders selected fr Users t be able t perfrm the relevant functins. See Technical Specificatin Sectins and fr additinal infrmatin. Queuing by Number Range (x) The Carrier can manage what updates it receives fr 3rd Party Netwrk Updates, and can manage this thrugh the Queuing by Number Range table. It is mre relevant t Cmpanies with multiple Carrier entities in the IPMS r thse using a CSD mdel. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 112 f 127

113 See Technical Specificatin Sectin fr additinal infrmatin. Queuing by Carrier Type (xi) The Carrier can manage separately whether it receives Netwrk Updates fr Lcal and Mbile Prts. See Technical Specificatin Sectin fr additinal infrmatin. New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 113 f 127

114 Appendix I. Special Prjects Uplad File Structure Header recrd Field name Data Type Descriptin Cmpany Name One String VarChar(50) Cmpany name as defined in IPMS database, e.g. Vdafne NZ Ltd File Date and Time DateTime DDMMMYYYY HH:MM:SS Date and time when file was created, e.g. 31NOV :59:59 Detail recrd Field name Data Type Descriptin Number VarChar(11) String f up t 11 numeric digits, including area cde r prefix with leading zer, e.g fr Mbile, r fr Lcal Numbers Carrier Name Integer ID f ne f the Carriers defined in IPMS database, e.g Service Prvider Name One String VarChar(50) Name f ne f the Service Prviders defined in IPMS database, e.g. Vdafne, Wsh New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 114 f 127

115 Appendix J. IPMS Flw Diagram New Zealand Telecmmunicatins Frum Operatins and Supprt Manual fr LMNP Page 115 f 127