Vous êtes sur la page 1sur 96

Canadian Wireless Number Portability Guidelines

Version 1.67 Issued June 14August 15, 2006

Table of Contents

1 2 3 4 5

Introduction......................................................................................................................3 Background......................................................................................................................3 End User Authorization...................................................................................................5 Passwords on End User Accounts....................................................................................6 Port Protection ................................................................................................................7 5.1 Guidelines for Use:....................................................................................................7 5.2 Monitoring:................................................................................................................7 5.3 Dispute Resolution:....................................................................................................8 5.4 Process for addressing fallout caused by port protection:.........................................8 6 Inadvertent Port Process..................................................................................................8 6.1 Preventing Inadvertent Ports......................................................................................8 6.2 Inadvertent Port Resolution.......................................................................................9 7 Customer Porting Request Disputes..............................................................................10 8 Carrier Dispute Resolution Process...............................................................................10 9 Porting Intervals.............................................................................................................10 9.1 Cancellation Deadline for Porting Requests ..........................................................11 9.2 Activation of Number Porting ................................................................................11 9.3 Line Activity Codes.................................................................................................11 9.4 Porting of Suspended and Disconnected Telephone Numbers................................11 9.5 Hours of Operations.................................................................................................12 10 Snap Back Process.......................................................................................................13 11 Fall Out........................................................................................................................13 12 Intercarrier Communication Processes and Scenarios.................................................13 12.1 Impacts and Responsibilities..................................................................................14 12.2 Wireless to Wireless Porting Process....................................................................15 12.3 Data Elements........................................................................................................22 12.4 Data Edits, Formatting and Transmission..............................................................52 12.5 Clearinghouse .....................................................................................................53 12.6 Industry Established Response Timelines.............................................................55 12.7 Version Control ..................................................................................................57 12.8 Backward Compatibility........................................................................................58 13 Data Dictionary............................................................................................................58 14 Glossary of Terms........................................................................................................90

CWTA

Issued 2/7/2013

Introduction

The purpose of this document is to define the operational and technical requirements for wireless number portability in Canada. The primary audience for this specification document is telecommunications service providers participating in wireless porting in Canada along with wireless equipment and service vendors who assist in the definition, development and deployment of Wireless Number Portability (WNP) solutions. It assumes the reader is familiar with WNP and the wireless telecommunications technologies. This document includes porting guidelines to be used in processing porting requests and the operational requirements and technical specifications for the exchange of information needed for the Intercarrier Communication Process (ICP). It represents a consensus developed by the members of the Canadian Wireless Telecommunications Association (CWTA) Canadian Wireless Number Portability Guidelines (CWNPG) Task team and is applicable to all Wireless Service Providers (WSPs) including analog Advanced Mobile Phone System (AMPS), Time Division Multiple Access (TDMA), Code Division Multiple Access (CDMA), Global System for Mobile Communications (GSM) providers (including digital Specialized Mobile Radio (SMR) providers). This document, a detailed interface specification, was created based on the Wireless Intercarrier Communications Interface Specification (WICIS) Version 3.0.0 and Canadian Local Ordering Guidelines (CLOG) Version 5.2. This document is not intended to supercede any regulatory decision regarding Number Portability or Intercarrier Communications, but is intended to describe the process and specifications as it involves wireless service providers, including Mobile Virtual Network Operators (MVNOs) and Resellers.

Background

On March 18, 2005, Industry Canada Minister David Emerson requested the Canadian Radiotelevision and Telecommunications Commission (CRTC) to move expeditiously to implement Wireless Number Portability (WNP) in Canada. WNP was defined as wireless-to-wireless, wireline-to-wireless, and wireless-to-wireline number portability. In April 2005, the CWTA volunteered to lead the Industry implementation of WNP and contracted with an independent consultant to develop an independent, objective plan. In developing the plan, the consultant received input from the CWTA WNP Task Force, consisting of 5 Wireless Service Providers (WSPs) and all other relevant stakeholders. Staff from CRTC and Industry Canada participated in the process as observers. On December 20, 2005, the CRTC issued Telecom Decision CRTC 2005 72, Implementation of Wireless Number Portability.

CWTA

Issued 2/7/2013

In that Decision, the CRTC directed the CRTC Interconnection Steering Committee Business Process Working Group (CISC BPWG) to identify required changes to the customer transfer processes and related documentation used for Local Number Portability to incorporate intermodal porting. For this reason, guidelines and processes relating to inter-modal number porting are not included in this document. The intent of this document is to focus on wireless to wireless porting only. To ensure that WNP could be implemented effectively and efficiently in Canada, a task team was formed to develop guidelines and processes to assist with the implementation and ongoing operation of number portability. The WICIS 3.0.0 and the CLOG 5.2 were used as a base for discussion purposes, with elements being adopted for inclusion in the Canadian Wireless Number Portability Guidelines (CWNPG). The CWNPG task team developed and agreed to the following information in an effort to ensure the smooth implementation of WNP in Canada and a quality customer experience. Service providers wanted a process that would not negatively impact customers, was user friendly, low cost, focused on the necessities, and reduced porting conflicts. This single process should be implemented by all wireless service providers Requirements that were considered are as follows: Product Related

One simple and consistent process for integrated and stand-lone platforms Use of a common Clearing House for all carriers Easy to modify and maintain Ability to set timers based on type and direction of port Help functions Reporting capabilities Timestamps and confirmation of receipt of transactions Ability to integrate into multiple systems such as billing, Point of Sale (POS) and Service Order Administration (SOA) systems

Data Related Same data structure for all ports User defined parameters for record retention Ability to maintain historical database of request and response transactions based on user defined parameters Ability to provide reporting on WNP activities for Fallout Resolution and other report requirements.

CWTA

Issued 2/7/2013

Ability to maintain Service Provider (SP) database When applicable, use the existing reason codes from WICIS and/or wireline When communication occurs between wireless carriers electronically, the date and time fields will be converted to Greenwich Mean Time (GMT). The offset to local time will be performed by the carriers Operational Support Systems (OSS).

Communication Protocols Adopt standard protocols for communication between carriers Effective and efficient communication methodology including Web Access Encryption

End User Authorization

End user authorization must be obtained by the New Service Provider (NSP) through completion of the Porting Request Authorization form or by other acceptable means as discussed below. The authorization form, if used, must be completed in full and signed by the customer requesting the port prior to the initiation of a porting request. This form must be retained, as evidence of the porting request, for a period of no less than 90 days. In the event of a Dispute, the End user authorization form must be produced and provide the information set out below. Sample Authorization Form Porting Request Authorization I hereby authorize ___________________________ to act as an agent on my behalf to port the listed phone number(s) to the above listed service provider. I understand that I am legally obligated for any contract termination fees, equipment financing and outstanding balances owed associated with the contract(s) I have entered into with my previous service provider. Information collected by the Carrier to complete the Porting Request will be used only for that purpose and will be safeguarded appropriately, consistent with requirements of the Personal Information Protection and Electronics Documents Act (PIPEDA) and the Carriers Privacy Policy. Customer/Business Name______________________________________ Billing Address _______________________________________

CWTA

Issued 2/7/2013

Phone number applicable to port request ___________________________ Business Customers Authorized representative _____________________ Customer Signature ____________________________________________ Carrier Contact Name___________________________________________ Date of authorization____________________________ Section H of the Master Agreement for Local Interconnection (MALI) provides the following alternate methods for obtaining customer authorization. 1. Oral confirmation, verified by an independent third party. 2. Electronic authorization confirmation through the use of a toll-free number 3. Electronic authorization confirmation via the Internet 4. Oral authorization retained as an audio recording by the SP
5.

Authorization confirmed through other methods, provided the record of authorization is created by the customer or by an independent third party.

NTD: confirm that this list is complete as per the MALI. NTD: Confirm that we are we processing ports on a FIFO (First in, first out) basis. Note that this is different from the approach used in the CLOG where the most recent authorization date will be processed and all other orders will be rejected. Since the porting intervals are different, the differences in approach probably make sense.

Passwords on End User Accounts

When a customer has established a password or personal identification number (PIN) with the donor carrier as a means of providing additional account access security for the customer, the password or PIN can be included on the WPR by the NSP, as part of the validation process for simple port requests, however it is not mandatory NTD Note that in the CLOG it states that when a Provisioning LEC assigns a password or personal identification number to a specific customer account as a means of providing additional account access security for the customer, the Ordering LEC must include the password in the REMARKS field of the LSR to the Provisioning LEC.

CWTA

Issued 2/7/2013

The provisioning LEC must advise the Ordering LEC in the REMARKS field of the LSC if an account password is missing or invalid. However, the Provisioning LEC must not reject or delay an LSR due to a missing or invalid password. Confirm that we are O.K. taking a slightly different approach from the CLOG or if we want to follow the same approach for passwords for wireless.

Port Protection

Port protection enables carriers to protect selected phone numbers from being inadvertently and/or fraudulently ported out. 5.1 Guidelines for Use: Port Protection should not be generally promoted or advertised Port Protection should not be applied to a phone number unless Port Protection has been authorized by the customer Carriers may offer Port Protection to customers in special circumstances deemed by the carrier to be in the best interests of the client. Examples include, but are not limited to the following:
o

Carriers may pro-actively offer Port Protection on select corporate accounts that are identified by the carrier as security or safety related (e.g. Police, Ambulance, or Emergency Services) Carriers may review existing contractual agreements with clients and proactively offer Port Protection in cases where the client has limited the authority or rights to the phone number. A carrier representative may offer Port Protection to clients that have been Ported in error or fraudulently ported as part of the resolution of the incident.

Port Protection may be applied at the account, sub-account, or telephone number level. However, carriers using both account and telephone number level Port Protection are to ensure when removing Port Protection that all levels are removed from a telephone number to prevent further port blocking When a customer requests that Port Protection be removed from their telephone number, the current service provider should not attempt to retain the customer or deter the customer from proceeding with authorized Port Protection removal.

5.2

Monitoring: Syniverse will provide carrier access to reports for monitoring the number of times a carrier has been denied ports-in due to Port Protection (reason code 6P). The reports should indicate which carriers have denied them the port.
7 Issued 2/7/2013

CWTA

5.3

Carriers will monitor fallout due to Port Protection (reason code 6P) and resolve concerns with partner carriers.

Dispute Resolution: Carriers who cannot resolve port protection issues informally should refer to the formal dispute resolution process outlined in the applicable bilateral intercarrier agreement. (Reference to be confirmed once Bi-lateral agreement template has been drafted.) Process for addressing fallout caused by port protection: 1 NSP submits a WPR to OSP 2 OSP responds with a WPRR 6P resolution code. OSP may provide a follow up number for client to call in the remarks field 3 NSP calls client to indicate that Port Protection is currently on the number and asks the client to call the OSP to authorize removal of Port pProtection 4 Client calls OSP and after confirming that Port Protection has been removed, calls NSP to notify them that Port Protection has been removed 5 NSP submits a SPR with remark Port Protection has been removed. Depending on the time delay encountered between steps 2 and 5, the SPR could be a SUP2 or a SUP3. 6 OSP approves port request

5.4

Inadvertent Port Process

An inadvertent port is the condition when a customer has been ported in error and the customer will experience an out of service condition. The discovery of the inadvertent port generally occurs when the customer contacts their current service providers repair service center. The repair service personnel uncover an inadvertent port through their trouble analysis processes. These processes can include line testing to validate that the customers TN is provisioned properly within the current service providers facilities (i.e. network and loop). In addition the trouble analysis processes include:

Determination that the customer calls are being routed to another service provider No recent port request (WPR/LSR) order activity in the service providers OSS NPAC query indicates the customers telephone number (TN) is active with another service provider

If the service providers repair service determines that the customer is provisioned within their facilities and the conditions described above have been validated, this is considered an inadvertent port. 6.1 Preventing Inadvertent Ports An OSP receiving a Subscription Version (SV) Create from a NSP for a TN that has not started or completed the ICP process should place the SV Create in Conflict at the NPAC. Waiting for response on SOA /SMG behavior in this situation.

CWTA

Issued 2/7/2013

Conflict Resolution Window If the old SP puts a SV into conflict the new SP cannot take the SV out of conflict until 6 (six) business hours have elapsed. This is the NPAC standard conflict timer duration for all port requests. Conflict Restriction This is the point beyond which the old SP no longer can place a SV into conflict. For wireline (landline) carriers, this is noon on the last business day prior to the SVs due date. There is no corresponding limitation for wireless (mobile) carriers SVs. If both carrier types are involved, the wireline limitation applies. Once in Conflict, the OSP should contact the NSPs porting centre or point of contact to do the following: Communicate to the NSP the reason for the Conflict and that the TN should not be ported. Request that the NSP cancel the port at the NPAC to avoid an out of service condition for the customer. Document the cause of the inadvertent port. 6.2 Inadvertent Port Resolution

During Business Hours:


If the inadvertent port was not prevented and the TN has been ported to the NSP, the following procedures can be used by the service providers to restore service during normal Business hours.
1. The

OSP determines the inadvertent has occurred and contacts (calls) the NSP Porting Centre or point of contact to notify the NSP of the trouble. 2. The OSP and NSP must agree that the port was not authorized and proceed with Step 3. 3. If the OSP is the code holder of the TN, the NSP can issue a NPAC Disconnect via the Syniverse GUI to return the TN immediately to the OSP and proceed to Step 5. If the OSP is not the code holder, proceed to Step 4. 4. The OSP and NSP must issue an SV Create and SV Concur via the Syniverse GUI allowing for the OSP to port the TN. The Due Date and Time will be immediate. The OSP can then issue the Activate and the TN will be returned to the OSP. Waiting for response on SOA /SMG behavior in this situation. 5. Document the cause of the inadvertent port.
Outside of Business Hours for Emergency Situations: There are Porting in Error - Emergency Procedures currently established by the NPAC for resolving Inadvertent Ports outside of NPAC Business Hours. These procedures can be found on the secure region of the NPAC website at http://www.npac.com

CWTA

Issued 2/7/2013

Customer Porting Request Disputes

The Dispute Resolution process was developed to enforce appropriate authorization of porting requests and to provide a means of dealing with customer complaints with regard to unauthorized porting activity. Each carrier agrees to obtain the appropriate authorization for porting requests. In situations where customer complaints arise as a result of unauthorized porting of a number, the carriers agree to the following: The contract holder or customer of record shall determine who the service provider will be. In situations where a port has been completed; porting activity was initiated by someone other than the contract or account owner, and the account/contract owner wishes to have service restored with the Old Service Provider (OSP), the OSP will initiate a port request to port the number back to the OSP. The NSP will be responsible for charges incurred by the OSP to port the number back. In addition, the porting request will be processed as quickly as possible to ensure that service is promptly restored for the customer. (NTD refer to steps identified in the inadvertent porting process above? ) The customer is required to complete an Unauthorized Port form, which the OSP will provide to the NSP at the request of the NSP. The unauthorized individual requesting the port, will be required to use a new number to continue service with the NSP. Carriers will monitor activity related to unauthorized porting and review authorization processes as required to ensure that these incidents are minimized.

8
??

Carrier Dispute Resolution Process

Porting Intervals

Simple wireless to wireless port requests are to be completed within 2.5 hours unless negotiated between the carriers otherwise. Porting involving an MVNO or Reseller, porting requests should be completed within this industry standard, unless the MVNO or Reseller cannot provide the information required for the porting request to be confirmed by the OSP within 30 minutes. In situations where the MVNO or Reseller cannot provide the required information to accommodate the 30 minute response interval, the porting interval will be negotiated by the carriers involved, not to exceed the 2 day porting interval maximum associated with intermodal porting activity. 1 to 5 lines for GUI users 1 to 25 lines for API users

CWTA

10

Issued 2/7/2013

The standard business day is governed by the calendar in the service providers territory in order to recognize variations in Statutory Holidays observed across the country. Hours of operation for trading partners will be identified in Carrier bi-lateral agreements. 9.1 Cancellation Deadline for Porting Requests (information taken from the WICIS document does it work for Canadian wireless?) Porting requests can be cancelled prior to receipt of a Wireless Port Request Response from the OSP. Porting cancellations made after the receipt of a Wireless Port Request will require the completion of the port request by the NSP, with a port following, back to the original OSP. NTD What about the 7 day period for LNP/Intermodal do we want something similar for wireless so that the OSP can cancel a porting request if not activated within 7 days? 9.2 Activation of Number Porting (Should this information be provided in previous section?) When a NSP cannot complete the work required to complete a port request, the NSP must complete the following within the 2.5 hour porting interval: 9.3 Cancel the port request if a response has not yet been received from the OSP, or Issue a supplemental port request with a revised date.

Line Activity Codes This section will relate mainly to intermodal ports and will be dealt with by CISC BPWG.

9.4

Porting of Suspended and Disconnected Telephone Numbers This section provides the industry guidelines for determining whether a suspended or disconnected telephone number is portable between service providers. Customer initiated Suspension and Disconnection When a customer suspends wireless/local service, the current service provider must process a request to port a suspended number. When a customer disconnects service, the current service provider may reject a request to port the disconnected number, and may make the disconnected number available for reassignment in accordance with COCA rules for Aging and Administration of Disconnected Telephone Numbers. Alternatively, the OSP may decide to restore service and agree to port the number to maintain a positive relationship with the customer.

9.4.1

9.4.2

Company-initiated Suspension and Disconnection When a service provider suspends or disconnects service in accordance with either Terms of Service or company policy per Telecom CRTC 97-8, the suspended or disconnected telephone number no longer has the status of a working telephone number. The
11 Issued 2/7/2013

CWTA

suspended or disconnected number regains its working status when the reasons for suspension or disconnection have been resolved. Exceptions to this general rule apply in situations where service has been suspended due to suspected fraud. In these situations, the number should regain its eligibility to port at the customers request. The working status of a telephone number at the time the current service provider receives a request determines whether or not the number is portable: If the telephone number is working at the time that the current service provider receives a request to port to a NSP, the OSP must port the number as requested. The OSP may suspend or disconnect a customers telephone number in accordance with Terms of Service or company policy (subject to CRTC Decision 978) until the confirmed time of the request. The telephone number must, however, be ported as requested. If the telephone number is not working at the time the OSP receives the request to port the number to the NSP, the OSP may reject the port request. The reason for the company-initiated suspension or disconnection of a customers service is confidential information and must not be disclosed to another service provider without the customers consent. 9.5 Hours of Operations The Carrier hours of operation will be defined on a carrier to carrier within the terms of the Bi-Lateral Agreements. For the pupose of the agreements the following definitions of hours of operation will be considered. Carrier ICP Processing Each carrier will determine its own standard business days and hours of operations during which porting requests can be submitted and processed by a Service Provider. These hours will vary dependant on carrier interface type: (i) (ii) OSS Interface will be based on OSS availability GUI Interface will be based on Porting Centre Hours of Operation Wireline will be based on their existing hours of operation.

9.5.1

(iii)

NTD Do we need any guidelines about whether porting requests can be sent to manual/GUI users outside their hours of operations? 9.5.2 Carrier Porting Centers Each carrier will also determine the standard business days and hours of operation during which a Carriers Porting Center is able to provide LNP Support and assistance to Service Providers.

CWTA

12

Issued 2/7/2013

9.5.3

NPAC /NeuStar The NPAC Automated interface is available on a 7 x 24 basis, except within the defined maintenance windows. The NPAC Timers (T1/T2) will operate Hours of timer operations will be from 7:00am to 7:00pm Central Standard Time, Monday to Saturday, Canadian National Holidays excepted.

9.5.4

Syniverse Service Bureau The Synivers Service Bureau is available on a 7 x 24 basis except within the defined maintenance windows. The Syniverse ICP Timer (30 minute timer) will operate during the same business days and hours or operations as the NPAC timers.

9.5.5

MVNOs and Resellers MVNOs and Resellers do not have direct acces to the NPAC and must process port request through their underlying carriers. Process flow charts detailing the handling of port requests involving resellers and MVNOs are included in Appendix > of the CWNPGDevelop procedures to communicate with the underlying carriers for porting requests.

10 Snap Back Process


Wireless Service Providers will align to the existing Snapback process and aging requirements as defined in the Central Office Code Assignment (COCA) Guilelines, Appendix F, which requires a service provider disconnecting a customer on a ported number to notify the NPAC of the disconnect and to return the ported number to the Code Holder after the appropriate aging interval. In addition to the aging performed by the disconnecting carrier, the code holder may chose to age the number for an additional period of time to address their own business requirements.

11 Fall Out
The purpose of this section is to: 12 Intercarrier Communication Processes and Scenarios

CWTA

13

Issued 2/7/2013

12.1 Impacts and Responsibilities The purpose of this section is to describe related activities that both the New Service Provider (NSP) and Old Service Provider (OSP) may encounter, and expected responsibilities related to the ICP. These impacts and responsibilities are not specifically defined within the ICP, but they are critical to a successful implementation.

12.1.1 New Service Provider The NSP has specific responsibilities within the porting process. Some of these responsibilities will fall within proprietary processes that will be unique from service provider to service provider. Other responsibilities will be common to the standardized process that is defined as the ICP. Throughout this document, the part of the process that belongs to the NSP will be referred to as the New Intercarrier Communication Process (NICP). The NSP is responsible for the following activities that fall outside the scope of the intercarrier communication solution: Develop internal procedures for initiating port requests and resolving conflicts Validate the NPA-NXX of the subscribers Mobile Directory Number (MDN) has been opened for porting

Validate the subscribers MDN can be ported into the NSPs coverage area based on rate center Develop a procedure to capture all data elements required for completing a valid request Develop internal procedures that require the receipt of a confirmation of a valid response from OSP prior to sending a create order to the NPAC Develop procedures to handle and correct invalid requests based on OSP response and reason codes Develop procedures to handle complex multi-line ports without undue burden to the process, customer or the OSP Maintain intercarrier contact information for porting issues Staff appropriately to handle porting volumes Obtain customer authorization for port requests Determine Old Network Service Provider (ONSP)

12.1.2 Old Service Provider The OSP has specific responsibilities within the porting process. Some of these responsibilities will fall within proprietary processes that will be unique from service

CWTA

14

Issued 2/7/2013

provider to service provider. Other responsibilities will be common to the standardized process that is defined as the ICP. Throughout this document, the part of the process that belongs to the OSP will be referred to as the Old ICP or OICP. The OSP is responsible for the following activities that fall outside the scope of the Intercarrier Communication solution: Develop internal procedures for receiving port requests and resolving conflicts Develop the staffing and system capacity necessary to meet port volumes Respond to all NSP requests in a timely manner

Develop a procedure to validate information in a manner that would reduce conflicts When producing a response for an invalid request, provide appropriate reason codes, reason code details and remarks Develop a procedure to ensure proper deactivation of all services and features related to the number porting out Maintain intercarrier contact information for porting issues

Develop procedures to generate a delay response, when unable to validate a request within the 30-minute guideline Develop procedures to handle complex multi-line ports without undue burden to the process, customer or the NSP

Ensure that they do not disconnect a porting number from their network until they receive a confirmation from the NPAC that the number is active on the NSPs network.
NTD: Are there specific requirements that need to be developed by MVNOs and Resellers that are not included in the above? 12.2 Wireless to Wireless Porting Process The ICP is defined as the open interface between the NSP and the OSP, used to exchange port requests, port responses and supplemental port requests. The ICP provides the following operations/messages: Wireless Port Request (WPR) submitted by the NSP to the OSP to obtain authorization for porting the identified telephone number(s) Wireless Port Request Response (WPRR) submitted by the OSP in response to a WPR or a Supplemental Port Request (SPR)

CWTA

15

Issued 2/7/2013

Supplemental Port Request (SPR) modifications or cancellations to a previous port request While the ICP clearly defines fields, record layouts, edits and communication procedures, the implementation of the process within proprietary systems may be unique. This allows service providers to build their own ICP solution, purchase one from a third party vendor, or contract with a service bureau. Service providers may have different data entry points such as POS, service order entry (SOE), or a third party system. OSP validation can be automated or manual. The Canadian Wireless Carrieres participating in Wireless Number Portability Implementation have reached consensus on port request validations as follows: Validation of single-line port requests will require Telephone number (mandatory) and one of the following conditional data elements. Account Number Password /PIN ESN /MEID

Validation of multiple-line port requests will require Telephone Numbers (mandatory) and one of the following conditional data elements: Account Number Password /PIN

One of the conditional data elements (Account Number, Password /PIN or ESN /MEID) must be populated on the WPR or the request will be considered invalid or incomplete.

The Clearing House will ensure that all mandatory data fields are populated with the correct data type. If the fields are not populated as required, or are populated with an incorrect type of data, the Clearing House will reject the order as an invalid entry. There are two basic types of wireless ports. The first is a single line port, which is defined as a customer requesting to port one number. The second is a multi-line port, which is defined as a customer requesting to port more than one number. Within the diagram and process narrative, the ICP is divided between functions that relate to the NSP and those that relate to the OSP. This should help the reader in understanding where the event is occurring within the NSP and OSP processes. In some cases, the OSP may be able to respond to a multi-line port within the 30-minute guideline. In other cases, the complexity of the port may require the OSP to inform the NSP of the need for additional time. This section will detail the process flow, a description, and a narrative of the porting process. In the following flows, Confirm means that all data within the request (WPR, SPR) that is being responded to is acknowledged and accepted for all MDNs. Resolution Required response means that at least one MDN or customer information

CWTA

16

Issued 2/7/2013

for at least one MDN on the request cannot be validated and a Delay response means that additional time has been requested for response
Wireless to Wireless Porting Process Flow

The following flow, description, and narrative illustrate the steps that need to occur to complete the intercarrier communication process. Note: This flow is for example purposes only and is not intended to provide a sample of every condition. The implementation of service provider and ICP modules may vary among service providers (represented by the dotted lines between the NSP and New ICP sections and the OSP and Old ICP sections), hence, the use of the dotted line to represent this. However, the interface between ICP modules is well defined via this document.

LNP - W ireless to W ireless ICP Porting Flow

Start End N Cust wants to continue? 18 Y NSP Receives "Delay" Response 13a N Resolve 13b Check reason code & remarks 12a

Continue porting process Y

NSP

O btain subscriber data & auth. 1

12b

Enter required data

NSP resolution

N 14a

Contact OSP & resolve 16

Alarm received Y

15b

Response type equals "C"? 12

New ICP

Edit & format Request

Store & transmit Request 4 3

Rcvd. transmit Acknowledged? 14

Begin time tracking 14b

Timer expired? 15 N

Reset timer

Y 13

Response type equals "D"? 10a

End timer

17

No action required

15a

Response Receipt rcvd, edited 10 Acknowledged & stored

Old ICP

Request rcvd, edited & stored 5

Receipt Acknowledged

Edit & format Response

Store & transmit Response 9 N

Rcvd. transmit Acknowledged ? 11

Validate Request

OSP

5a

Can validate within 30 mins or delayed time ? 6

Complete "Delay" Response

7c N

Complete "Resolution Required" Response 7b Complete "Cofirm" Response

O SP resolution 11a

Is it a "confirm" Response? Y

11b

Data valid for each number? 7 Y

7a

End

Continue porting process

11c

CWTA

17

Issued 2/7/2013

Figure 1 - Wireless to Wireless Port

12.2.1 Detail Description of Process Boxes BOX # 1 2 3 4 5 5A 6 7 7A Name Start Obtain subscriber data & authorization Enter required data Edit & format request Store & transmit request Request rcvd, edited & stored Validate request Can validate within 30 minutes or delayed time? Data valid for each number? Complete Confirm response Complete Resolution Required response with reasons and remarks Complete Delay response with reasons and remarks Edit & format response Description The start point in the process flow The process of obtaining the subscriber information and the authorization to port the numbers. The subscriber information is entered into the NSPs system and sent to the NICP, or manually entered directly into the NICP. The NICP edits the input and formats the request into the proper record format. The NICP stores the request and then transmits it to the OICP according to the routing information. The request is received by the OICP, edited for validity and stored within the OICP. It is forwarded to the OSPs internal system either directly or manually. Each porting telephone number within the request is validated by the OSP. This can be a manual or automated procedure. The OSP will determine if it can complete the validation process within the 30 minutes or the delayed time previously set by the OSP. This box represents decisions based on the validity of each ported line number within the request. If yes to Data valid for each telephone number (Box 7), the OSP prepares a response that indicates confirmation for each ported line number. The response is either sent to the OICP or manually entered directly into the OICP. If no to Data valid for each telephone number (Box 7), then the OSP prepares a response with reasons and remarks as to why a ported line number is not being confirmed. The response is either sent to the OICP, or manually entered directly into the OICP. If no to Can validate within 30 mins or the delayed time previously set? (Box 6), then the OSP prepares a response with delayed time, reasons and remarks as to why the request is being delayed. The response is either sent to the OICP, or manually entered directly into the OICP. The OICP edits the response and formats the request into the proper record format.

7B

7C

CWTA

18

Issued 2/7/2013

BOX # 9 10 10A 11 11A 11B 11C 12 12A 12B 13 13A 13B 14 14A 14B 15 15A 15B 16

Name Store & transmit response Response rcvd, edited, and stored Response type equals D? Rcvd transmit OSP resolution Is Recd transmit confirm (RTC) for a confirm response? Continue porting process Response type equals C? Check reason code & remarks Continue porting process Reset Timer NSP receives Delay response Resolve Rcvd trans. Acknowledged? NSP resolution Begin time tracking Timer expired? No action required Alarm received Contact OSP &

Description The OICP stores the response and then transmits it to the NICP according to the routing information The NICP receives, acknowledges the receipt back to the OICP, edits and stores the Response. If the response type is anything other than delay, end the timer. This box represents a decision based on whether or not the NICP sent a confirmation for the receipt of the transaction sent by the OICP. If no to Received transmit acknowledged? (Box 11), then the OSP takes steps necessary to determine why the transmission was not received by the NICP. Is this acknowledgement for a confirm response? The OSP continues with the porting process. This box represents a decision based on the type of response received from the OSP. The response can be either C = Confirm, D = Delay or R = Resolution Required. If no, to Response = C (Box 12), the NSP will check for the reason code and remarks to determine why request wasnt confirmed. If yes to Response = C (Box 12) then the NSP will continue with the porting process. If yes to Response Type of D, then the timers are reset to reflect the delay time submitted by the OSP. This box represents that the NSP was notified of a Delay response. If no to Box 12, then continue with a resolution process This box represents a decision based on whether or not the OICP sent a confirmation for the receipt of the transaction sent by the NICP. If no to Received transmit Acknowledged? (Box 14), then the NSP takes steps necessary to determine why the transmission was not received by the OICP. If yes to Received transmit Acknowledged? (Box 14), then the NICP initiates the time tracking mechanism that tracks the elapsed time during the ICP. The box represents the on-going time tracking that occurs during the process. If the timer (Box 15) does not expire or if the timer ends due to the completion of the ICP, then no action is required. If the timer does expire (Box 15) before the completion of the process then an alarm is sent by the NICP to the NSP. The NSP initiates process to contact the OSP to determine why

CWTA

19

Issued 2/7/2013

BOX # resolve 17 18

Name End timer Customer wants to continue?

END

Description the Response has not been received within the proper time frame. This box represents the portion of the time tracking mechanism whereby the timer is ended when the NICP receives a Response from the OSP. This box represents the NSP proprietary process initiated with the customer when a Resolution Required Response Type for a porting telephone number is received from the OSP. This could include such things as verification of customer information or notification that the MDN is not a portable number. Represents the end of the ICP.

12.2.2 Narrative for Process Flow The process begins when a customer requests to port their telephone number(s) to the NSP. The NSP should gather the appropriate subscriber information to populate the request. This includes obtaining an authorization from the subscriber to initiate the porting process as required by company policy (Box 1). The NSP should refer to the data elements for mandatory subscriber information. The information gathered should be entered into the proper system, either an integrated POS or SOE system or directly into the NICP (Box 2). The data is edited and formatted according to the rules defined by the CWNPG Document (Box 3). If the edits fail, an error message will be returned to the point of data entry. The formatted record is stored and forwarded to the proper OSP (Box 4). The OICP receives and stores the request. The request is passed to the OSPs Billing and Customer Care (B&CC) system and edited against the Data Dictionary (Box 5). When the OICP receives a Request, a Confirmation of Receipt is issued back to the NICP (Box 14). Once the NICP receives the Confirmation, the Timer is started (Box 14B). If a receipt is not received within the defined time period, the NSP initiates a resolution process (Box 14A). The OSP validates the subscriber information contained on the Request based on proprietary processes (Box 5A). If the request is valid, the OSP populates the proper values for indicating a Confirm response (Box 7A). If the Request cannot be validated, the OSP populates the proper fields to indicate a Resolution Required response to the NSP (Box 7B). If a Request cannot be validated in the appropriate time frame, the OSP populates the proper fields to indicate a Delay response (Box 7C). The data required to issue a Response can be entered through proprietary systems or directly into the OICP. The OICP edits and formats the data (Box 8) according to the Data Dictionary. If the edits fail, an error message will be returned to the point of data entry. The formatted record is stored and forwarded to the proper NSP based on a table of Company Code routing information (Box 9).
CWTA 20 Issued 2/7/2013

The NICP receives and stores the Response (Box 10). When the NICP receives a Response, an acknowledgement (Box 11) is issued back to the OICP. The OSP should not start the NPAC process without this confirmation of receipt from the NSP. This prevents inadvertent cancellations of port requests at the NPAC due to timing errors. When the OICP receives the Confirmation of Receipt, the OSP continues with their Porting Procedures (Box 11B). If a receipt is not received within a defined time period, the OSP initiates a resolution process (Box 11A). The receipt of a response that is not a Delay (Box 10A) ends the Timer (Box 17). If the Timer expires (Box 15) before the receipt of the Response, an alarm will be issued from the NICP and sent to the NSP (Box 15B). The NSP will then contact the OSP for resolution (Box 16). If the Timer is not expired, then no action is required (Box 15A).

The NSP reads the response to determine Response Type (Box 12). If the Response Type is not C for Confirmation, then the NSP interprets Response Type and the Reason Code (Box 12A). Depending on the reason for the Resolution Required, the NSP determines if the port request should continue (Box 18). The NSP can either end the port (END) or correct the information and submit an SPR (Box 2). If the Response Type is a C, then the NSP continues with the porting process (Box 12B). The NSP should not start the NPAC process without receipt of a Confirm response from the OSP.

12.2.3 Complex Ports This section is meant to highlight complex ports in the context of the ICP. Differentiating between a simple port and a complex port is important. A Simple Port involves an account for a single line only (Porting a single line from a multi-line account is not a simple port). Complex ports require more time for data entry, increased coordination between the Service providers and/or additional time for other processes. As a result of this added complexity and coordination-intensity between the service providers, special rules and processes apply to complex ports. There are several unique issues that can add to the complexity and the time required to complete a port request . Multiple Service Providers and Service Types - Depending on the port, multiple service providers may be involved. A customer may port several numbers from multiple OSPs. In addition, there are some service providers who are voice service consolidators or integrators. These Service Providers offer both wireline and wireless services. In these cases, one service provider may need to coordinate a port with either another consolidator of voice services or with multiple Service Providers. The need for this level of coordination could make this a complex port. Number of Lines The number of lines to be ported has notable impact on the complexity and coordination intensity of a port. The port may be considered complex if the number of lines involved becomes onerous depending on whether or

CWTA

21

Issued 2/7/2013

not the service provider has an automated or manual system of communication with other service providers and with the NPAC. Multiple Geographic Locations - Considering a major account or a national account, it is conceivable that a customer requests a multi-line port across multiple geographic locations. The fact that multiple offices for each service provider are involved may cause them to pursue a coordinated project management approach. This increases the coordination intensity of such a port. Therefore, multiple geographic locations may be considered a complex port. Multiple or Different Time Zones The problem of multiple geographic locations is compounded when these locations span time zones. Business hours in one of the time zones involved may be after hours in another. If the parties involved in a port are in two or more time zones, the port can be considered to be complex. Time of Day (After hours or Busy Times) Any port that must be completed at a time other than normal business hours or during particularly busy times during the day can be considered to be complex due to the coordination of personnel to work during these times. Coordination Request from a New Service Provider New service providers may make a discretionary decision based on their internal business rules to request a coordinated port. A request of coordination is always considered a complex port. Ports involving a reseller or MVNO that cannot respond within required timelines to meet the 30 minute response interval will be considered to be complex. Carriers have established the following targets for the number of lines on a WPR that carriers will attempt to process in 2.5 hours o o 1 to 5 lines for GUI users 1 to 25 lines for API users

Regardless of the complexity of the port, a Response Type of Delay, Resolution Required or Confirmation is still required within 30 minutes after a transmission acknowledgment has been received.

12.3 Data Elements This section contains the fields needed to support wireless to wireless porting requests. Time stamps for measuring the performance of the port are not included in this record layout. It is assumed at this time that there will be a header of sorts that tracks the NICP start time and the OICP end time along with possible other important timing milestones. This header would allow systems to determine record aging without having to process the entire record. It is critical to the

CWTA

22

Issued 2/7/2013

success of the process that all service providers use the exact same record layout. Also, the data record should be constructed in the same sequence as shown in the record layout.

Section 3.3.2 includes select samples of populated WPRs, SPRs, and WPRRs. It is not the intent to provide a sample of every condition.

12.3.1 Wireless Port Request Record The information on the Wireless Port Request record is populated by the NSP from either their own internal systems or through data entered directly into NICP. In the table below, the definition for the values in the Type column can be found in the Data Dictionary. The values for length are for the size of the field. The values in the Use column are M for mandatory, C for conditional and O for optional. The values for Data Source indicate the origin of the field. When NSP is specified as the Data Source, it is assumed that either the NSPs systems will generate the information fed to the NICP or the information will be manually entered into the NICP. When the Data Source is SYSTEM, it is assumed that the NICP will generate the required information. For complete descriptions of the field attributes, please refer to the Data Dictionary. NTD: Data Source will be updated as per the technical specifications when they are finalized.

Field CWNPGWICIS _REL_NO NLSP ONSP REQ_NO VER ID REQ SUP NPDI RESP_NO NNSP D/TSENT DDD/T CHC AGAUTH DATED AUTHNM

Description WICIS Release Number New Local Service Provider Old Network Service Provider Request Number Version Identification for the Request Supplement Type Number Portability Direction Indicator Response Number New Network Service Provider Date and Time Sent Desired Due Date and Time Coordinated Hot Cut Agency Authorization Status Date of Agency Authorization Authorization Name

Type N[+] AN AN AN N N[+] A AN AN N N A A N L8A

Length Use Data Source 6 4 4 16 2 1 1 18 4 12 12 1 1 8 60 M M M M M C M M M M M O M C C SYSTEM NSP NSP SYSTEM SYSTEM NSP NSP NSP SYSTEM NSP NSP NSP NSP NSP

CWTA

23

Issued 2/7/2013

Field GREQ_NO INIT IMPCON TEL NO (IMPCON) BILLPREFIX BILLFIRSTNM BILLMDINIT BILLLASTNM BILLSUFFIX BUSNM BILLSTNUM BILLSTNM BILLSTDIR CITY STATE POSTAL CD COUNTRY ACCT PSWD/PIN ESN/MEID NPQTY LNUM PORTED # NAME REMARKS NRSELLNM

Description Group Request Number Initiator Identification Implementation Contact Telephone Number for Implementation Contact Billing Name Prefix Billing First Name Billing Middle Initial Billing Last Name Billing Name Suffix Business Name Billing Street Number Billing Street Name Billing Street Directional City State/Province Postal Code Country Account Number Password/PIN Equipment Identifier Number Portability Quantity Line Number (repeats) Porting Telephone Number (repeats) Name (repeats) Remarks New Reseller Name

Type AN[+] L8A L8A N[+] L8A L8A L8A L8A L8A L8A L7A[-] L8A A L8A A[+] AN[+] L8A AN L8A N N N N[+] L8A L8A L8A

Length Use Data Source 16 15 15 17 10 25 1 25 10 60 10 60 2 35 2 10 3 20 15 17 5 5 17 60 160 20 O M M M O C O C O C C M O M C O C C C C M M M O O C NSP NSP or SYSTEM NSP NSP NSP NSP NSP NSP NSP NSP NSP NSP NSP NSP NSP NSP NSP NSP NSP NSP NSP SYSTEM NSP NSP NSP NSP

12.3.2 Wireless Port Request Response Record The Wireless Port Request Response record is used by the OSP to send a Confirm, Resolution Required or Delay Response back to the NSP. In the table below, when OSP is specified as the Data Source, it is assumed that the information will be automatically or manually entered into the OICP. When the Data Source is OICP, it is assumed that the information is derived from the port Request, provided by the NSP. When the Data Source is SYSTEM, it is assumed that the OICP will generate the required information. It is important to note that all Porting Telephone Numbers involved in the port be listed in the appropriate fields on the Port Response Record. For complete descriptions of the field attributes, please refer to the Data Dictionary.

CWTA

24

Issued 2/7/2013

Field CWNPGWICIS_ REL_ NO NNSP OLSP ONSP REQ_NO VER ID REQ VER ID RESP RT GRESP_NO RESP_NO CD/TSENT REP TEL NO (REP) CHC DD/T NPQTY LNUM PORTED # RCODE RDET REMARKS ORSELLNM DCODE

Description WICIS Release Number New Network Service Provider Old Local Service Provider Old Network Service Provider Request Number Version Identification for the Request Version Identification for the Response Response Type Group Response Number Response Number Confirmation Date and Time Sent Representative Telephone Number for OSPs representative Coordinated Hot Cut Due Date and Time Number Portability Quantity Line Number corresponds to LNUM on the original Request from NSP (repeats) Porting Telephone Number (repeats) Reason Code (repeats) Reason Code Detail (repeats) Remarks Old Reseller Name Delay Code

Type N[+] AN AN AN AN N N A AN[+] AN N L8A N[+] A N N N N[+] AN[+] L8A L8A L8A AN[+]

Length Use Data Source 6 M OICP 4 4 4 16 2 2 1 20 18 12 15 17 1 12 5 5 17 2 60 160 20 2 M M M M M O M O M M M M C M C C C C C C C C OICP OSP OICP OICP OICP OICP OSP OSP SYSTEM SYSTEM OSP OSP OSP OSP or SYSTEM OICP OICP OICP OSP OSP OSP OSP OSP

12.3.3 Supplemental Port Request Record The information on the Supplemental Port Request (SPR) record is populated by the NSP from either their own internal systems or through data entered directly into NICP. SPRs are used to cancel a port request (type 1), change the due date on a port request (type 2), or modify any data on the port request (type 3). SPRs with a SUP value of 2 or 3 should not be sent by the NSP to the OSP until the NSP has received a WPRR with an RT value of C or R for the most recent acknowledged WPR/SPR for the port request. SPRs should follow the same process as the original port request, meaning the same time intervals will be used, and a WPRR will be required from the OSP when an SPR with a SUP value of 2 or 3 is received. SPRs with a SUP value

CWTA

25

Issued 2/7/2013

of 1 may be sent by the NSP prior to receiving a WPRR from the OSP. A WPRR for a SUP Type 1 is recommended but not required. A port response, confirming the information on the SPR, must be sent from the OSP and received by the NSP before the Subscription Version (SV) modification or activation. If the original request has been confirmed, and the NSP has sent the SV-Create to the NPAC, TYPE 3 changes must be communicated to the OSP via an SPR. Type 1 and 2 changes can be made directly via the NPAC or the supplemental process can be used. SPRs cannot be used after SV activation.

12.3.3.1

Supplemental Exchange and Confirmation Procedures

Supplemental port requests (SPRs) are sent by the NSP any time there is additional information available that is pertinent to a port, an initial WPR has been sent by the NSP, and a WPRR with a RT value of C or R has been received by the NSP from the OSP. SPRs can be sent to cancel a WPR in its entirety, change the due date of a WPR, or to modify any information on a particular WPR. It is a requirement to send a SPR with a SUP value of 1 in the event that the NSP desires to cancel a WPR. This assumes that the acknowledgement of the transmission of the WPR has been received by the NSP. An SPR with a SUP value of 1 may be sent prior to receiving a WPRR. It is not necessary for the NSP to send a SPR with a SUP value of 1 if acknowledgement of the transmission of the WPR has not been received by the NSP. Acknowledgement of transmissions is discussed in sections 12.5 and 12.6. For each SPR that is sent for a specific WPR, the NSP shall assign a value to the VERSION ID data element. The VERSION ID must have a value of 02 for the first SPR that is sent for a specific WPR, and, for each subsequent SPR for that same specific WPR, the value of the VERSION ID must be increased in consecutive order with no duplicate values assigned. The OSP must send a WPRR for each SPR with a SUP value of 2 or 3 that is received. The OSP is not required to send a WPRR for an SPR with a SUP value of 1 but can if they choose to. In the case of an SPR with a VERSION ID value that is not in consecutive order, the OSP may send a WPRR with an RCODE value of 7D with a remark indicating an out-of-sequence condition. If this RCODE with associated remarks is received by the NSP, the NSP will be required to submit an SPR with a SUP value of 1. The NSP can then initiate a new WPR with a new REQ_NO for that (those) PORTED#(s). There should be no validation of the VERSION ID REQ field by the OSP when an SPR with a SUP value of 1 is received. The 30-minute response timer begins for each SPR with a SUP value of 2 or 3 when the NNSP receives protocol acknowledgement from the ONSP. No response timers are required for an SPR with a SUP value of 1. SUPPLEMENTAL TYPE 1 (CANCEL ENTIRE PORT REQUEST) Field Description Type N[+] Length Use Data Source 6 M SYSTEM

CWNPGWICIS WICIS Release Number _REL_NO

CWTA

26

Issued 2/7/2013

Field NLSP NNSP ONSP REQ_NO VER ID REQ SUP RESP_NO D/TSENT REMARKS NRSELLNM

Description New Local Service Provider New Network Service Provider Old Network Service Provider Request Number Version Identification for the Request Supplement Type Response Number Date and Time Sent Remarks New Reseller Name

Type AN AN AN AN N N[+] AN N L8A L8A

Length Use Data Source 4 4 4 16 2 1 18 12 160 20 M M M M M M M M O C NSP NSP NSP SYSTEM SYSTEM NSP SYSTEM SYSTEM NSP NSP

SUPPLEMENTAL TYPE 2 (CHANGE DUE DATE ON PORT REQUEST) Field CWNPGWICIS _REL_NO NLSP NNSP ONSP REQ_NO VER ID REQ SUP RESP_NO D/TSENT DDD/T CHC REMARKS NRSELLNM Description WICIS Release Number New Local Service Provider New Network Service Provider Old Network Service Provider Request Number Version Identification for the Request Supplement Type Response Number Date and Time Sent Desired Due Date and Time Coordinated Hot Cut Remarks New Reseller Name Type N[+] AN AN AN AN N N[+] AN N N A L8A L8A Length Use Data Source 6 4 4 4 16 2 1 18 12 12 1 160 20 M M M M M M M M M M O O C SYSTEM NSP NSP NSP SYSTEM SYSTEM NSP SYSTEM SYSTEM NSP NSP NSP NSP

SUPPLEMENTAL TYPE 3 (MODIFY ANY DATA ON PORT REQUEST) Field CWNPGWICIS _REL_NO NLSP ONSP REQ_NO VER ID REQ Description WICIS Release Number New Local Service Provider Old Network Service Provider Request Number Version Identification for the Type N[+] AN AN AN N Length Use Data Source 6 4 4 16 2 M M M M M SYSTEM NSP NSP SYSTEM SYSTEM

CWTA

27

Issued 2/7/2013

Field SUP NPDI RESP_NO NNSP D/TSENT DDD/T CHC AGAUTH DATED AUTHNM GREQ_NO INIT IMPCON TEL NO (IMPCON) BILLPREFIX BILLFIRSTNM BILLMDINIT BILLLASTNM BILLSUFFIX BUSNM BILLSTNUM BILLSTNM BILLSTDIR CITY STATE ZIP CODE COUNTRY ACCT PSWD/PIN ESN/MEID NPQTY LNUM PORTED # NAME REMARKS NRSELLNM

Description Request Supplement Type Number Portability Direction Indicator Response Number New Network Service Provider Date and Time Sent Desired Due Date and Time Coordinated Hot Cut Agency Authorization Status Date of Agency Authorization Authorization Name Group Request Number Initiator Identification (creator) Implementation Contact Telephone Number for Implementation Contact Billing Name Prefix Billing First Name Billing Middle Initial Billing Last Name Billing Name Suffix Business Name Billing Street Number Billing Street Name Billing Street Directional City State/Province Zip Code Country Account Number Password/PIN Equipment Identifier Number Portability Quantity Line Number (repeats) Porting Telephone Number (repeats) Name (repeats) Remarks New Reseller Name

Type N[+] A AN AN N N A A N L8A AN[+] L8A L8A N[+] L8A L8A L8A L8A] L8A L8A L7A[-] L8A A L8A A[+] AN[+] L8A AN L8A N N N N[+] L8A L8A L8A

Length Use Data Source 1 1 18 4 12 12 1 1 8 60 16 15 15 17 10 25 1 25 10 60 10 60 2 35 2 10 3 20 15 17 5 5 17 60 160 20 M M M M M M O M C C O M M M O C O C O C C M O M C O C C C C M M M O M C NSP NSP OSP NSP SYSTEM NSP NSP NSP NSP NSP NSP NSP or SYSTEM NSP NSP NSP NSP NSP NSP NSP NSP NSP NSP NSP NSP NSP NSP NSP NSP NSP NSP NSP SYSTEM NSP NSP NSP NSP

Valid Delay codes are as follows:

CWTA

28

Issued 2/7/2013

6G = Port Complexity 6H = System Outage 6J = High Volume 6L = Request received outside of business hours 8J = Reseller/MVNO unable to meet timelines . 12.3.4 Sample Data Elements Needed for a Single Port To further illustrate the use of the WPR and WPRR records, this section includes a sample of a request to port a single number along with samples of a Confirmation, Resolution Required and Delay response utilized via the standardized communication protocol (CORBA).

SAMPLE WPR RECORD FOR A SINGLE PORT. Field CWNPGWICIS_ REL_NO NLSP ONSP REQ_NO VER ID REQ SUP NPDI RESP_NO NNSP D/TSENT DDD/T CHC AGAUTH DATED AUTHNM GREQ_NO INIT IMPCON TEL NO (IMPCON) BILLPREFIX BILLFIRSTNM Description WICIS Release Number New Local Service Provider Old Network Service Provider Request Number Version Identification for the Request Supplement Type Number Portability Direction Indicator Response Number New Network Service Provider Date and Time Sent Desired Due Date and Time Coordinated Hot Cut Agency Authorization Status Date of Agency Authorization Authorization Name Group Request Number Initiator Identification (creator) Implementation Contact Telephone Number Billing Name Prefix Billing First Name Type N[+] AN AN AN N N[+] A AN AN N N A A N L8A AN[+] L8A L8A N[+] L8A L8A Length Use 6 4 4 16 2 1 1 18 4 12 12 1 1 8 60 16 15 15 17 10 25 M M M M M C M M M M M O M C C O M M M O C Sample Value 3.0.0 1234 5678 12340043230000 01 01 A 1234006365000 000A1 1234 110520001150 110520001450 Y 11052000 Don J Wallace Terry Lori 409-5557779876 Professor Don

CWTA

29

Issued 2/7/2013

Field BILLMDINIT BILLLASTNM BILLSUFFIX BUSNM BILLSTNUM BILLSTNM BILLSTDIR CITY STATE ZIP CODE COUNTRY ACCT PSWD/PIN ESN/MEID NPQTY LNUM PORTED # NAME REMARKS NRSELLNM

Description Billing Middle Initial Billing Last Name Billing Name Suffix Business Name Billing Street Number Billing Street Name Billing Street Directional City State/Province Zip Code Country Account Number Password/Pin Number Equipment Identifier Number Portability Quantity Line Number Porting Telephone Number Name Remarks New Reseller Name

Type L8A L8A L8A L8A L7A[-] L8A A L8A A[+] AN[+] L8A AN L8A N N N N[+] L8A L8A L8A

Length Use 1 25 10 60 10 60 2 35 2 10 3 20 15 17 5 5 17 60 160 20 O C O C C M O M C O C C C C M M M O OC C

Sample Value J Wallace Jr 5301 Morning Creek NW Toronto ON K1P5G4 CAN 1234567890123 4567 00001 00001 409-5556961234 Don Wallace RUSH

SAMPLE WPRR CONFIRMATION RESPONSE FOR A SINGLE PORT. Field CWNPGWICIS_ REL_NO NNSP OLSP ONSP REQ_NO VER ID REQ VER ID RESP RT GRESP_NO RESP_NO CD/TSENT REP Description WICIS Release Number New Network Service Provider Old Local Service Provider Old Network Service Provider Request Number Version Identification for the Request Version Identification for the Response Response Type Group Response Number Response Number Confirmation Date and Time Sent Representative Type N[+] AN AN AN AN N N A AN[+] AN N L8A Length Use 6 M 4 4 4 16 2 2 1 20 18 12 15 M M M M M O M O M M M C 5678104323000 00001 110520001145 J. Represent Sample Value 3.0.0 1234 5678 5678 1234004323000 001 01

CWTA

30

Issued 2/7/2013

Field TEL NO (REP) CHC DD/T NPQTY LNUM PORTED # RCODE RDET REMARKS ORSELLNM

Description Telephone Number for OSPs representative Coordinated Hot Cut Due Date and Time Number Portability Quantity Line Number corresponds to LNUM on original Request from NSP Porting Telephone Number Reason Code Reason Code Detail Remarks Old Reseller Name

Type N[+] A N N N N[+] AN[+] L8A L8A L8A

Length Use 17 M 1 12 5 5 17 2 60 160 20 C M C C C C C CO C

Sample Value 409-5557771234 110520001400 00001 00001 409-5556961234

SAMPLE OF A RESOLUTION REQUIRED WPRR FOR A SINGLE PORT. Field CWNPGWICIS_ REL_NO NNSP OLSP ONSP REQ_NO VER ID REQ VER ID RESP RT GRESP_NO RESP_NO CD/TSENT REP TEL NO (REP) CHC DD/T NPQTY LNUM PORTED # Description WICIS Release Number New Network Service Provider Old Local Service Provider Old Network Service Provider Request Number Version Identification for the Request Version Identification for the Response Response Type Group Response Number Response Number Confirmation Date and Time Sent Representative Telephone Number for OSPs representative Coordinated Hot Cut Due Date and Time Number Portability Quantity Line Number corresponds to LNUM on original Request from NSP Porting Telephone Number Type N[+] AN AN AN AN N N A AN[+] AN N L8A N[+] A N N N N[+] Length Use Sample Value 6 M 3.0.0 4 4 4 16 2 2 1 20 18 12 15 17 1 12 5 5 17 M M M M M O M O M M M M C M C C C R 56781043230000 0001 110520001145 J. Represent 409-5557771234 110520001400 00001 00001 409-5556961234 5678 5678 12340043230000 01 01

CWTA

31

Issued 2/7/2013

Field RCODE RDET

Description Reason Code Reason Code Detail

Type AN[+] L8A

REMARKS ORSELLNM

Remarks Old Reseller Name

L8A L8A

Length Use Sample Value 1234 2 C 6A 60 C Customer Name does not match telephone number 160 O 20 C

Sample of a Timing Delay response for a Single Port. Response Type is populated with a D. A Delay response should only be used when the OSP is encountering circumstances such as a complex port, system outage, or high volumes. Due Date and Time (DD/T) have been updated with the time that the OSP will be able to validate and return a Response. Note that in this response the NPQTY, LNUM, PORTED#, RCODE and RDET fields are not shown. These fields are conditional. When the Response Type is D for Delay, they are prohibited. Field Description CWNPGWICIS_ WICIS Release Number REL_NO NNSP New Network Service Provider OLSP Old Local Service Provider ONSP Old Network Service Provider REQ_NO Request Number VER ID REQ VER ID RESP RT GRESP_NO RESP_NO CD/TSENT REP TEL NO (REP) CHC DD/T REMARKS ORSELLNM DCODE Version Identification for the Request Version Identification for the Response Response Type Group Response Number Response Number Confirmation Date and Time Sent Representative Telephone Number for OSPs representative Coordinated Hot Cut Due Date and Time Remarks Old Reseller Name Delay Code Type N[+] AN AN AN AN N N A AN[+] AN N L8A N[+] A N L8A L8A AN[+] Length Use Sample Value 6 M 3.0.0 4 4 4 16 2 2 1 20 18 12 15 17 1 12 160 20 2 M M M M M O M O M M M M C M O C C D 56781043230000 0001 110520001145 J. Represent 409-5557771234 110520001500 6H 1234 5678 5678 12340043230000 01 01

CWTA

32

Issued 2/7/2013

12.3.5 Sample Data Elements Needed for a Multi-line Port This section includes a sample of a Request to port multiple numbers along with samples of Confirmation and Resolution Required Response utilized via the standardized communication protocol (CORBA). The major difference between the single and multiple line number examples is the ability to repeat specific fields regarding the porting number in the Request and Response. A sample Delay Response is not included here since there are no significant differences from the example shown in the previous section. The following is a sample WPR for a multi-line port. Note that fields LNUM, PORTED#, and NAME repeat. Field Description Type N[+] AN AN AN Length Use 6 4 4 16 2 1 1 18 4 12 12 1 1 8 60 16 15 15 17 10 25 1 25 10 60 10 60 M M M M M C M M M M M O M C C O M M M O C O C O C C M Sample Value 3.0.0 1234 5678 1234004323000 002 01 A 1234 110520001150 110620001400 Y 11052000 Bruce Willis Terry Bradshaw Mike Coleman 409-5557779876-333 Reverend Bruce J Willis Sr P.O. Box 1234

CWNPGWICIS WICIS Release Number _REL_NO NLSP New Local Service Provider ONSP Old Network Service Provider REQ_NO Request Number VER ID REQ

Version Identification for the N Request SUP Supplement Type N[+] NPDI Number Portability Direction A Indicator RESP_NO Response Number AN NNSP New Network Service Provider AN D/TSENT Date and Time Sent N DDD/T Desired Due Date and Time N CHC Coordinated Hot Cut A AGAUTH Agency Authorization Status A DATED Date of Agency Authorization N AUTHNM Authorization Name L8A GREQ_NO Group Request Number AN[+] INIT Initiator Identification (creator) L8A IMPCON Implementation Contact L8A TEL NO Telephone Number for N[+] (IMPCON) Implementation contact BILLPREFIX Billing Name Prefix L8A BILLFIRSTNM Billing First Name L8A BILLMDINIT Billing Middle Initial L8A BILLLASTNM Billing Last Name L8A BILLSUFFIX Billing Name Suffix L8A BUSNM Business Name L8A BILLSTNUM Billing Street Number L7A[-] BILLSTNM Billing Street Name L8A

CWTA

33

Issued 2/7/2013

Field BILLSTDIR CITY STATE ZIP CODE COUNTRY ACCT PSWD/PIN ESN/MEID NPQTY LNUM PORTED # NAME LNUM PORTED # NAME LNUM PORTED # NAME REMARKS NRSELLNM

Description Billing Street Directional City State/Province Zip Code Country Account Number Password/Pin Number Equipment Identifier Number Portability Quantity Line Number Porting Telephone Number Name Line Number Porting Telephone Number Name Line Number Porting Telephone Number Name Remarks New Reseller Name

Type A L8A A[+] AN[+] L8A AN L8A N N N N[+] L8A N N[+] L8A N N[+] L8A L8A L8A

Length Use 2 35 2 10 3 20 15 17 5 5 17 60 5 17 60 5 17 60 160 20

Sample Value

O W M Toronto C ON O K1P5G4 C CAN C C C M 00003 M 00001 M 409-777696-1234 O J. Customer M 00002 M 409-7776961235 O J. Customer M 00003 M 409-5556961236 O J. Customer OC RUSH C

The following is a sample WPRR confirmation for a multi-line port. Note that LNUM, PORTED#, RCODE and RDET repeat. Field Description CWNPGWICIS WICIS Release Number _REL_NO NNSP New Network Service Provider OLSP Old Local Service Provider ONSP Old Network Service Provider REQ_NO Request Number VER ID REQ VER ID RESP RT GRESP_NO RESP_NO CD/TSENT Version Identification for the Request Version Identification for the Response Response Type Group Response Number Response Number Confirmation Date and Time Sent Type N[+] AN AN AN AN N N A AN[+] AN N Length Use 6 M 4 4 4 16 2 2 1 20 18 12 M M M M M O M O M M Sample Value 3.0.0 1234 5678 5678 1234004323000 002 01 01 C 45678 5678104323000 00002 110520001145

CWTA

34

Issued 2/7/2013

Field REP TEL NO (REP) CHC DD/T NPQTY LNUM PORTED # RCODE RDET LNUM PORTED # RCODE RDET LNUM PORTED # RCODE RDET REMARKS ORSELLNM

Description Representative Telephone Number Coordinated Hot Cut Due Date and Time Number Portability Quantity Line Number corresponds to LNUM on original Request from NSP Porting Telephone Number Reason Code Reason Code Detail Line Number corresponds to LNUM on original Request from NSP Porting Telephone Number Reason Code Reason Code Detail Line Number corresponds to LNUM on original Request from NSP Porting Telephone Number Reason Code Reason Code Detail Remarks Old Reseller Name

Type L8A N[+] A N N N N[+] AN[+] L8A N N[+] AN[+] L8A N N[+] AN[+] L8A L8A L8A [-]

Length Use 15 M 17 M 1 12 5 5 17 2 60 5 17 2 60 5 17 2 60 160 20 O M C C C C C C C C C C C C C CO C

Sample Value J. Represent 409-5557779876 110620001400 00003 00001 409-5556961234 00002 409-5556961235 00003 409-5556961236

The following is a sample Resolution Required WPRR for a multi-line port. Note that LNUM, PORTED#, RCODE and RDET repeat. In this example, only one of the numbers in the Request to port requires resolution by the NSP. Field Description CWNPGWICIS WICIS Release Number _REL_NO NNSP New Network Service Provider OLSP Old Local Service Provider ONSP Old Network Service Provider REQ_NO Request Number VER ID REQ Version Identification for the Request Type N[+] AN AN AN AN N Length Use 6 M 4 4 4 16 2 M M M M M Sample Value 3.0.0 1234 5678 5678 12340043230000 02 01

CWTA

35

Issued 2/7/2013

Field VER ID RESP RT GRESP_NO RESP_NO CD/TSENT REP TEL NO (REP) CHC DD/T NPQTY LNUM PORTED # RCODE RDET LNUM PORTED # RCODE RDET LNUM PORTED # RCODE RDET REMARKS ORSELLNM

Description Version Identification for the Response Response Type Group Response Number Response Number Confirmation Date and Time Sent Representative Telephone Number Coordinated Hot Cut Due Date and Time Number Portability Quantity Line Number corresponds to LNUM on original Request from NSP Porting Telephone Number Reason Code Reason Code Detail Line Number corresponds to LNUM on original Request from NSP Porting Telephone Number Reason Code Reason Code Detail Line Number corresponds to LNUM on original Request from NSP Porting Telephone Number Reason Code Reason Code Detail Remarks Old Reseller Name

Type N A AN[+] AN N L8A N[+] A N N N N[+] AN[+] L8A N N[+] AN[+] L8A N N[+] AN[+] L8A L8A L8A

Length Use 2 O 1 20 18 12 15 17 1 12 5 5 17 2 60 5 17 2 60 5 17 2 60 160 20 M O M M M M C M C C C C C C C C C C C C C CO C

Sample Value 01 R 45678 56781043230000 0002 110520001145 J. Represent 409-5557779876 110620001400 00003 00001 409-555696-1234 6A Customer name doesnt match 00002 409-5556961235 7A 00003 409-696-1236 7A

12.3.6 Sample Data Elements Needed for Supplemental Port Requests To further illustrate the use of the Supplemental Port Request and WPRR records, this section includes a sample of a multi-line WPR and SPR along with samples of Confirmation and Resolution Required WPRRs utilized via the standardized communication protocol (CORBA). The same WPRR record will be used for all WPRs and SPRs.

CWTA

36

Issued 2/7/2013

The following is a sample WPR for a Multi-line Port. Field Description Type N[+] AN AN AN Length Use 6 4 4 16 2 1 1 18 4 12 12 1 1 8 60 16 15 15 17 10 25 1 25 10 60 10 60 2 35 2 10 3 20 15 17 5 M M M M M C M M M M M O M C C O M M M O C O C O C C M O M C O C C C C M Sample Value 3.0.0 1234 5678 1234004323000 002 01 A 1234 110520001150 110620001400 Y 11052000 Bruce Willis Terry Bradshaw Mike Coleman 409-5557779876-333 Reverend Bruce C Willis M.D. P.O. Box 1234 NE Toronto ON K1P5G4 CAN

CWNPGWICIS WICIS Release Number _REL_NO NLSP New Local Service Provider ONSP Old Network Service Provider REQ_NO Request Number VER ID REQ

Version Identification for the N Request SUP Supplement Type N[+] NPDI Number Portability Direction A Indicator RESP_NO Response Number AN NNSP New Network Service Provider AN D/TSENT Date and Time Sent N DDD/T Desired Due Date and Time N CHC Coordinated Hot Cut A AGAUTH Agency Authorization Status A DATED Date of Agency Authorization N AUTHNM Authorization Name L8A GREQ_NO Group Request Number AN[+] INIT Initiator Identification (creator) L8A IMPCON Implementation Contact L8A TEL NO Telephone Number for N[+] (IMPCON) Implementation contact BILLPREFIX Billing Name Prefix L8A BILLFIRSTNM Billing First Name L8A BILLMDINIT Billing Middle Initial L8A BILLLASTNM Billing Last Name L8A BILLSUFFIX Billing Name Suffix L8A BUSNM Business Name L8A BILLSTNUM Billing Street Number L7A[-] BILLSTNM Billing Street Name L8A BILLSTDIR Billing Street Directional A CITY City L8A STATE State/Province A[+] ZIP CODE Zip Code AN[+] COUNTRY Country L8A ACCT Account Number AN PSWD/PIN Password/Pin Number L8A ESN/MEID Equipment Identifier N NPQTY Number Portability Quantity N

00003

CWTA

37

Issued 2/7/2013

Field LNUM PORTED # NAME LNUM PORTED # NAME LNUM PORTED # NAME REMARKS NRSELLNM

Description Line Number Porting Telephone Number Name Line Number Porting Telephone Number Name Line Number Porting Telephone Number Name Remarks New Reseller Name

Type N N[+] L8A N N[+] L8A N N[+] L8A L8A L8A

Length Use 5 17 60 5 17 60 5 17 60 160 20 M M O M M O M M O OC C

Sample Value 00001 409-5556961234 J. Customer 00002 409-555-6961235 J. Customer 00003 409-696-1236 J. Customer RUSH

The following is a sample Confirmation WPRR for a Multi-line Port. Field Description CWNPGWICIS WICIS Release Number _REL_NO NNSP New Network Service Provider OLSP Old Local Service Provider ONSP Old Network Service Provider REQ_NO Request Number VER ID REQ VER ID RESP RT GRESP_NO RESP_NO CD/TSENT REP TEL NO (REP) CHC DD/T NPQTY LNUM PORTED # Version Identification for the Request Version Identification for the Response Response Type Group Response Number Response Number Confirmation Date and Time Sent Representative Telephone Number Coordinated Hot Cut Due Date and Time Number Portability Quantity Line Number corresponds to LNUM on original Request from NSP Porting Telephone Number Type N[+] AN AN AN AN N N A AN[+] AN N L8A N[+] A N N N N[+] Length 6 4 4 4 16 2 2 1 20 18 12 15 17 1 12 5 5 17 Use M M M M M M O M O M M M M C M C C C Sample Value 3.0.0 1234 5678 5678 123400432300 0002 01 01 C 567810432300 000002 110520001145 J. Represent 409-5557779876 110620001400 00003 00001 409-555696-

CWTA

38

Issued 2/7/2013

Field RCODE RDET LNUM PORTED # RCODE RDET LNUM PORTED # RCODE RDET REMARKS ORSELLNM

Description Reason Code Reason Code Detail Line Number corresponds to LNUM on original Request from NSP Porting Telephone Number Reason Code Reason Code Detail Line Number corresponds to LNUM on original Request from NSP Porting Telephone Number Reason Code Reason Code Detail Remarks Old Reseller Name

Type AN[+] L8A N N[+] AN[+] L8A N N[+] AN[+] L8A L8A L8A-]

Length 2 60 5 17 2 60 5 17 2 60 160 20

Use C C C C C C C C C C CO C

Sample Value 1234 00002 409-5556961235 00003 409-5556961236

Sample record for an SPR (TYPE 2) to change the due date and/or time. Field CWNPGWICIS _REL_NO NLSP NNSP ONSP REQ_NO VER ID REQ SUP RESP_NO D/TSENT DDD/T CHC REMARKS NRSELLNM Description WICIS Release Number New Local Service Provider New Network Service Provider Old Network Service Provider Request Number Version Identification for the Request Supplement Type Response Number Date and Time Sent Desired Due Date and Time Coordinated Hot Cut Remarks New Reseller Name Type N[+] AN AN AN AN N N[+] AN N N A L8A L8A Length 6 4 4 4 16 2 1 18 12 12 1 160 20 Use M M M M M M M M M M O OC C Sample Value 3.0.0 1234 1234 5678 12340043230 00002 02 2 56781043230 0000002 11052000125 0 11062000110 0 RUSH

CWTA

39

Issued 2/7/2013

Sample Confirmation WPRR for an SPR (TYPE 2). Field CWNPGWICIS _REL_NO NNSP OLSP ONSP REQ_NO VER ID REQ VER ID RESP RT GRESP_NO RESP_NO CD/TSENT REP TEL NO (REP) CHC DD/T NPQTY LNUM PORTED # RCODE RDET LNUM PORTED # RCODE RDET LNUM PORTED # RCODE Description WICIS Release Number New Network Service Provider Old Local Service Provider Old Network Service Provider Request Number Version Identification for the Request Version Identification for the Response Response Type Group Response Number Response Number Confirmation Date and Time Sent Representative Telephone Number Coordinated Hot Cut Due Date and Time Number Portability Quantity Line Number corresponds to LNUM on original Request from NSP Porting Telephone Number Reason Code Reason Code Detail Line Number corresponds to LNUM on original Request from NSP Porting Telephone Number Reason Code Reason Code Detail Line Number corresponds to LNUM on original Request from NSP Porting Telephone Number Reason Code Type N[+] AN AN AN AN N N A AN[+] AN N L8A N[+] A N N N N[+] AN[+] L8A N N[+] AN[+] L8A N N[+] AN[+] Length Use 6 M 4 4 4 16 2 2 1 20 18 12 15 17 1 12 5 5 17 2 60 5 17 2 60 5 17 2 M M M M M O M O M M M M C M C C C C C C C C C C C C Sample Value 3.0.0 1234 5678 5678 1234004323000 002 02 01 C 5678104323000 00002 110520001300 J. Represent 409-5557779876 110620001100 00003 00001 409-5556961234 00002 409-5556961235 00003 409-5556961236

CWTA

40

Issued 2/7/2013

Field RDET REMARKS ORSELLNM

Description Reason Code Detail Remarks Old Reseller Name

Type L8A L8A L8A

Length Use 60 C 160 O 20 C

Sample Value

Sample record for an SPR (TYPE 3). This sample illustrates an address change. Field CWNPGWICIS _REL_NO NLSP ONSP REQ_NO VER ID REQ SUP NPDI RESP_NO NNSP D/TSENT DDD/T CHC AGAUTH DATED AUTHNM GREQ_NO INIT IMPCON TEL NO (IMPCON) BILLPREFIX BILLFIRSTNM BILLMDINIT BILLLASTNM BILLSUFFIX BUSNM BILLSTNUM BILLSTNM BILLSTDIR CITY STATE Description WICIS Release Number New Local Service Provider Old Network Service Provider Request Number Version Identification for the Request Supplement Type Number Portability Direction Indicator Response Number New Network Service Provider Date and Time Sent Desired Due Date and Time Coordinated Hot Cut Agency Authorization Status Date of Agency Authorization Authorization Name Group Request Number Initiator Identification (creator) Implementation Contact Telephone Number for Implementation Contact Billing Name Prefix Billing First Name Billing Middle Initial Billing Last Name Billing Name Suffix Business Name Billing Street Number Billing Street Name Billing Street Directional City Province Type N[+] AN AN AN N N[+] A AN AN N N A A N L8A AN[+] L8A L8A N[+] L8A L8A L8A L8A L8A L8A L7A[-] L8A A L8A A[+] Length Use Sample Value 6 4 4 16 2 1 1 18 4 12 12 1 1 8 60 16 15 15 17 10 25 1 25 10 60 10 60 2 35 2 M M M M M M M M 3.0.0 1234 5678 1234004323000 002 02 3 A 5678104323000 00002 1234 110620001230 110620001400

M M M O M Y C 03052001 C Bruce Willis O M Terry Bradshaw M Mike Coleman M 409-777-9876 O C O C O C C M O M C Professor Bruce D Willis Jr 5301 Morning Creek Cr Toronto ON

CWTA

41

Issued 2/7/2013

Field ZIP CODE COUNTRY ACCT PSWD/PIN ESN/MEID NPQTY LNUM PORTED # NAME LNUM PORTED # NAME LNUM PORTED # NAME REMARKS NRSELLNM

Description Zip Code Country Account Number Password/PIN Equipment Identifier Number Portability Quantity Line Number Porting Telephone Number Name Line Number corresponds to LNUM on original Request from NSP Porting Telephone Number Name Line Number corresponds to LNUM on original Request from NSP Porting Telephone Number Name Remarks New Reseller Name

Type AN[+] L8A AN L8A N N N N[+] L8A N N[+] L8A N N[+] L8A L8A L8A

Length Use Sample Value 10 3 20 15 17 5 5 17 60 5 17 60 5 17 60 160 20 O C C C C M M M O M M O M M O M C K1P5G4

00003 00001 409-5556961234 Don Wallace 00002 409-5556961235 J. Customer 00003 409-5556961236 Tom Customer Changed billing address

Sample Confirmation WPRR for an SPR (TYPE 3). Field CWNPGWICIS_ REL_NO NNSP OLSP ONSP REQ_NO VER ID REQ VER ID RESP RT GRESP_NO Description WICIS Release New Network Service Provider Old Local Service Provider Old Network Service Provider Request Number Version Identification for the Request Version Identification for the Response Response Type Group Response Number Type N[+] AN AN AN AN N N A AN[+] Length 6 4 4 4 16 2 2 1 20 Use M M M M M M O M O Sample Value 3.0.0 1234 5678 5678 123400432300 0002 02 02 C

CWTA

42

Issued 2/7/2013

Field RESP_NO CD/TSENT REP TEL NO (REP) CHC DD/T NPQTY LNUM PORTED # RCODE RDET LNUM PORTED # RCODE RDET LNUM PORTED # RCODE RDET REMARKS ORSELLNM

Description Response Number Confirmation Date and Time Sent Representative Telephone Number for OSPs representative Coordinated Hot Cut Due Date and Time Number Portability Quantity Line Number corresponds to LNUM on original Request from NSP Porting Telephone Number Reason Code Reason Code Detail Line Number corresponds to LNUM on original Request from NSP Porting Telephone Number Reason Code Reason Code Detail Line Number corresponds to LNUM on original Request from NSP Porting Telephone Number Reason Code Reason Code Detail Remarks Old Reseller Name

Type AN N L8A N[+] A N N N N[+] AN[+] L8A N N[+] AN[+] L8A N N[+] AN[+] L8A L8A L8A

Length 18 12 15 17 1 12 5 5 17 2 60 5 17 2 60 5 17 2 60 160 20

Use M M M M C M C C C C C C C C C C C C C O C

Sample Value 567810432300 000002 110520001240 J. Represent 409-5557771234 110520001550 00003 00001 409-5556961234 00002 409-5556961235 00003 409-5556961236

Sample Delay WPRR for an SPR (TYPE 3). Field CWNPGWICIS_ REL_NO NNSP OLSP ONSP REQ_NO Description WICIS Release Number New Network Service Provider Old Local Service Provider Old Network Service Provider Request Number Type N[+] AN AN AN AN Length Use 6 M 4 4 4 16 M M M M Sample Value 3.0.0 1234 5678 5678 1234004323000 002

CWTA

43

Issued 2/7/2013

Field VER ID REQ VER ID RESP RT GRESP_NO RESP_NO CD/TSENT REP TEL NO (REP) CHC DD/T NPQTY LNUM PORTED # RCODE RDET REMARKS ORSELLNM DCODE

Description Version Identification for the Request Version Identification for the Response Response Type Group Response Number Response Number Confirmation Date and Time Sent Representative Telephone Number for OSPs representative Coordinated Hot Cut Due Date and Time Number Portability Quantity Line Number corresponds to LNUM on original Request from NSP Porting Telephone Number Reason Code Reason Code Detail Remarks Old Reseller Name Delay Code

Type N N A AN[+] AN N L8A N[+] A N N N N[+] AN[+] L8A L8A L8A AN[+]

Length Use 2 M 2 1 20 18 12 15 17 1 12 5 5 17 2 60 160 20 2 O M O M M M M C M C C C C C O C C

Sample Value 02 02 D 5678104323000 00002 110520001240 J. Represent 409-5557771234 110520001550

6J

Sample record for an SPR (TYPE 3). This sample illustrates removing two TNs, and changing due date. Field Description Type N[+] AN AN AN N N[+] A AN AN Length Use 6 4 4 16 2 1 1 18 4 M M M M M C M M M Sample Value 3.0.0 1234 5678 1234004323000 002 03 3 A 5678104323000 00002 5678

CWNPGWICIS WICIS Release Number _REL_NO NLSP New Local Service Provider ONSP Old Network Service Provider REQ_NO Request Number VER ID REQ SUP NPDI RESP_NO NNSP Version Identification for the Request Supplement Type Number Portability Direction Indicator Response Number New Network Service Provider

CWTA

44

Issued 2/7/2013

Field D/TSENT DDD/T CHC AGAUTH DATED AUTHNM GREQ_NO INIT IMPCON TEL NO (IMPCON) BILLPREFIX BILLFIRSTNM BILLMDINIT BILLLASTNM BILLSUFFIX BUSNM BILLSTNUM BILLSTNM BILLSTDIR CITY STATE ZIP CODE COUNTRY ACCT PSWD/PIN ESN/MEID NPQTY LNUM PORTED # NAME REMARKS

Description

Type

Length Use 12 12 1 1 8 60 16 15 15 17 10 25 1 25 10 60 10 60 2 35 2 10 3 20 15 17 5 5 17 60 160 M M O M C C O M M M O C O C O C C M O M C O C C C C M M M O M

Sample Value 110520001800 110720001200 Y 11052000 Bruce Willis Terry Bradshaw Mike Coleman 409-5557779876-333 Professor Bruce J Willis Sr 5301 Morning Creek Cr E Toronto ON K1P5G4 CAN

Date and Time Sent N Desired Due Date and Time N Coordinated Hot Cut A Agency Authorization Status A Date of Agency Authorization N Authorization Name L8A Group Request Number AN[+] Initiator Identification (creator) L8A Implementation Contact L8A Telephone Number for N[+] Implementation contact Billing Name Prefix L8A Billing First Name L8A Billing Middle Initial L8A Billing Last Name L8A Billing Name Suffix L8A Business Name L8A Billing Street Number L7A[-] Billing Street Name L8A Billing Street Directional City State/Province Zip Code Country Account Number Password/Pin Number Equipment Identifier Number Portability Quantity Line Number Porting Telephone Number Name Remarks A L8A A[+] AN[+] L8A AN L8A N N N N[+] L8A L8A

00001 00003 409-5556961236 J. Customer Removed TNs 409-5556961234, 409555696-1235, and changed due date

NRSELLNM

New Reseller Name

L8A

20

The following is a sample Confirmation WPRR for SPR (TYPE 3).

CWTA

45

Issued 2/7/2013

Field Description CWNPGWICIS WICIS Release Number _REL_NO NNSP New Network Service Provider OLSP Old Local Service Provider ONSP Old Network Service Provider REQ_NO Request Number VER ID REQ VER ID RESP RT GRESP_NO RESP_NO CD/TSENT REP TEL NO (REP) CHC DD/T NPQTY LNUM PORTED # RCODE RDET REMARKS ORSELLNM Version Identification for the Request Version Identification for the Response Response Type Group Response Number Response Number Confirmation Date and Time Sent Representative Telephone Number Coordinated Hot Cut Due Date and Time Number Portability Quantity Line Number corresponds to LNUM on original Request from NSP Porting Telephone Number Reason Code Reason Code Detail Remarks Old Reseller Name

Type N[+] AN AN AN AN N N A AN[+] AN N L8A N[+] A N N N N[+] AN[+] L8A L8A L8A

Length Use 6 M 4 4 4 16 2 2 1 20 18 12 15 17 1 12 5 5 17 2 60 160 20 M M M M M O M O M M M M C M C C C C C CO C

Sample Value 3.0.0 1234 5678 5678 1234004323000 002 03 03 C 5678104323000 00002 110520001830 J. Represent 409-5557779876 110720001200 00001 00003 409-5556961236

Sample record for an SPR (TYPE 3). This sample illustrates adding a TN. Field Description Type N[+] AN AN AN N Length Use 6 4 4 16 2 M M M M M Sample Value 3.0.0 1234 5678 1234004323000 002 04

CWNPGWICIS WICIS Release Number _REL_NO NLSP New Local Service Provider ONSP Old Network Service Provider REQ_NO Request Number VER ID REQ Version Identification for the

CWTA

46

Issued 2/7/2013

Field SUP NPDI RESP_NO NNSP D/TSENT DDD/T CHC AGAUTH DATED AUTHNM GREQ_NO INIT IMPCON TEL NO (IMPCON) BILLPREFIX BILLFIRSTNM BILLMDINIT BILLLASTNM BILLSUFFIX BUSNM BILLSTNUM BILLSTNM BILLSTDIR CITY STATE ZIP CODE COUNTRY ACCT PSWD/PIN ESN/MEID NPQTY LNUM PORTED # NAME LNUM PORTED # NAME

Description Request Supplement Type Number Portability Direction Indicator Response Number

Type N[+] A AN

Length Use 1 1 18 4 12 12 1 1 8 60 16 15 15 17 10 25 1 25 10 60 10 60 2 35 2 10 3 20 15 17 5 5 17 60 5 17 60 C M M M M M O M C C O M M M O C O C O C C M O M C O C C C C M M M O M M O

Sample Value 3 A 5678104323000 00002 5678 110620001100 110720001200 Y 11052000 Bruce Willis Terry Bradshaw Mike Coleman 409-5557779876-333 Professor Bruce J Willis M.D. 5301 Morning Creek Cr S Toronto ON K1P5G4 CAN

New Network Service Provider AN Date and Time Sent N Desired Due Date and Time N Coordinated Hot Cut A Agency Authorization Status A Date of Agency Authorization N Authorization Name L8A Group Request Number AN[+] Initiator Identification (creator) L8A Implementation Contact L8A Telephone Number for N[+] Implementation contact Billing Name Prefix L8A Billing First Name L8A Billing Middle Initial L8A Billing Last Name L8A Billing Name Suffix L8A Business Name L8A Billing Street Number L7A[-] Billing Street Name L8A Billing Street Directional City State/Province Zip Code Country Account Number Password/Pin Number Equipment Identifier Number Portability Quantity Line Number Porting Telephone Number Name Line Number Porting Telephone Number Name A L8A A[+] AN[+] L8A AN L8A N N N N[+] L8A N N[+] L8A

00002 00003 409-5556961236 J. Customer 00004 409-5556961240 J. Customer

CWTA

47

Issued 2/7/2013

Field REMARKS NRSELLNM

Description Remarks New Reseller Name

Type L8A L8A

Length Use 160 20 M C

Sample Value Added TN 409555696-1240

The following is a sample Resolution Required WPRR for SPR (TYPE 3). Field CWNPGWICIS _REL_NO NNSP OLSP ONSP REQ_NO VER ID REQ VER ID RESP RT GRESP_NO RESP_NO CD/TSENT REP TEL NO (REP) CHC DD/T NPQTY LNUM PORTED # RCODE RDET LNUM PORTED # RCODE RDET Description WICIS Release Number New Network Service Provider Old Local Service Provider Old Network Service Provider Request Number Version Identification for the Request Version Identification for the Response Response Type Group Response Number Response Number Confirmation Date and Time Sent Representative Telephone Number Coordinated Hot Cut Due Date and Time Number Portability Quantity Line Number corresponds to LNUM on original Request from NSP Porting Telephone Number Reason Code Reason Code Detail Line Number corresponds to LNUM on original Request from NSP Porting Telephone Number Reason Code Reason Code Detail Type N[+] AN AN AN AN N N A AN[+] AN N L8A N[+] A N N N N[+] AN[+] L8A N N[+] AN[+] L8A Length Use 6 M 4 4 4 16 2 2 1 20 18 12 15 17 1 12 5 5 17 2 60 5 17 2 60 M M M M M O M O M M M M C M C C C C C C M C MC Sample Value 3.0.0 1234 5678 5678 1234004323000 002 04 04 R 89598398 5678104323000 00002 110620001120 J. Represent 409-5557779876 110620001560 00002 00003 409-5556961236 7A 00004 409-5556961240 6D Customer

CWTA

48

Issued 2/7/2013

Field

Description

Type

Length Use

REMARKS ORSELLNM

Remarks Old Reseller Name

L8A L8A

160 20

M C

Sample Value doesnt have service on 409555696-1240 No service for 404-5556961240

Sample record for a SPR (TYPE 1). This sample illustrates canceling a port request. Field CWNPGWICIS _REL_NO NLSP NNSP ONSP REQ_NO VER ID REQ SUP RESP_NO D/TSENT REMARKS NRSELLNM Description WICIS Release Number New Local Service Provider New Network Service Provider Old Network Service Provider Request Number Version Identification for the Request Supplement Type Response Number Date and Time Sent Remarks New Reseller Name Type N[+] AN AN AN AN N N[+] AN N L8A L8A Length 6 4 4 4 16 2 1 18 12 160 20 Use Sample Value M M M M M M M M M OC C 3.0.0 1234 1234 5678 1234004323000 002 05 1 5678104323000 00002 110620001600

Sample Confirmation WPRR for an SPR (TYPE 1). Field CWNPGWICIS_ REL_NO NNSP OLSP ONSP REQ_NO VER ID REQ VER ID RESP Description WICIS Release Number New Network Service Provider Old Local Service Provider Old Network Service Provider Request Number Version Identification for the Request Version Identification for the Response Type N[+] AN AN AN AN N N Length Use 6 M 4 4 4 16 2 2 M M M M M O Sample Value 3.0.0 1234 5678 5678 1234004323000 002 05 05

CWTA

49

Issued 2/7/2013

Field RT GRESP_NO RESP_NO CD/TSENT REP TEL NO (REP) CHC DD/T NPQTY LNUM PORTED # RCODE RDET REMARKS ORSELLNM

Description Response Type Group Response Number Response Number Confirmation Date and Time Sent Representative Telephone Number for OSPs representative Coordinated Hot Cut Due Date and Time Number Portability Quantity Line Number corresponds to LNUM on original Request from NSP Porting Telephone Number Reason Code Reason Code Detail Remarks Old Reseller Name

Type A AN[+] AN N L8A N[+] A N N N N[+] AN[+] L8A L8A L8A

Length Use 1 M 20 O 18 M 12 15 17 1 12 5 5 17 2 60 160 20 M M M C M C C C C C O C

Sample Value C 5678104323000 00002 110620001608 J. Represent 409-555-7771234 110520001400 00001 00001 409-5556961234

12.3.7 Sample Data Elements Needed for a Single Port Containing Resellers To further illustrate the use of the WPR and WPRR records, this section includes a sample of a Request to port a single number along with samples of a Confirmation involving Resellers. NTD if this applies to the Canadian environment Sample WPR record for a Single Port involving a New Reseller. Field CWNPGWICIS_ REL_NO NLSP ONSP REQ_NO VER ID REQ Description WICIS Release Number New Local Service Provider Old Network Service Provider Request Number Version Identification for the Type N[+] AN AN AN N Length Use 6 4 4 16 2 M M M M Sample Value 3.0.0

5555 5678 1234004323000 003 M 01

CWTA

50

Issued 2/7/2013

Field SUP NPDI RESP_NO NNSP D/TSENT DDD/T CHC AGAUTH DATED AUTHNM GREQ_NO INIT IMPCON TEL NO (IMPCON) BILLPREFIX BILLFIRSTNM BILLMDINIT BILLLASTNM BILLSUFFIX BUSNM BILLSTNUM BILLSTNM BILLSTDIR CITY STATE ZIP CODE COUNTRY ACCT PSWD/PIN ESN/MEID NPQTY LNUM PORTED # NAME REMARKS NRSELLNM

Description Request Supplement Type Number Portability Direction Indicator Response Number New Network Service Provider Date and Time Sent Desired Due Date and Time Coordinated Hot Cut Agency Authorization Status Date of Agency Authorization Authorization Name Group Request Number Initiator Identification (creator) Implementation Contact Telephone Number Billing Name Prefix Billing First Name Billing Middle Initial Billing Last Name Billing Name Suffix Business Name Billing Street Number Billing Street Name Billing Street Directional City State/Province Zip Code Country Account Number Password/Pin Number Equipment Identifier Number Portability Quantity Line Number Porting Telephone Number Name Remarks New Reseller Name

Type N[+] A AN AN N N A A N L8A AN[+] L8A L8A N[+] L8A L8A L8A L8A L8A L8A L7A[-] L8A A L8A A[+] AN[+] L8A AN L8A N N N N[+] L8A L8A L8A

Length Use 1 1 18 4 12 12 1 1 8 60 16 15 15 17 10 25 1 25 10 60 10 60 2 35 2 10 3 20 15 17 5 5 17 60 160 20 C M M M M M O M C C O M M M O C O C O C C M O M C O C C C C M M M O OC MC

Sample Value

A 1234 110520001150 110520001450 Y 11052000 Don Wallace Terry Lori 409-5557779876 Reverend Don D Wallace Sr 5301 Morning Creek NE Toronto ON K1P5G4

1234567890123 4567 00001 00001 409-5556961234 Don Wallace RUSH New Reseller Inc.

CWTA

51

Issued 2/7/2013

Sample WPRR confirmation response for a single port involving an Old Reseller without an OCN. Field CWNPGWICIS_ REL_NO NNSP OLSP ONSP REQ_NO VER ID REQ VER ID RESP RT GRESP_NO RESP_NO CD/TSENT REP TEL NO (REP) CHC DD/T NPQTY LNUM PORTED # RCODE RDET REMARKS ORSELLNM Description WICIS Release Number New Network Service Provider Old Local Service Provider Old Network Service Provider Request Number Version Identification for the Request Version Identification for the Response Response Type Group Response Number Response Number Confirmation Date and Time Sent Representative Telephone Number for OSPs representative Coordinated Hot Cut Due Date and Time Number Portability Quantity Line Number corresponds to LNUM on original Request from NSP Porting Telephone Number Reason Code Reason Code Detail Remarks Old Reseller Name Type N[+] AN AN AN AN N N A AN[+] AN N L8A N[+] A N N N N[+] AN[+] L8A L8A L8A Length Use 6 M 4 4 4 16 2 2 1 20 18 12 15 17 1 12 5 5 17 2 60 160 20 M M M M M O M O M M M M C M C C C C C CO MC C 5678104323000 00003 110520001145 J. Represent 409-5557771234 110520001400 00001 00001 409-5556961234 Sample Value 3.0.0 1234 ZZZZ 5678 1234004323000 003 01

Old Reseller Co.

12.4 Data Edits, Formatting and Transmission Section 4 of this document is a Data Dictionary that details the valid values for all fields on both the Request and Response. A Response or Request is incomplete until all required fields are completed and validated. There are three types of fields: Mandatory Required for the Request or Response to be valid.

CWTA

52

Issued 2/7/2013

Conditional Required if specific conditions have been met. The Data Dictionary defines the conditions for these types of fields. Optional Not required for the Request or Response to be considered valid.

Once a Request or Response is populated with all the mandatory fields, the ICP will validate the data and format it into the standardized record for transmission. It is assumed that some service providers will have Application Programming Interfaces (APIs) from their existing systems to the ICP. The intent of the edit and format steps is to ensure that the data is correct before it is transmitted. This includes the ability to send error messages that give specific information as to the error. It is expected that the ICP include standard communication protocols to ensure Responses and Requests are sent correctly. This would include Confirmation of Receipt for the delivery of transactions between service providers. It is a requirement to have the ability to resubmit a WPR, SPR, or WPRR if an acknowledgement to any transmission is not received by the sender.

12.4.1 Standard Communication Protocol This should be replaced with Canadian Protocol information

12.5 Clearinghouse A clearinghouse is defined as a separate entity that supports connectivity between Service Providers and/or Service Bureaus in order to receive and forward port requests and port response messages. There may be any number of clearinghouses made available to facilitate the ICP connectivity. However, the use of a clearinghouse is optional. The inclusion of a clearinghouse solution should not materially affect the way two Service Providers interact using the ICP module as defined in this document (that is, the clearinghouse(s) will be transparent to the ICP module).

A. Port Request example

CWTA

53

Issued 2/7/2013

NNSP ICP Module

Clearing House #1 Port Request Port Request

Clearing House #2

ONSP ICP Module

Port Request Request Acknowledgement

Request Acknowledgement Request Acknowledgement

In the above drawing, the NNSP does not assume receipt of the port Request until the ONSP returns the acknowledgement. Intermediate clearinghouses do not return any acknowledgements prior to receipt of the ONSP acknowledgement.

CWTA

54

Issued 2/7/2013

B. Port Response example

NNSP ICP Module

Clearing House #1

Clearing House #2 Port Response

ONSP ICP Module

Port Response Response Acknowledgement

Port Response

Response Acknowledgement

Response Acknowlegement

In the above drawing, ONSP does not assume receipt of the port response until the NNSP returns the acknowledgement. Intermediate clearinghouses do not return any acknowledgement prior to receipt of the NNSP acknowledgement. This messaging behavior, shown in the above examples, applies to all ICP messaging (e.g., port response, supplements). If several clearinghouses are involved, all clearinghouses behave in the same way.

12.6 Industry Established Response Timelines Current industry goals suggest 30 minutes for the completion of the Intercarrier Communication Process. The process documented here requires the ONSP to send a WPRR within 30 minutes even if that WPRR contains an RT value of D for Delay. This will let the NNSP know that progress is being made on the Request, but that it wont be completed in time. If the ONSP sends a Response indicating that more time is needed, then the ONSP will be required to populate an estimated date and time when the validation will be complete. Timers and alarms within the ICP should be reset by the NNSP to the agreed date and time. Due to the variance in time properties between carrier systems, the determination of when to begin the 30 minute time interval varies slightly between old and new network service providers. The NNSP should begin the 30 minute interval when they receive confirmation that the WPR has been successfully transmitted to the ONSP. The ONSP should begin their 30 minute interval upon automated receipt of the WPR from the NNSP.
CWTA 55 Issued 2/7/2013

In order to reduce fall-out and to account for any variance in time properties between the carrier systems, it is recommended that the new network service providers cushion the 2 hour and 30 minute port window when populating their Desired Due Date on the WPR or Supplemental Request (by setting their DDD/T at a suggested minimum of 2 hours and 45 minutes). NTD: Can we do the same? Do we need to add anything for MVNOs and Resellers?

CWTA

56

Issued 2/7/2013

12.7 Version Control The following version control rules were established to provide for an orderly and logical migration from one release of the CWNPG to the next beginning with version 1.0.0. Release numbers are stated in the format: X.Y.Z (minimum of 5, maximum of 6 Numeric Plus [including Hex value 2F]) where X represents a record layout change Y represents an inter-Service Provider interface behavioral change Z represents a clarification change Valid Ranges for X.Y.Z X range: 1-99 Y range :0- 9 Z range :0-9 Examples of valid release numbers are: 3.0.0 3.0.3 3.5.0 21.3.1 For version control purposes currently contained in the CWNPG, the N version is considered to be the unique combination of X and Y. These rules apply to all implementations of the CWNPG after the initial implementation of March 14, 2007: 1) No more than two production versions are supported at any time; the sunrise date for the N+1 version can never be earlier than the day after the sunset date for the N-1 version. 2) Sunrise and sunset dates are to be determined by industry consensus for each release. 3) Service providers are required to support version N up to its sunset date. 4) Service providers may implement the N+1 version any time between the sunrise date of the N+1 version and the sunset date of the N version.

CWTA

57

Issued 2/7/2013

The following shows these rules in timeline format:

Sunrise date for version N Version N-1 Version N

Sunset date Sunrise date Sunset date for version N-1 for version N+1

for version N

Version N+1

12.8 Backward Compatibility This section provides information in regard to maintaining two versions of software releases and will contain any necessary mappings defined for changes to the document. Backward compatibility rules have been defined as the following: The N+1 implementation/version must be able to support the N version until the sunset date of N. Service Providers moving to N+1 must determine how to support the N version until the sunset of N. The N+1 Service Provider is responsible for mapping to the N version for requests and translating the responses from the N Service Provider to the N+1 format if necessary. Where possible, the CWNPG Work Stream will provide industry guidelines for the operational handling and mapping of new/changed data elements. This definition does not supercede Section 3.8 of the CWNPG document, which defines version control.

13 Data Dictionary
The following section describes the data element specification and usage for all data fields indicated on the port Request and port Response records. All fields presented in the data dictionary should be left justified with no trailing spaces or blanks, unless otherwise stated

CWTA

58

Issued 2/7/2013

for a specific data element. Variable length fields (identified by a minimum and/or maximum length in the Validation Description column) are initialized to an empty value. A non-populated field is represented as an empty value. For the IDL implementation, the following applies: -An empty value for variable length strings is defined as the empty string (zero length null terminated or zero length). -An empty value for a fixed length character array is defined as populated with the NULL character or the space/blank character. -All date and time fields presented in this data dictionary should utilize the GMT format unless otherwise specified. Medium column indicates if element applies to an IDL (I) interface. Conventions The CWNPG incorporates the following conventions for the population of form entries: Mandatory - the field must be populated in order for the WPR, SPR, or WPRR to be considered valid Optional - the field may or may not be populated Prohibited - the field must not be populated Conditional - population of this field is dependent upon the presence, absence, or combination of other data entries NOTE: Examples provided in the Data Dictionary may not represent all possible values, however, when a carrier populates the field, the entry must be within the restrictions provided in the Validation Description. Limited 7-Bit ASCII (L7A)=Hex 09, 0A, 0D, 20-7E Limited 7-Bit ASCII Minus (L7A[-])=L7A excluding identified characters

8-bit character set (code page) based upon WE8ISO8859P1 (L8A) (see decimal values 161 255 plus Limited 7-bit ASCII described in table below) Alphanumeric Plus
(AN[+])=Hex 30-39, 41-5A, 61-7A, + additional characters from L7A set as defined Numeric Plus (N[+])=Hex 30-39, + additional characters from L7A set as defined Alphanumeric (AN)=Hex 30-39, 41-5A and 61-7A Alpha (A)=Hex 41-5A and 61-7A Alpha Plus (A[+])=Hex 41-5A, 61-7A, + additional characters from L7A set as defined Numeric(N)=Hex 30-39 Null (Null)=Hex 00 ENUM(ENUM)=List of specific values defined in the IDL structure

Decimal 0 9 10 13

Octal 00 11 12 15

Hex 00 09 0A 0D

Character Null TAB LF CR

Decimal 32 33 34 35

Octal 40 41 42 43

Hex 20 21 22 23

Character Space/Blank ! " #

CWTA

59

Issued 2/7/2013

Decimal 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77

Octal 44 45 46 47 50 51 52 53 54 55 56 57 60 61 62 63 64 65 66 67 70 71 72 73 74 75 76 77 100 101 102 103 104 105 106 107 110 111 112 113 114 115

Hex 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D

Character $ % & ' ( ) * + , / . 0 1 2 3 4 5 6 7 8 9 : ; < = > ? @ A B C D E F G H I J K L M

Decimal 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118

Octal 115 117 120 121 122 123 124 125 126 127 130 131 132 133 134 135 136 137 140 141 142 143 144 145 146 147 150 151 152 153 154 155 156 157 160 161 162 163 164 165 166

Hex 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76

Character N O P Q R S T U V W X Y Z [ \ ] ^ _ ` a b c d e f g h i j k l m n o p q r s t u v

CWTA

60

Issued 2/7/2013

Decimal 119 120 121 122 123 124 125 126


161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193

Octal 167 170 171 172 173 174 175 176


241 242 243 244 245 246 247 250 251 252 253 254 255 256 257 260 261 262 263 264 265 266 267 270 271 272 273 274 275 276 277 300 301

Hex 77 78 79 7A 7B 7C 7D 7E
A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 BA BB BC BD BE BF C0 C1

Character w x y z { | } ~

Decimal
194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234

Octal
302 303 304 305 306 307 310 311 312 313 314 315 316 317 320 321 322 323 324 325 326 327 330 331 332 333 334 335 336 337 340 341 342 343 344 345 346 347 350 351 352

Hex
C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA

Character

CWTA

61

Issued 2/7/2013

Decimal
235 236 237 238 239 240 241 242 243 244 245

Octal
353 354 355 356 357 360 361 362 363 364 365

Hex
EB EC ED EE EF F0 F1 F2 F3 F4 F5

Character

Decimal
246 247 248 249 250 251 252 253 254 255 256

Octal
366 367 370 371 372 373 374 375 376 377

Hex
F6 F7 F8 F9 FA FB FC FD FE FF

Character

Element ACCT

Medium Description I Account Number This field indicates the customers account number within the OSPs internal systems. NOTE: Account Number should be formatted as contiguous characters consisting solely of the digits 0 through 9 and the letters Aa through Zz with no imbedded blanks. Record: WPR, SUP3 Derivation: NSP process Conditions: Conditional For single-line ports; mandatory if neither the PSWD/PIN or the ESN/MEID data elements are populated. For multi-line ports; Mandatory if the PSWD/PIN data element is not populated Values: Alphanumeric values

Validation Description Maximum 20 position AN

CWTA

62

Issued 2/7/2013

Element AGAUTH

Medium Description I

Validation Description Agency Authorization Status This field indicates 1 position A that the NSP has the appropriate authorization from the subscriber to request the port. Record: WPR, SUP3 Derivation: NSP process Conditions: Mandatory Valid Values: Y = Authorization on file N = No Authorization on file

AUTHNM

Authorization Name This field indicates the end Maximum 60 position L8A user that authorized the request to port the number. Record: WPR, SUP3 Derivation: NSP process Conditions: Conditional mandatory when AGAUTH = Y, optional when AGAUTH = N. Values: L8A [excluding Hex values 09, 0A, 0D] Format: FirstName MiddleInitial LastName Billing First Name This field relates to Maximum 25 position subscriber information. This is the billing first L8A name for the user requesting the port. This field identifies the name of the end user. However, it is not intended for directory services. Record: WPR, SUP3 Derivation: NSP process Conditions: Conditional mandatory if BUSNM is not populated; optional if BUSNM is populated. Values: L8A [excluding Hex values 09, 0A, 0D]

BILLFIRSTNM I

CWTA

63

Issued 2/7/2013

Element BILLLASTNM

Medium Description I Billing Last Name This field relates to subscriber information. This is the last name of the end user requesting the port. This field identifies the name of the end user. However, it is not intended for directory services. Record: WPR, SUP3 Derivation: NSP process Conditions: Conditional mandatory if BUSNM is not populated; optional if BUSNM is populated. Values: L8A [excluding Hex values 09, 0A, 0D]

Validation Description Maximum 25 position L8A

BILLMDINIT

Billing Name Middle Initial This field relates to Maximum 1 position subscriber information. This is the middle initial L8A, NULL of the end user requesting the port. This field identifies the name of the end user. However, it is not intended for directory services. Record: WPR, SUP3 Derivation: NSP process Conditions: Optional used if billing middle initial provided. Values: L8A [excluding Hex values 09, 0A, 0D], NULL

BILLPREFIX

Billing Name Prefix This field is intended to capture the billing name prefix. Record: WPR, SUP3 Derivation: NSP process Conditions: Optional used if billing name prefix is provided. Values: L8A [excluding Hex values 09, 0A, 0D] Examples: Reverend Professor

Maximum of 10 position L8A

CWTA

64

Issued 2/7/2013

Element BILLSTDIR

Medium Description I Billing Street Directional This field is intended to capture the street directional for the billing address. This directional abbreviation is a suffix to the BILLSTNM. Any prefix directional should be included as part of the BILLSTNM. Record: WPR, SUP3 Derivation: NSP process Conditions: Optional used if billing street address direction is provided. Values: Alpha values Examples: E = East W = West N = North S = South NE = Northeast NW = Northwest SE = Southeast SW = Southwest

Validation Description Maximum of 2 position A

BILLSTNM

Billing Street Name This field is intended to capture the street name of the billing address. Street, P.O. Box, Rural Route, Military, Foreign, Rural Free Delivery, etc. address types should be entered in this field. Record: WPR, SUP3 Derivation: NSP process Conditions: Mandatory

Maximum of 60 position L8A

Values: L8A [excluding Hex values 09, 0A, 0D]


Examples: Lucerne Way Rural Route 30 P. O. Box 1146 Peachtree Rd Suite 200 Old National Hwy Room 10 Milton Lane Apt 2B

CWTA

65

Issued 2/7/2013

Element BILLSTNUM

Medium Description I Billing Street Number This field is intended to capture the street/house number of the billing address. Record: WPR, SUP3 Derivation: NSP process Conditions: Conditional mandatory if billing street address is used; optional for all other address types (PO Box, Rural Route, Military, Foreign, Rural Free Delivery, etc.). Values: Limited 7-Bit ASCII Minus [excluding Hex values 09, 0A, 0D] Billing Name Suffix This field is intended to capture the billing name suffix. Record: WPR, SUP3 Derivation: NSP process Conditions: Optional used if billing name suffix is provided. Values: L8A [excluding Hex values 09, 0A, 0D] Examples: Jr Sr
III

Validation Description Maximum of 10 position L7A[-]

BILLSUFFIX

Maximum of 10 position L8A

Values: L8A [excluding Hex values 09, 0A, 0D] Examples: Jr Sr III M.D.

CWTA

66

Issued 2/7/2013

Element BUSNM

Medium Description Validation Description Business Name This field relates to subscriber Maximum of 60 position I information. This is the Business Name for the L8A company requesting the port. This field identifies the name of the company. However, it is not intended for directory services. Record: WPR, SUP3 Derivation: NSP process Conditions: Conditional mandatory if BILLFIRSTNM and BILLLASTNM are not populated; optional if BILLFIRSTNM and BILLLASTNM are populated. Values: L8A [excluding Hex values 09, 0A, 0D] Confirmation Date and Time Sent This field 12 position indicates the date and time that the OSP N completed the confirmation or validation of the subscriber information. MMDDYYYYHHMM Record: WPRR Derivation: OSP process. Conditions: Mandatory Values: Numeric values Valid values: MM = 01 12 DD = 01 31 YYYY = 20x HH = 00 23 MM = 00 59 x
HH = 00 23 MM = 00 59

CD/TSENT

CWTA

67

Issued 2/7/2013

Element CHC

Medium Description Coordinated Hot Cut This field indicates a I request by the NSP to ensure a coordinated effort to port all numbers on the request at the same time. This may require manual intervention and coordination between the service providers. Record: WPR, WPRR, SUP2, SUP3 Derivation: NSP and OSP process Conditions: Optional used if the NSP requires coordination of port request. On a WPR, SUP2 or SUP3 the NSP can either not populate the CHC field or populate with Y. The value of N is prohibited. On a WPRR the OSP can either not populate the CHC field or populate with either Y or N. If the NSP has populated the value of Y on a WPR, SUP2 or SUP3, then the OSP must populate the CHC field with either a Y or N on the WPRR. When the NSP has sent the WPR or SUP with CHC not populated, the OSP is not allowed to populate CHC in the WPRR. Values: Alpha values Valid Values: Y, N or Not Populated Y = Hot Cut Requested by NSP or Agreed to by OSP N = OSP Can not Coordinate Hot Cut Not Populated No Coordinated Hot Cut requested City This field identifies the city of the subscribers billing address. Record: WPR, SUP3 Derivation: NSP process Conditions: Mandatory Values: L8A

Validation Description 1 position A, ENUM

CITY

Maximum of 35 position L8A

CWTA

68

Issued 2/7/2013

Element COUNTRY

Medium Description I Country This field identifies the country of the end users billing address. Record: WPR, SUP3 Derivation: NSP process Conditions: Conditional mandatory if the billing address is outside of the US and Canada; optional if the billing address is within the US and Canada. When Country is populated with USA, CAN or not populated, then PROV/STATE is mandatory and PC/ZIP is optional. Values: L8A

Validation Description Maximum of 3 position L8A

D/TSENT

Date and Time Sent This field indicates the date 12 position and time that the request was sent from the NSP. N This date and time is populated within the NSPs MMDDYYYYHHMM internal process. Record: WPR, SUP1, SUP2, SUP3 Derivation: NSP process prior to sending the request. This Date and Time changes with each new Version. Conditions: Mandatory Values: Numeric values Valid values: MM = 01 12 DD = 01 31 YYYY = 20xx HH = 00 23 MM = 00 59

CWTA

69

Issued 2/7/2013

Element DATED

Medium Description I Date of Agency Authorization This field indicates the date that the port authorization was received. Record: WPR, SUP3 Derivation: NSP process Conditions: Conditional mandatory when AGAUTH = Y, optional when AGAUTH = N Values: Numeric values MM = 01 12 DD = 01 31 YYYY = 20xx

Validation Description 8 position N MMDDYYYY

DCODE

I,

Delay Code populated only for a Delay response 2 position (i.e. when the value in the RT field is D) in a AN[+], NULL WPRR; this data element is used to communicate the reason for the delay from the OSP to the NSP; the DCODE is returned at the request level, not at the LNUM level. When the DCODE field is populated, the NPQTY field is not populated; when the DCODE field is populated, LNUMs and the information included in the LNUM array are not populated; a Delay response applies to the entire specific WPR or SPR. Record: WPRR Derivation: OSP process Conditions: Conditional: mandatory if RT has a value of D; prohibited if RT does not have a value of D. Values: Alphanumeric Plus values [including Hex value 20], NULL Valid Values: 6G = Port Complexity 6H = System Outage 6J = High Volume 6L = Request received outside of business hours 8J = Reseller/MVNO unable to meet timelines.

CWTA

70

Issued 2/7/2013

Element DD/T

Medium Description I

Validation Description 12 position Due Date and Time On a Confirm response when NPDI = A or B for a WPR, SUP 2 or 3, N the DD/T should match the NSP Desired Due Date and Time on the Request you are responding MMDDYYYYHHMM to. When the NPDI = C on a confirm response for a WPR, SUP 2 or 3 the DD/T may be different than the DDD/T on the WPR/SPR. On a confirmation response to a SUP 1, the DD/T is not required to match the DDD/T from the most recently received WPR, SUP 2, or SUP 3. For a Delay response, this value is the date and time that the OSP expects to send a confirmation or resolution required. Should the due date and time become invalid, a subsequent Delay may be sent. For a Resolution Required response, this field indicates the date and time that the OSP can coordinate a port.

Record: WPRR Derivation: OSP process Conditions: Mandatory Values: Numeric values Valid Values: MM = 01 12 DD = 01 31 YYYY = 20xx HH = 00 23 MM = 00 59

CWTA

71

Issued 2/7/2013

Element DDD/T

Medium Description I Desired Due Date and Time This is the desired due date and time for the completion of the port and activation of service on the NSP system. Record: WPR, SUP2, SUP3 Derivation: NSP process Conditions: Mandatory Values: Numeric values Valid Values: MM = 01 12 DD = 01 31 YYYY = 20xx HH = 00 23 MM = 00 59 Note: In order to reduce fall-out and to account for any variance in time properties between carrier systems, it is recommended that the new network service providers cushion the 2 hour and 30 minute port window when populating their Desired Due Date on the WPR or Supplemental Request (by setting their DDD/T at a suggested minimum of 2 hours and 45 minutes).

Validation Description 12 position N MMDDYYYYHHMM

ESN/MEID

Equipment Identifier This is the Electronic Maximum of 17 position Serial Number (ESN) / Mobile Equipment N Identifier (MEID) used to identify the subscribers handset. This field can be collected from the subscribers handset so the port can proceed even if the subscriber does not know their Account Number or Password/PIN at the time of port. ESN/MEID field will be expressed in decimal 17 digit format. Record: WPR, SUP3 Derivation: NSP process Conditions: Conditional single line ports: mandatory if neither the ACCT nor the PSWD/PIN data elements are not populated; for multi-line ports: not valid. Values: Numeric

CWTA

72

Issued 2/7/2013

Element GREQ_NO

Medium Description Validation Description Group Request Number - This field is used by the Maximum of 16 position I NSP to relate multiple requests generated by the AN[+] NICP back to a single customer, requesting service. For example, if a customer wants to port numbers from two different OSPs, two Requests are created with two different REQ NO. The GREQ NO would tie the two requests back to the single customer. Can be an internal Service Order Entry or Point of Sale number. This field is used primarily for complex ports. Record: WPR, SUP3 Derivation: NSP process Conditions: Optional used when the NSP desires to relate multiple requests. There is no relation between GREQ NO and GRESP NO. Values: Alphanumeric Plus values [including Hex value 20 Group Response Number This field indicates the Maximum of 20 position unique number assigned by the OSP, used to AN[+] relate multiple port responses together. This field can be used for internal OSP utilization. Record: WPRR Derivation: OSP process Conditions: Optional - used when the OSP desires to relate multiple responses. There is no relation between GREQ_NO and GRESP_NO. Values: Alphanumeric Plus values [including Hex value 20

GRESP_NO

CWTA

73

Issued 2/7/2013

Element IMPCON

Medium Description Validation Description Implementation Contact This field identifies the Maximum of 15 position I NSP representative who is in control of the port. L8A This is the name of a NSP representative or porting center. The OSP would use this for a point of contact in resolving issues. Record: WPR, SUP3 Derivation: NSP process Conditions: Mandatory Values: L8A [excluding Hex values 09, 0A, 0D] Initiator Identification This field identifies the NSP representative who originated the request. Record: WPR, SUP3 Derivation: NSP process Conditions: Mandatory Values: L8A [excluding Hex values 09, 0A, 0D]

INIT

Maximum of 15 position L8A

CWTA

74

Issued 2/7/2013

Element LNUM

Medium Description Line Number On the initial Request, this field I consist of consecutive numbering, starting at 1 of each telephone number or range involved in a request. On subsequent versions of the initial Request or once the LNUM is generated, it cannot be changed and is reserved through the completion of the request. Therefore, when the OSP issues the response, the LNUM must be retained. In addition, each response to a either a WPR or Supplemental WPR will echo back each occurrence of LNUM and the fields related to LNUM except for a Delay response (RT = D). There is to be a single occurrence of each LNUM on the WPR, SPR (SUP =3) and WPRR. This field repeats as part of an array. Record: WPR, WPRR, SUP3 Derivation: NSP process; OSP populates from most recently received WPR or SUP 3 Conditions: Mandatory for WPRs and SUP 3; conditional for WPRR: mandatory when RT has a value of C or R ; prohibited when RT has a value of D. Values: Numeric values Valid Values: 00001 01000

Validation Description 5 position N Right justify-zero fill

NAME

Name This field identifies the phone end user. Name repeats as part of an array. Record: WPR, SUP3 Derivation: NSP process Conditions: Optional. Values: L8A [excluding Hex values 09, 0A, 0D]

Maximum of 60 position L8A

CWTA

75

Issued 2/7/2013

Element NLSP

Medium Description I

Validation Description New Local Service Provider This field indicates 4 position AN an Operating Company Number (OCN) of the New Service Provider requesting the port. In the case when the new local service provider is the same company as the new network service provider, the value of the NNSP field should be copied into this field. When the new local service provider is a reseller, and they do not have an OCN, this field should be populated with the value of ZZZZ.

Record: WPR, SPR Derivation: NSP process Conditions: Mandatory Values: Alphanumeric values Valid Values: Any valid OCN, SPID, or ZZZZ. NNSP I 4 position New Network Service Provider This field indicates the NPAC managed SPID of the facility- AN based provider (NSP). This information is used by the OSP in generating the subscription version create. Record: WPR, WPRR, SPR, FAK, FEX Derivation: NSP process; OSP populates from WPR or SUP. Conditions: Mandatory Values: Alphanumeric values Valid Values: Any valid SPID value

CWTA

76

Issued 2/7/2013

Element NPDI

Medium Description I Number Portability Direction Indicator This field is used to indicate the direction of the port. Within the description of the Number Portability Direction Indicator, the first is the OSP and the second is the NSP. For example, Value B is Wireless to Wireline. The OSP is Wireless and the NSP is Wireline. Record: WPR SUP 3 Derivation: NSP process Conditions: Mandatory Values: Alpha values Valid Values: Upper Case Values A = Wireless to Wireless B = Wireless to Wireline C = Wireline to Wireless

Validation Description 1 position or checkbox A, ENUM

NPQTY

Number Portability Quantity This field indicates 5 position the quantity of telephone numbers involved in the N port request. Right justify-zero fill Record: WPR, WPRR, SUP3 Derivation: NSP process; OSP populates from most recently received WPR or SUP 3. Conditions: Mandatory for WPRs and SUP 3; conditional for WPRR: mandatory when RT has a value of C or R ; prohibited when RT has a value of D. Values: Numeric values Valid Values: 00001-10000

CWTA

77

Issued 2/7/2013

Element NRSELLNM

Medium Description I New Reseller Name This field indicates the name of the New Reseller involved in the port Request. Record: WPR, SPR Derivation: NSP process Conditions: Conditional mandatory if NLSP is a reseller, otherwise not populated Values: L8A [excluding Hex values 09, 0A, 0D]

Validation Description Maximum of 20 position L8A

OLSP

Old Local Service Provider This field indicates 4 position AN the Operating Company Number (OCN) of the Old Service Provider. In the case when the old local service provider is the same company as the old network service provider, the value of the ONSP field should be copied into this field. When the old local service provider is a reseller, and they do not have an OCN, this field should be populated with the value of ZZZZ. Record: WPRR Derivation: OSP process Conditions: Mandatory Values: Alphanumeric values Valid Values: Any valid OCN, SPID, or ZZZZ.

CWTA

78

Issued 2/7/2013

Element ONSP

Medium Description Validation Description I 4 position Old Network Service Provider This field indicates the NPAC managed SPID of the facility- AN based provider (OSP). This information is used by the NSP in generating the subscription version create. Record: WPR, WPRR, SPR, FAK, FEX Derivation: NSP process: OSP populated from WPR or SUP. Conditions: Mandatory Values: Alphanumeric values Valid Values: Any valid SPID value

ORSELLNM

Old Reseller Name This field indicates the name Maximum 20 position of the Old Reseller involved in the port response. L8A Record: WPRR Derivation: OSP process Conditions: Conditional mandatory if OLSP is a reseller, otherwise not populated Values: L8A [excluding Hex values 09, 0A, 0D]

PSWD/PIN

Maximum of 15 position Password/Pin Number This field indicates the customers password or pin number specified on L8A his/her account within the OSPs internal systems. Record: WPR, SUP3 Derivation: NSP process Conditions: Conditional for single-line ports; Mandatory if neither the ACCT or the ESN/MEID data elements are populated, for multi-line ports; mandatory if the ACCT date element is not populated Values: L8A [excluding Hex values 09, 0A, 0D]

CWTA

79

Issued 2/7/2013

Element PORTED#

Medium Description I

Validation Description Porting Telephone Number This field indicates a 12 or 17 position N[+] single telephone number (TN) or range of consecutive TNs to be ported. Each telephone NPA-NXX-L111-L222 number can occur only once in any given WPR, Left justified SPR, or WPRR this field repeats as part of an array.

Record: WPR, WPRR, SUP3 Derivation: NSP process; OSP populates from most recently received WPR or SUP 3. Conditions: Mandatory for WPRs and SUP 3; conditional for WPRR: mandatory when RT has a value of C or R ; prohibited when RT has a value of D. Values: Numeric Plus values [Including Hex value 2D] Examples: Single Telephone Number: 409-6961234 Range of Consecutive Numbers: 409-6961000-1999

CWTA

80

Issued 2/7/2013

Element RCODE

Medium Description I

Validation Description Reason Code This field indicates the OSPs port 2 position request issue requiring resolution, per each porting AN[+], NULL telephone number (TN) or consecutive range of TNs. For any given WPRR, only one RCODE is allowed to be sent for each LNUM. This field repeats as part of an array. Reason codes beginning with a zero are only valid if the OSP is a wireline carrier.

Record: WPRR Derivation: OSP process Conditions: Conditional mandatory when RT is equal to R; prohibited when RT is equal to C or D. When responding to a SUP 2 when RT = R the only valid RCODES are: 6E = Due Date cant be met 6F = Due Time cant be met 1P = Other (Remarks must be DD/T specific) Values: Alphanumeric Plus values [including Hex value 20], NULL Valid Values: 1P = Other 6A = MDN not found/doesnt belong to this SP 6B = Same new and old Network Provider 6C = Customer information does not match (should only be used in cases where no other RCODEs beginning with 8 are applicable) 6D = MDN not active 6E = Due Date cant be met 6F = Due Time cant be met 6K = Administrative number-not portable 6N = Port request already pending duplicate request 6P = MDN has service provider port protection 7A = LNUM/MDN is valid; errors with other LNUMs/MDNs in request 7D = VER ID REQ out of sequence 8A = Account number incorrect 8C = Password/PIN incorrect 8D = Zip code required or incorrect 8H = ESN/MEID incorrect (valid on single-lin port requests only) 8X = Cancellation of WPR by OSP 01 = Name does not match database
CWTA 81 Issued 2/7/2013

Element RDET

Medium Description Validation Description Reason Code Detail This field indicates the OSP Maximum of 60 position I narrative detail as to why the port request requires L8A resolution (Response Type = R) or is delayed (Response Type = D), for each RCODE. There is a single occurrence of this field for each LNUM on the response. This field repeats as part of an array. Record: WPRR Derivation: OSP process Conditions: Conditional mandatory when RT = R ; prohibited when RT = C or D; Values: L8A Remarks This field may be used for comments Maximum of 160 by the NSP or OSP. position L8A Record: WPR, WPRR, SPR Derivation: NSP process or OSP process Conditions: Conditional mandatory if SUP3; optional if SUP1 or SUP2; optional on WPR, mandatory on WPRR with RCODE of 1P. Values: L8A Representative This field indicates the OSP Contact Representative for issues surrounding a port Response. (same verbiage as NSP contact) Record: WPRR Derivation: OSP process Conditions: Mandatory Values: L8A [excluding Hex values 09, 0A, 0D]

REMARKS

REP

Maximum of 15 position L8A

CWTA

82

Issued 2/7/2013

Element REQ_NO

Medium Description Request Number A unique number assigned by I the NSPs ICP to track Requests generated by the system. It is the responsibility of the NSP to ensure their corporate processes or their implementation of the ICP does not generate duplicate REQ_NOs. Note: If NPDI = A or C, then the NNSP segment of this element may be validated to match the value populated in the NNSP field. The request number in its entirety should only be validated to ensure it is not a duplicate. Record: WPR, WPRR, SPR, FAK, FEX Derivation: NSP Process, OSP populates from WPR Conditions: Mandatory Values: Alphanumeric values Request Number = NNSPIYYJJJXXXXXX NNSP=NNSP value from WPR I=numeric Host ID [ICP HOST ID] (0-9, varies per instance of multiple ICPs per SPID) YY=last two digits of the system year as generated by the NNSP (00-99) JJJ=system julian date as generated by the NNSP (001-366) XXXXXX=1-6 position unique alphanumeric value (0-9, A-Z)

Validation Description Minimum 11, Maximum 16 position AN NNSPIYYJJJXXXXXX NOTE: REQ_NO should be formatted as contiguous characters consisting solely of the digits 0 through 9 and the letters A through Z with no imbedded blanks or special characters.

CWTA

83

Issued 2/7/2013

Element RESP_NO

Medium Description Response Number This field uniquely identifies I the port response(s) sent to the NSP for a given REQ NO. Note: If NPDI = A or B, then the ONSP segment of this element may be validated to match the value populated in the ONSP field. The response number in its entirety should only be validated to ensure it is not a duplicate. Record: WPR, WPRR, SPR, FAK, FEX Derivation: OSP process, NSP populates from WPRR or not populated Conditions: Mandatory Values: Alphanumeric values Response Number = ONSPIYYJJJXXXXXXXX ONSP=ONSP value from WPR I=numeric Host ID [ICP HOST ID] (0-9, varies per instance of multiple ICPs per SPID) YY=last two digits of the system year as generated by the ONSP (00-99) JJJ=system julian date as generated by the ONSP (001-366) XXXXXXXX=1-8 position unique alphanumeric value (0-9, A-Z) Not populated on WPR Not populated or populated with RESP_NO from WPRR on SUP 1. Populated with RESP_NO from WPRR on SUP 2 or 3.

Validation Description Minimum 11, Maximum 18 position AN For IDL: Zero length field on initial WPR. (For SUP 1 either a zero length field or populated with RESP_NO returned from OSP.) ONSPIYYJJJXXXXXX XX NOTE: RESP_NO should be formatted as contiguous characters consisting solely of the digits 0 through 9 and the letters A through Z with no imbedded blanks or special characters.

CWTA

84

Issued 2/7/2013

Element RT

Medium Description Validation Description Response Type This field indicates the type of 1 position or checkbox I response sent from the OSP. If all Porting A, ENUM Telephone Numbers within the port request have been accepted by the OSP, the Response Type would be C for Confirmation. If any Porting Telephone Numbers or customer information within the request cannot be validated by the OSP, the Response Type would be R for Resolution Required. If the OSP cannot validate the initial Request within the 30-minute guideline, a Response with a Response Type of D for Delay is required. If the OSP cannot meet the updated Due Date and Time from a previous Delay, a subsequent Delay may be sent. Record: WPRR Derivation: OSP process Conditions: Mandatory Values: Alpha values Valid Values: C = Confirmation D = Delay R = Resolution State/Province This field identifies the two character postal code abbreviation for the state/province of the subscribers billing address. Record: WPR, SUP3 Derivation: NSP process Conditions: Conditional Mandatory when Country is USA, CAN or not populated; otherwise optional. Values: Alphanumeric Plus values [including Hex value 20], NULL When Country is USA, CAN or not populated, the Valid Values are the Canadian Postal Abbreviations for the Canadian Provinces and Territories and US States and Territories. For more specific information, please refer to the Canadian Postal Service Website.)

STATE

2 position A[+], NULL

CWTA

85

Issued 2/7/2013

Element SUP

Medium Description Supplement Type This field identifies the reason I for a change to the original port request. The supplemental type represents any new iteration of a port request. Record: WPR, SPR Derivation: NSP Process Conditions: Conditional mandatory on a port request when utilized as a supplement to the initial request; not populated on initial port request. Values: Numeric Plus values [including Hex value 20] Valid Values: Not populated on WPR. 1 = Cancel Indicates that the pending order is to be cancelled in its entirety 2 = New Desired Due Date and Time Indicates that the pending order requires only a change of desired due date and time 3 = Other Indicates any other change to the request. This value requires an entry in the Remarks field to specifically identify the changes. For the NSP, except for the changed fields, the remainder of the request must be identical to the original request issued. For the OSP, a SUP Type 3 is a complete replacement of the prior request.

Validation Description 1 position or checkbox N[+] The SUP field is not populated on the initial Request

TEL NO (IMPCON)

Telephone Number This is the telephone number for the Implementation Contact (IMPCON). It includes space for a four-digit extension line. Record: WPR, SUP3 Derivation: NSP process Conditions: Mandatory Values: Numeric Plus values [including Hex value 2D]

Minimum 12, maximum 17 position N [+] NPA-NXX-LLLLXXXX Left justify

CWTA

86

Issued 2/7/2013

Element TEL NO (REP)

Medium Description I

Validation Description Telephone Number - OSP Contact Representative Minimum 12, maximum 17 position Telephone Number for issues surrounding this N [+] port request and response. NPA-NXX-LLLLXXXX Left justify

Record: WPRR Derivation: OSP process Conditions: Mandatory Values: Numeric Plus values [including Hex value 2D] VER ID REQ I Version Identification for the Request This field is used to identify subsequent issues related to the original port request. Must be a value of 01 on the initial port request and incremented by a value of +01 for each subsequent request related to the initial request. On a WPRR the value received in the associated WPR or SPR should be returned. Record: WPR, WPRR, SPR, FAK, FEX Derivation: NSP Process; OSP populates from WPR or SUP Conditions: Mandatory must be populated on all WPRs, WPRRs and SPRs; must be a value of 01 on each WPR and incremented by a value of +01 for each related SPR. This field should not be validated by the OSP if receiving a SUP1. Values: Numeric values Valid Values: 01 99 beginning with each WPR and incremented by +01 for each related SPR.

2 position N

CWTA

87

Issued 2/7/2013

Element VER ID RESP

Medium Description Version Identification for the Response This I field is used to identify subsequent issues related to the original port request. Record: WPRR, FAK, FEX Derivation: OSP Process; NSP populates from WPRR. Conditions: Optional populated on the WPRR at the option of the OSP. Required on Intermodal WPRR Values: Numeric Examples: 01 99 as additional updated Responses are sent from the OSP to the NSP. CWNPG Release Number This field identifies the CWNPG release being utilized by the NSP and OSP for the request and response. It consists of 3 subfields which must be at least a single digit for the X, Y and Z components of the CWNPG Version Number separated by periods. Record: WPR, WPRR, SPR Derivation: NSP Process, OSP populates from WPR Conditions: Mandatory Values: Numeric Plus [including Hex value 2F] Valid Value: 3.0.0

Validation Description 2 position N

CWNPG_REL_ I NO

5 to 6 position N[+] X.Y.Z X range: 1-99 Y range :0- 9 Z range :0-9 Left justified No zero padding

CWTA

88

Issued 2/7/2013

Element ZIP CODE

Medium Description ZIP Code/Postal Code This field identifies the F, I zip code or postal code of the subscribers billing address. When billing address in in the US, a US five or nine-digit Zip Code may be used in the PC data element Record: WPR, SUP3 Derivation: NSP process Conditions: Optional NOTE: In the GUI, the field label will be Postal Code /Zip Code in the interface doc, the field label will remain Zip to minimize changes Values: Alphanumeric Plus values [including Hex values 20 or 2D] Valid Values: When Country is USA, CAN or not populated,, the valid format for Zip is either xxxxx-xxxx for US (with 5 characters being the minimum) or xxxxxx for Canadian)

Validation Description Maximum 10 position AN[+] xxxxx-xxxx for US xxxxxx for Canadian

CWTA

89

Issued 2/7/2013

14 Glossary of Terms
Term/Acronym AMPS B&CC BPWG CC CDMA CISC CMRS CRTC CWNPG CWTA EDI FOC Definition Advanced Mobile Phone System Billing & Customer Care Business Process Working Group Customer Care Code Division Multiple Access CRTC Industry Steering Committee Commercial Mobile Radio Service Canadian Radio Television and Telecommuncation Commission Canadian Wireless Number Portability Guidelines Canadian Wireless Telecommunicaitons Association Electronic Data Interface. A standard mechanized exchange of data. Standards developed at the national level. Firm Order Confirmation. A Service Provider returns an FOC in response to an initial LSR from another Provider. The FOC is the document or data structure used to either confirm that the information presented in the LSR is correct and accurate or to reject the LSR based on errors, omissions, or requests that cannot be met. In an LNP environment, the FOC is sent by the losing or old service provider back to the requesting or new service provider. If the recipient of the LSR is not the current provider of the requested TNs, then the LSR should be rejected. Greenwich Mean Time Global System for Mobile Communication Intercarrier Communication Process Interface Definition Language International Mobile Station Identifier. 15-digit, non-dialable identifier, specific to a service provider, and unique for each mobile station. Currently, the IMSI is used in GSM networks. It equates to the MIN in non-GSM networks. Interoperable Naming Service Interoperable Object Reference Local Number Portability. Local Number Portability Administration Working Group Location Routing Number. A 10 digit number that uniquely identifies a switch. Every ported subscribers MDN is associated with an LRN. This number will be used to route a call to the ported subscriber. The number will point to the entry point switch to which the calls will be routed to for call completion. Local Service Management System Local Service Provider Local Service Request. An established document or data structure currently in use by the Wireline industry for the purpose of communicating between providers. The standard mechanized exchange is EDI. These are also manually exchanged by fax. Each service provider must agree with every other Service Provider individually as to what method of exchange will be used. Mobile Directory Number the 10 digit NANP number that is dialed to reach a

GMT GSM ICP IDL IMSI INS IOR LNP LNPA_WG LRN

LSMS LSP LSR

MDN

CWTA

90

Issued 2/7/2013

Term/Acronym MIN

MSID MSISDN NAG NANC NANP NECA NICP NP NP DB NPAC NPAC-SMS NSP OBF OICP ORB OSP OSS POS PSTN RBOC RFI SLA SMR SMS SOA

SOE

SPID SV

Definition specific terminal see also: MSISDN. Mobile Identification Number a 10 digit number used by the cellular network for the purpose of communication between the cellular switch and the cellular phone. This is the number that, along with the Electronic Serial Number (ESN), is programmed into the cellular phone. In the pre-LNP environment, the MIN and MDN are the same number. In the post-LNP environment, the MIN and MDN will be different for ported MDNs. The MIN and IMSI are referred to collectively as MSID (Mobile Subscriber Identity). Mobile Station Identifiereither a MIN or IMSI will be used. This could be a 10 digit MIN in the NPA-NXX-XXXX format or an E.212 IMSI. Mobile Subscriber Integrated Services Digital Network the term used in GSM terminology to refer to the 10-digit NANP number that is dialed to reach a specific GSM terminal. Number Advisory Group North American Numbering Council North American Numbering Plan National Exchange Carrier Association New Intercarrier Communication Process Number Portability Number Portability Database Number Portability Administration Center Number Portability Administration Center Service Management System New Service Provider Ordering and Billing Forum Old Intercarrier Communication Process Object Request Broker Old Service Provider Operations Support System Point of Sale or Point of Service Public Switched Telecommunications Network Regional Bell Operating Company Request for Information Service Level Agreement Specialized Mobile Radio Short Message Service Service Order Administration. The software that sits between a Billing/Customer Care SOE system and the NPAC that facilitates communication with the NPAC. Among other functions, it is the vehicle used to establish a ported number entry in the NPAC. Service Order Entry. A focal point where requests from multiple users are funneled to pass to the SOA. This may be the billing/customer care system or another delivery point that would provide the funnel from multiple system(s) locations. This architecture needs to be designed. Service Provider Identification Subscription Version. NPAC SMS data object that represents a ported telephone number.
91 Issued 2/7/2013

CWTA

Term/Acronym TDMA TLDN URI WNP WPR WPRR WSP

Definition Time Division Multiple Access Temporary Local Directory Number Universal Resource Identifier Wireless Number Portability. Interchangeable with LNP, but often used when pointing out differences between the Landline and Wireless porting processes. Wireless Port Request Wireless Port Request Response Wireless Service Provider

CWTA

92

Issued 2/7/2013

Ordering Timeframes

Orders should not normally be submitted more than (appropriate interval) in advance of the desired port completion time. Simple wireless to wireless port requests are to be completed within 2.5 hours unless negotiated between the carriers otherwise. For porting involving an MVNO or Reseller, porting requests should be completed within this industry standard, unless the MVNO or Reseller cannot provide the information required for the porting request to be confirmed by the OSP within 30 minutes. In situations where the MVNO or Reseller cannot provide the required information to accommodate the 30 minute response interval, the porting interval will be negotiated by the carriers involved, not to exceed the 2 day porting interval maximum associated with inter-modal porting activity. The standard business day is governed by the calendar in the service providers territory in order to recognize variations in Statutory Holidays observed across the country. What is appropriate from a wireless to wireless perspective? A daily cut-off time has been established in conjunction with the receipt of a port request and the return of the corresponding response. For wireless to wireless ports, a port request must be received 30 minutes prior to the end of the business hours of the NSP the port request to commence on the date of receipt (Does this work from an ICP perspective or does the timer commence with the porting request is initiated?).

1.1

Order Completion Notification (Covered in a previous section?)

Notification of completed orders will be provided to the NSP and OSP by NPAC. (Need to confirm?) In the event that orders cannot be completed as requested, the OSP will provide notification to the NSP with an indication as to why the port request cannot be completed. In addition, the OSP will provide information as to when the porting request will be completed. Carriers will review issues relating to porting requests not completed within required timelines, taking corrective action as required to resolve systemic issues.

CWTA

93

Issued 2/7/2013

1.2

Cancellation Deadline for Porting Requests (information taken from the WICIS document does it work for Canadian wireless?)

Porting requests can be cancelled prior to receipt of a Wireless Port Request Response from the OSP. Porting cancellations made after the receipt of a Wireless Port Request will require the completion of the port request by the NSP, with a port following, back to the original OSP.

1.3

Activation of Number Porting Should this information be provided in previous section?

When a NSP cannot complete the work required to complete a port request, the NSP must complete the following within the 2.5 hour porting interval: Cancel the port request if a response has not yet been received from the OSP, or Issue a supplemental port request with a revised date. 1.4 Line Activity Codes

This section will relate mainly to intermodal ports and will be dealt with by CISC BPWG.

Industry Ordering Guidelines

The purpose of this section is to highlight some of the key rules and practices that have been accepted and endorsed by the Canadian Industry to facilitate the exchange of information for porting activity. For example: Each port request must include. The preferred sequence of manually transmitting port request forms is as follows:

The order activities associated with a port request must share the same unique attributes: (to be discussed) o Same contact name o Same due date o Same purchase order number Porting of Suspended and Disconnected Telephone Numbers

2.1

This section provides the industry rules for determining whether a suspended or disconnected telephone number is portable between service providers. 2.1.1 Customer initiated Suspension and Disconnection

When a customer suspends wireless/local service, the current service provider must process a request to port a suspended number.

CWTA

94

Issued 2/7/2013

When a customer disconnects service, the current service provider may reject a request to port the disconnected number, and may make the disconnected number available for re-assignment in accordance with COCA rules for Aging and Administration of Disconnected Telephone Numbers. Alternatively, the OSP may decide to restore service and agree to port the number to maintain a positive relationship with the customer. 2.1.2 Company-initiated Suspension and Disconnection

When a service provider suspends or disconnects service in accordance with either Terms of Service or company policy per Telecom CRTC 97-8, the suspended or disconnected telephone number no longer has the status of a working telephone number. The suspended or disconnected number regains its working status when the reasons for suspension or disconnection have been resolved. Exceptions to this general rule apply in situations where service has been suspended due to suspected fraud. In these situations, the number should regain its eligibility to port at the customers request. The working status of a telephone number at the time the current service provider receives a request determines whether or not the number is portable: If the telephone number is working at the time that the current service provider receives a request to port to a NSP, the OSP must port the number as requested. The OSP may suspend or disconnect a customers telephone number in accordance with Terms of Service or company policy (subject to CRTC Decision 97-8) until the confirmed time of the request. The telephone number must, however, be ported as requested. If the telephone number is not working at the time the OSP receives the request to port the number to the NSP, the OSP may reject the port request. The reason for the company-initiated suspension or disconnection of a customers service is confidential information and must not be disclosed to another service provider without the customers consent. 2.2 2.2.1 Hours of Operations Carriers

Each carrier will determine its own hours of operations. Given that differences among carriers are likely to exist, the following guidelines were developed. Timers will accommodate the carrier with the least hours of operations in a given area. For example, if carrier A has porting availability, including fall-out resolution from 9:00am to 9:00pm and carrier B has the equivalent availability from 9:30am to 9:30pm, then the timers will run during the hours of 9:30am to 9:00pm.

CWTA

95

Issued 2/7/2013

Porting requests initiated less than 30 minutes prior to the end of day (9:00pm in the example above) will not start the timers until the beginning of hours of operations of the next business day. NPAC/Neustar Hours of operations will support the carriers hours of operations across Canada. These hours of operations will be from TBD Fall Out

2.2.2

The purpose of this section is to: Describe the processes to be used when dealing with fall-out Describe the guidelines that carriers will adhere to when dealing with fall-out Describe the escalation procedures to be followed in escalation situations

CWTA

96

Issued 2/7/2013

Vous aimerez peut-être aussi