cwnpg_v1_7_august_15_2006.doc

Canadian

Wireless Number Portability

Guidelines

Version 1.67Issued June 14August 15, 2006

Table of Contents

1 Introduction..................................................................................................................32 Background..................................................................................................................33 End User Authorization...............................................................................................54 Passwords on End User Accounts...............................................................................65 Port Protection.............................................................................................................7

5.1 Guidelines for Use:..............................................................................................75.2 Monitoring:..........................................................................................................75.3 Dispute Resolution:.............................................................................................85.4 Process for addressing fallout caused by port protection:...................................8

6 Inadvertent Port Process..............................................................................................86.1 Preventing Inadvertent Ports................................................................................86.2 Inadvertent Port Resolution.................................................................................9

7 Customer Porting Request Disputes..........................................................................108 Carrier Dispute Resolution Process...........................................................................109 Porting Intervals.........................................................................................................10

9.1 Cancellation Deadline for Porting Requests......................................................119.2 Activation of Number Porting...........................................................................119.3 Line Activity Codes...........................................................................................119.4 Porting of Suspended and Disconnected Telephone Numbers..........................119.5 Hours of Operations...........................................................................................12

10 Snap Back Process.................................................................................................1311 Fall Out..................................................................................................................1312 Intercarrier Communication Processes and Scenarios...........................................13

12.1 Impacts and Responsibilities.............................................................................1312.2 Wireless to Wireless Porting Process................................................................1512.3 Data Elements....................................................................................................2212.4 Data Edits, Formatting and Transmission.........................................................5212.5 Clearinghouse....................................................................................................5312.6 Industry Established Response Timelines.........................................................5412.7 Version Control.................................................................................................5612.8 Backward Compatibility....................................................................................57

13 Data Dictionary......................................................................................................5714 Glossary of Terms..................................................................................................83

CWTA 2 Issued 4/8/2023

1 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.

2 Background

On March 18, 2005, Industry Canada Minister David Emerson requested the Canadian Radio-television 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.


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 inter-modal 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.


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 carrier’s Operational Support Systems (OSS).

Communication Protocols

Adopt standard protocols for communication between carriers

Effective and efficient communication methodology including Web Access

Encryption

3 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 Carrier’s Privacy Policy.

Customer/Business Name______________________________________

Billing Address _______________________________________

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.

4 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.


mackc2, 08/10/06,

We will need to identify password requirements for complex ports.

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.

5 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)

o Carriers may review existing contractual agreements with clients and pro-actively offer Port Protection in cases where the client has limited the authority or rights to the phone number.

o 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.


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

5.3 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.)

5.4 Process for addressing fallout caused by port protection:1 NSP submits a WPR to OSP2 OSP responds with a WPRR – 6P resolution code. OSP may provide a follow up

number for client to call in the remarks field3 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 pProtection4 Client calls OSP and after confirming that Port Protection has been removed, calls

NSP to notify them that Port Protection has been removed5 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

6 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 provider’s 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 customer’s TN is provisioned properly within the current service provider’s 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 provider’s OSS NPAC query indicates the customer’s telephone number (TN) is active with

another service provider

If the service provider’s 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 PortsAn 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.


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 SV’s “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 NSP’s 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


http://www.npac.com/

7 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

??

9 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 inter-modal porting activity.

1 to 5 lines for GUI users

1 to 25 lines for API users


mackc2, 06/14/06,

Do we need to develop this form or provide and example?

mackc2, 06/14/06,

We need to determine how this will happen and how the costs will be decided

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:

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.

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

9.4 Porting of Suspended and Disconnected Telephone NumbersThis section provides the industry guidelines for determining whether a suspended or disconnected telephone number is portable between service providers.

9.4.1 Customer initiated Suspension and DisconnectionWhen 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 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.

9.4.2 Company-initiated Suspension and DisconnectionWhen 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 it’s eligibility to port at the customer’s 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 customer’s 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 customer’s service is confidential information and must not be disclosed to another service provider without the customer’s consent.

9.5 Hours of OperationsThe 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.

9.5.1 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) OSS Interface will be based on OSS availability(ii) GUI Interface will be based on Porting Centre Hours of Operation(iii) Wireline will be based on their existing hours of operation.

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.


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 MVNO’s 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


12.1 Impacts and ResponsibilitiesThe 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 ProviderThe 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 subscriber’s Mobile Directory Number (MDN) has been opened for porting

Validate the subscriber’s MDN can be ported into the NSP’s 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 ProviderThe OSP 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 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 NSP’s 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 ProcessThe 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)

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 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.

Figure 1 - Wireless to Wireless Port


12.2.1 Detail Description of Process Boxes

BOX # Name DescriptionStart The start point in the process flow

1 Obtain subscriber data & authorization

The process of obtaining the subscriber information and the authorization to port the numbers.

2 Enter required data The subscriber information is entered into the NSP’s system and sent to the NICP, or manually entered directly into the NICP.

3 Edit & format request

The NICP edits the input and formats the request into the proper record format.

4 Store & transmit request

The NICP stores the request and then transmits it to the OICP according to the routing information.

5 Request rcvd, edited & stored

The request is received by the OICP, edited for validity and stored within the OICP. It is forwarded to the OSP’s internal system either directly or manually.

5A Validate request Each porting telephone number within the request is validated by the OSP. This can be a manual or automated procedure.

6 Can validate within 30 minutes or delayed time?

The OSP will determine if it can complete the validation process within the 30 minutes or the delayed time previously set by the OSP.

7 Data valid for each number?

This box represents decisions based on the validity of each ported line number within the request.

7A Complete “Confirm” response

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.

7B Complete “Resolution Required” response with reasons and remarks

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.

7C Complete “Delay” response with reasons and remarks

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.

8 Edit & format response

The OICP edits the response and formats the request into the proper record format.

9 Store & transmit response

The OICP stores the response and then transmits it to the NICP according to the routing information

10 Response rcvd, edited, and stored

The NICP receives, acknowledges the receipt back to the OICP, edits and stores the Response.

10A Response type equals “D”?

If the response type is anything other than “delay”, end the timer.

11 Rcvd transmit This box represents a decision based on whether or not the


BOX # Name DescriptionNICP sent a confirmation for the receipt of the transaction sent by the OICP.

11A OSP resolution 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.

11B Is Recd transmit confirm (RTC) for a “confirm” response?

Is this acknowledgement for a “confirm” response?

11C Continue porting process

The OSP continues with the porting process.

12 Response type equals C?

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.

12A Check reason code & remarks

If no, to “Response = C” (Box 12), the NSP will check for the reason code and remarks to determine why request wasn’t confirmed.

12B Continue porting process

If yes to “Response = C” (Box 12) then the NSP will continue with the porting process.

13 Reset Timer If yes to Response Type of “D”, then the timers are reset to reflect the delay time submitted by the OSP.

13A NSP receives “Delay” response

This box represents that the NSP was notified of a “Delay” response.

13B Resolve If no to Box 12, then continue with a resolution process14 Rcvd trans.

Acknowledged?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.

14A NSP resolution 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.

14B Begin time tracking If yes to “Received transmit Acknowledged?” (Box 14), then the NICP initiates the time tracking mechanism that tracks the elapsed time during the ICP.

15 Timer expired? The box represents the on-going time tracking that occurs during the process.

15A No action required 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.

15B Alarm received If the timer does expire (Box 15) before the completion of the process then an alarm is sent by the NICP to the NSP.

16 Contact OSP & resolve

The NSP initiates process to contact the OSP to determine why the Response has not been received within the proper time frame.

17 End timer This box represents the portion of the time tracking mechanism whereby the timer is ended when the NICP receives a Response from the OSP.

18 Customer wants to continue?

This box represents the NSP proprietary process initiated with the customer when a Resolution Required Response Type for a


BOX # Name Descriptionporting 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.

END Represents the end of the ICP.

12.2.2 Narrative for Process FlowThe 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 OSP’s 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).

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 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 1 to 5 lines for GUI users o 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 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 NSP’s 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 Description Type Length Use Data Source

CWNPGWICIS_REL_NO

WICIS Release Number N[+] 6 M SYSTEM

NLSP New Local Service Provider AN 4 M NSP

ONSP Old Network Service Provider AN 4 M NSP

REQ_NO Request Number AN 16 M SYSTEMVER ID REQ Version Identification for the

RequestN 2 M SYSTEM

SUP Supplement Type N[+] 1 C NSPNPDI Number Portability Direction

IndicatorA 1 M NSP

RESP_NO Response Number AN 18 MNNSP New Network Service Provider AN 4 M NSPD/TSENT Date and Time Sent N 12 M SYSTEMDDD/T Desired Due Date and Time N 12 M NSPCHC Coordinated Hot Cut A 1 O NSPAGAUTH Agency Authorization Status A 1 M NSPDATED Date of Agency Authorization N 8 C NSPAUTHNM Authorization Name L8A 60 C NSPGREQ_NO Group Request Number AN[+] 16 O NSPINIT Initiator Identification L8A 15 M NSP or

SYSTEMIMPCON Implementation Contact L8A 15 M NSPTEL NO

(IMPCON) Telephone Number for Implementation Contact

N[+] 17 M NSP

BILLPREFIX Billing Name Prefix L8A 10 O NSP



BILLFIRSTNM Billing First Name L8A 25 C NSPBILLMDINIT Billing Middle Initial L8A 1 O NSPBILLLASTNM Billing Last Name L8A 25 C NSPBILLSUFFIX Billing Name Suffix L8A 10 O NSPBUSNM Business Name L8A 60 C NSPBILLSTNUM Billing Street Number L7A[-] 10 C NSPBILLSTNM Billing Street Name L8A 60 M NSPBILLSTDIR Billing Street Directional A 2 O NSPCITY City L8A 35 M NSPSTATE State/Province A[+] 2 C NSPPOSTAL CD Postal Code AN[+] 10 O NSPCOUNTRY Country L8A 3 C NSPACCT Account Number AN 20 C NSPPSWD/PIN Password/PIN L8A 15 C NSPESN/MEID Equipment Identifier N 17 C NSPNPQTY Number Portability Quantity N 5 M NSPLNUM Line Number (repeats) N 5 M SYSTEMPORTED # Porting Telephone Number

(repeats)N[+] 17 M NSP

NAME Name (repeats) L8A 60 O NSPREMARKS Remarks L8A 160 O NSPNRSELLNM New Reseller Name L8A 20 C 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.

Field Description Type Length Use Data SourceCWNPGWICIS_REL_ NO

WICIS Release Number N[+] 6 M OICP

NNSP New Network Service Provider AN 4 M OICP

OLSP Old Local Service Provider AN 4 M OSP

ONSP Old Network Service Provider AN 4 M OICP


Field Description Type Length Use Data SourceREQ_NO Request Number AN 16 M OICPVER ID REQ Version Identification for the

RequestN 2 M OICP

VER ID RESP Version Identification for the Response

N 2 O OICP

RT Response Type A 1 M OSPGRESP_NO Group Response Number AN[+] 20 O OSPRESP_NO Response Number AN 18 M SYSTEMCD/TSENT Confirmation Date and Time

Sent N 12 M SYSTEM

REP Representative L8A 15 M OSPTEL NO (REP) Telephone Number for OSP’s

representativeN[+] 17 M OSP

CHC Coordinated Hot Cut A 1 C OSPDD/T Due Date and Time N 12 M OSP or

SYSTEMNPQTY Number Portability Quantity N 5 C OICPLNUM Line Number corresponds to

LNUM on the original Request from NSP (repeats)

N 5 C OICP

PORTED # Porting Telephone Number (repeats)

N[+] 17 C OICP

RCODE Reason Code (repeats) AN[+] 2 C OSPRDET Reason Code Detail (repeats) L8A 60 C OSPREMARKS Remarks L8A 160 C OSPORSELLNM Old Reseller Name L8A 20 C OSPDCODE Delay Code AN[+] 2 C 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 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)


CWNPGWICIS_REL_NO



NNSP New Network Service Provider AN 4 M NSP



RequestN 2 M SYSTEM



SUP Supplement Type N[+] 1 M NSPRESP_NO Response Number AN 18 M SYSTEMD/TSENT Date and Time Sent N 12 M SYSTEMREMARKS Remarks L8A 160 O NSPNRSELLNM New Reseller Name L8A 20 C NSP

SUPPLEMENTAL TYPE 2 (CHANGE DUE DATE ON PORT REQUEST)


CWNPGWICIS_REL_NO



NNSP New Network Service Provider AN 4 M NSP



RequestN 2 M SYSTEM

SUP Supplement Type N[+] 1 M NSPRESP_NO Response Number AN 18 M SYSTEMD/TSENT Date and Time Sent N 12 M SYSTEMDDD/T Desired Due Date and Time N 12 M NSPCHC Coordinated Hot Cut A 1 O NSPREMARKS Remarks L8A 160 O NSPNRSELLNM New Reseller Name L8A 20 C NSP

SUPPLEMENTAL TYPE 3 (MODIFY ANY DATA ON PORT REQUEST)


CWNPGWICIS_REL_NO





RequestN 2 M SYSTEM

SUP Supplement Type N[+] 1 M NSPNPDI Number Portability Direction

IndicatorA 1 M NSP

RESP_NO Response Number AN 18 M OSPNNSP New Network Service Provider AN 4 M NSP



D/TSENT Date and Time Sent N 12 M SYSTEMDDD/T Desired Due Date and Time N 12 M NSPCHC Coordinated Hot Cut A 1 O NSPAGAUTH Agency Authorization Status A 1 M NSPDATED Date of Agency Authorization N 8 C NSPAUTHNM Authorization Name L8A 60 C NSPGREQ_NO Group Request Number AN[+] 16 O NSPINIT Initiator Identification (creator) L8A 15 M NSP or

SYSTEMIMPCON Implementation Contact L8A 15 M NSPTEL NO


N[+] 17 M NSP

BILLPREFIX Billing Name Prefix L8A 10 O NSPBILLFIRSTNM Billing First Name L8A 25 C NSPBILLMDINIT Billing Middle Initial L8A 1 O NSPBILLLASTNM Billing Last Name L8A] 25 C NSPBILLSUFFIX Billing Name Suffix L8A 10 O NSPBUSNM Business Name L8A 60 C NSPBILLSTNUM Billing Street Number L7A[-] 10 C NSPBILLSTNM Billing Street Name L8A 60 M NSPBILLSTDIR Billing Street Directional A 2 O NSPCITY City L8A 35 M NSPSTATE State/Province A[+] 2 C NSPZIP CODE Zip Code AN[+] 10 O NSPCOUNTRY Country L8A 3 C NSPACCT Account Number AN 20 C NSPPSWD/PIN Password/PIN L8A 15 C NSPESN/MEID Equipment Identifier N 17 C NSPNPQTY Number Portability Quantity N 5 M NSPLNUM Line Number (repeats) N 5 M SYSTEMPORTED # Porting Telephone Number

(repeats)N[+] 17 M NSP

NAME Name (repeats) L8A 60 O NSPREMARKS Remarks L8A 160 M NSPNRSELLNM New Reseller Name L8A 20 C NSP

Valid Delay codes are as follows:

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 Description Type Length Use Sample Value

CWNPGWICIS_REL_NO

WICIS Release Number N[+] 6 M 3.0.0

NLSP New Local Service Provider AN 4 M 1234

ONSP Old Network Service Provider AN 4 M 5678

REQ_NO Request Number AN 16 M 1234004323000001

VER ID REQ Version Identification for the Request

N 2 M 01

SUP Supplement Type N[+] 1 CNPDI Number Portability Direction

IndicatorA 1 M A

RESP_NO Response Number AN 18 M 1234006365000000A1

NNSP New Network Service Provider AN 4 M 1234D/TSENT Date and Time Sent N 12 M 110520001150DDD/T Desired Due Date and Time N 12 M 110520001450CHC Coordinated Hot Cut A 1 O AGAUTH Agency Authorization Status A 1 M YDATED Date of Agency Authorization N 8 C 11052000AUTHNM Authorization Name L8A 60 C Don J WallaceGREQ_NO Group Request Number AN[+] 16 OINIT Initiator Identification (creator) L8A 15 M TerryIMPCON Implementation Contact L8A 15 M LoriTEL NO (IMPCON)

Telephone Number N[+] 17 M 409-555777-9876

BILLPREFIX Billing Name Prefix L8A 10 O ProfessorBILLFIRSTNM Billing First Name L8A 25 C DonBILLMDINIT Billing Middle Initial L8A 1 O JBILLLASTNM Billing Last Name L8A 25 C WallaceBILLSUFFIX Billing Name Suffix L8A 10 O JrBUSNM Business Name L8A 60 CBILLSTNUM Billing Street Number L7A[-] 10 C 5301



BILLSTNM Billing Street Name L8A 60 M Morning CreekBILLSTDIR Billing Street Directional A 2 O NW

CITY City L8A 35 M TorontoSTATE State/Province A[+] 2 C ONZIP CODE Zip Code AN[+] 10 O K1P5G4 COUNTRY Country L8A 3 C CANACCT Account Number AN 20 CPSWD/PIN Password/Pin Number L8A 15 CESN/MEID Equipment Identifier N 17 C 1234567890123

4567NPQTY Number Portability Quantity N 5 M 00001LNUM Line Number N 5 M 00001PORTED # Porting Telephone Number N[+] 17 M 409-555696-

1234NAME Name L8A 60 O Don WallaceREMARKS Remarks L8A 160 OC RUSHNRSELLNM New Reseller Name L8A 20 C

Sample WPRR confirmation response for a single port.

Field Description Type Length Use Sample ValueCWNPGWICIS_REL_NO


NNSP New Network Service Provider AN 4 M 1234

OLSP Old Local Service Provider AN 4 M 5678

ONSP Old Network Service Provider AN 4 M 5678REQ_NO Request Number AN 16 M 1234004323000

001VER ID REQ Version Identification for the

RequestN 2 M 01


N 2 O

RT Response Type A 1 M CGRESP_NO Group Response Number AN[+] 20 ORESP_NO Response Number AN 18 M 5678104323000

00001CD/TSENT Confirmation Date and Time

Sent N 12 M 110520001145

REP Representative L8A 15 M J. RepresentTEL NO (REP) Telephone Number for OSP’s

representativeN[+] 17 M 409-555777-

1234CHC Coordinated Hot Cut A 1 CDD/T Due Date and Time N 12 M 110520001400


Field Description Type Length Use Sample ValueNPQTY Number Portability Quantity N 5 C 00001LNUM Line Number corresponds to

LNUM on original Request from NSP

N 5 C 00001

PORTED # Porting Telephone Number N[+] 17 C 409-555696-1234

RCODE Reason Code AN[+] 2 C RDET Reason Code Detail L8A 60 C REMARKS Remarks L8A 160 COORSELLNM Old Reseller Name L8A 20 C

Sample of a Resolution Required WPRR for a Single Port.







RequestN 2 M 01


N 2 O

RT Response Type A 1 M RGRESP_NO Group Response Number AN[+] 20 ORESP_NO Response Number AN 18 M 5678104323000


Sent N 12 M 110520001145


representative N[+] 17 M 409-555777-

1234CHC Coordinated Hot Cut A 1 CDD/T Due Date and Time N 12 M 110520001400NPQTY Number Portability Quantity N 5 C 00001LNUM Line Number corresponds to


N 5 C 00001


RCODE Reason Code AN[+] 2 C 6A RDET Reason Code Detail L8A 60 C Customer Name


Field Description Type Length Use Sample Valuedoes not match telephone number

REMARKS Remarks L8A 160 OORSELLNM Old Reseller Name L8A 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.







RequestN 2 M 01


N 2 O

RT Response Type A 1 M DGRESP_NO Group Response Number AN[+] 20 ORESP_NO Response Number AN 18 M 5678104323000


Sent N 12 M 110520001145



1234CHC Coordinated Hot Cut A 1 CDD/T Due Date and Time N 12 M 110520001500REMARKS Remarks L8A 160 OORSELLNM Old Reseller Name L8A 20 CDCODE Delay Code AN[+] 2 C 6H

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.


CWNPGWICIS_REL_NO






N 2 M 01


IndicatorA 1 M A

RESP_NO Response Number AN 18 MNNSP New Network Service Provider AN 4 M 1234D/TSENT Date and Time Sent N 12 M 110520001150DDD/T Desired Due Date and Time N 12 M 110620001400CHC Coordinated Hot Cut A 1 O AGAUTH Agency Authorization Status A 1 M YDATED Date of Agency Authorization N 8 C 11052000AUTHNM Authorization Name L8A 60 C Bruce WillisGREQ_NO Group Request Number AN[+] 16 OINIT Initiator Identification (creator) L8A 15 M Terry BradshawIMPCON Implementation Contact L8A 15 M Mike ColemanTEL NO (IMPCON)

Telephone Number for Implementation contact

N[+] 17 M 409-555777-9876-333

BILLPREFIX Billing Name Prefix L8A 10 O ReverendBILLFIRSTNM Billing First Name L8A 25 C BruceBILLMDINIT Billing Middle Initial L8A 1 O JBILLLASTNM Billing Last Name L8A 25 C WillisBILLSUFFIX Billing Name Suffix L8A 10 O SrBUSNM Business Name L8A 60 CBILLSTNUM Billing Street Number L7A[-] 10 CBILLSTNM Billing Street Name L8A 60 M P.O. Box 1234BILLSTDIR Billing Street Directional A 2 O WCITY City L8A 35 M Toronto



STATE State/Province A[+] 2 C ONZIP CODE Zip Code AN[+] 10 O K1P5G4 COUNTRY Country L8A 3 C CANACCT Account Number AN 20 CPSWD/PIN Password/Pin Number L8A 15 CESN/MEID Equipment Identifier N 17 CNPQTY Number Portability Quantity N 5 M 00003LNUM Line Number N 5 M 00001PORTED # Porting Telephone Number N[+] 17 M 409-777696-1234NAME Name L8A 60 O J. CustomerLNUM Line Number N 5 M 00002PORTED # Porting Telephone Number N[+] 17 M 409-777696-

1235NAME Name L8A 60 O J. CustomerLNUM Line Number N 5 M 00003PORTED # Porting Telephone Number N[+] 17 M 409-555696-

1236NAME Name L8A 60 O J. CustomerREMARKS Remarks L8A 160 OC RUSHNRSELLNM New Reseller Name L8A 20 C

The following is a sample WPRR confirmation for a multi-line port. Note that LNUM, PORTED#, RCODE and RDET repeat.

Field Description Type Length Use Sample ValueCWNPGWICIS

_REL_NOWICIS Release Number N[+] 6 M 3.0.0





RequestN 2 M 01


N 2 O 01

RT Response Type A 1 M CGRESP_NO Group Response Number AN[+] 20 O 45678RESP_NO Response Number AN 18 M 5678104323000


Sent N 12 M 110520001145

REP Representative L8A 15 M J. Represent


Field Description Type Length Use Sample ValueTEL NO (REP) Telephone Number N[+] 17 M 409-555777-

9876CHC Coordinated Hot Cut A 1 ODD/T Due Date and Time N 12 M 110620001400NPQTY Number Portability Quantity N 5 C 00003LNUM Line Number corresponds to


N 5 C 00001


RCODE Reason Code AN[+] 2 CRDET Reason Code Detail L8A 60 CLNUM Line Number corresponds to


N 5 C 00002




N 5 C 00003


RCODE Reason Code AN[+] 2 CRDET Reason Code Detail L8A 60 CREMARKS Remarks L8A 160 COORSELLNM Old Reseller Name L8A [-] 20 C

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.







RequestN 2 M 01


Field Description Type Length Use Sample ValueVER ID RESP Version Identification for the

ResponseN 2 O 01

RT Response Type A 1 M RGRESP_NO Group Response Number AN[+] 20 O 45678RESP_NO Response Number AN 18 M 5678104323000


Sent N 12 M 110520001145

REP Representative L8A 15 M J. RepresentTEL NO (REP) Telephone Number N[+] 17 M 409-555777-



N 5 C 00001

PORTED # Porting Telephone Number N[+] 17 C 409-555696-1234RCODE Reason Code AN[+] 2 C 6ARDET Reason Code Detail L8A 60 C Customer name

doesn’t match LNUM Line Number corresponds to


N 5 C 00002


RCODE Reason Code AN[+] 2 C 7ARDET Reason Code Detail L8A 60 C

LNUM Line Number corresponds to LNUM on original Request from NSP

N 5 C 00003

PORTED # Porting Telephone Number N[+] 17 C 409-696-1236RCODE Reason Code AN[+] 2 C 7ARDET Reason Code Detail L8A 60 CREMARKS Remarks L8A 160 COORSELLNM Old Reseller Name L8A 20 C

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.


The following is a sample WPR for a Multi-line Port.


CWNPGWICIS_REL_NO






N 2 M 01


IndicatorA 1 M A

RESP_NO Response Number AN 18 MNNSP New Network Service Provider AN 4 M 1234D/TSENT Date and Time Sent N 12 M 110520001150DDD/T Desired Due Date and Time N 12 M 110620001400CHC Coordinated Hot Cut A 1 O AGAUTH Agency Authorization Status A 1 M YDATED Date of Agency Authorization N 8 C 11052000AUTHNM Authorization Name L8A 60 C Bruce WillisGREQ_NO Group Request Number AN[+] 16 OINIT Initiator Identification (creator) L8A 15 M Terry BradshawIMPCON Implementation Contact L8A 15 M Mike ColemanTEL NO (IMPCON)


N[+] 17 M 409-555777-9876-333

BILLPREFIX Billing Name Prefix L8A 10 O ReverendBILLFIRSTNM Billing First Name L8A 25 C BruceBILLMDINIT Billing Middle Initial L8A 1 O CBILLLASTNM Billing Last Name L8A 25 C WillisBILLSUFFIX Billing Name Suffix L8A 10 O M.D.BUSNM Business Name L8A 60 CBILLSTNUM Billing Street Number L7A[-] 10 CBILLSTNM Billing Street Name L8A 60 M P.O. Box 1234BILLSTDIR Billing Street Directional A 2 O NECITY City L8A 35 M TorontoSTATE State/Province A[+] 2 C ONZIP CODE Zip Code AN[+] 10 O K1P5G4 COUNTRY Country L8A 3 C CANACCT Account Number AN 20 CPSWD/PIN Password/Pin Number L8A 15 CESN/MEID Equipment Identifier N 17 C



NPQTY Number Portability Quantity N 5 M 00003LNUM Line Number N 5 M 00001PORTED # Porting Telephone Number N[+] 17 M 409-555696-

1234NAME Name L8A 60 O J. CustomerLNUM Line Number N 5 M 00002PORTED # Porting Telephone Number N[+] 17 M 409-555-696-

1235NAME Name L8A 60 O J. CustomerLNUM Line Number N 5 M 00003PORTED # Porting Telephone Number N[+] 17 M 409-696-1236NAME Name L8A 60 O J. CustomerREMARKS Remarks L8A 160 OC RUSHNRSELLNM New Reseller Name L8A 20 C

The following is a sample Confirmation WPRR for a Multi-line Port.




OLSP Old Local Service Provider AN 4 M 5678ONSP Old Network Service Provider AN 4 M 5678REQ_NO Request Number AN 16 M 123400432300


RequestN 2 M 01


N 2 O 01



Sent N 12 M 110520001145



LNUM on original Request N 5 C 00001


Field Description Type Length Use Sample Valuefrom NSP




N 5 C 00002




N 5 C 00003


RCODE Reason Code AN[+] 2 CRDET Reason Code Detail L8A 60 CREMARKS Remarks L8A 160 COORSELLNM Old Reseller Name L8A-] 20 C

Sample record for an SPR (TYPE 2) to change the due date and/or time.


CWNPGWICIS_REL_NO







N 2 M 02

SUP Supplement Type N[+] 1 M 2RESP_NO Response Number AN 18 M 56781043230

0000002D/TSENT Date and Time Sent N 12 M 11052000125

0DDD/T Desired Due Date and Time N 12 M 11062000110

0CHC Coordinated Hot Cut A 1 O REMARKS Remarks L8A 160 OC RUSH



NRSELLNM New Reseller Name L8A 20 C

Sample Confirmation WPRR for an SPR (TYPE 2).







RequestN 2 M 02


N 2 O 01



Sent N 12 M 110520001300




N 5 C 00001




N 5 C 00002


RCODE Reason Code AN[+] 2 CRDET Reason Code Detail L8A 60 CLNUM Line Number corresponds to N 5 C 00003


Field Description Type Length Use Sample ValueLNUM on original Request from NSP


RCODE Reason Code AN[+] 2 CRDET Reason Code Detail L8A 60 CREMARKS Remarks L8A 160 OORSELLNM Old Reseller Name L8A 20 C

Sample record for an SPR (TYPE 3). This sample illustrates an address change.


CWNPGWICIS_REL_NO






N 2 M 02

SUP Supplement Type N[+] 1 M 3NPDI Number Portability Direction

IndicatorA 1 M A

RESP_NO Response Number AN 18 M 567810432300000002

NNSP New Network Service Provider AN 4 M 1234D/TSENT Date and Time Sent N 12 M 110620001230DDD/T Desired Due Date and Time N 12 M 110620001400CHC Coordinated Hot Cut A 1 O AGAUTH Agency Authorization Status A 1 M YDATED Date of Agency Authorization N 8 C 03052001AUTHNM Authorization Name L8A 60 C Bruce WillisGREQ_NO Group Request Number AN[+] 16 OINIT Initiator Identification (creator) L8A 15 M Terry BradshawIMPCON Implementation Contact L8A 15 M Mike ColemanTEL NO


N[+] 17 M 409-777-9876

BILLPREFIX Billing Name Prefix L8A 10 O ProfessorBILLFIRSTNM Billing First Name L8A 25 C BruceBILLMDINIT Billing Middle Initial L8A 1 O DBILLLASTNM Billing Last Name L8A 25 C WillisBILLSUFFIX Billing Name Suffix L8A 10 O JrBUSNM Business Name L8A 60 C



BILLSTNUM Billing Street Number L7A[-] 10 C 5301BILLSTNM Billing Street Name L8A 60 M Morning Creek

CrBILLSTDIR Billing Street Directional A 2 OCITY City L8A 35 M TorontoSTATE Province

A[+] 2 C ON

ZIP CODE Zip Code AN[+] 10 O K1P5G4 COUNTRY Country L8A 3 CACCT Account Number AN 20 CPSWD/PIN Password/PIN L8A 15 CESN/MEID Equipment Identifier N 17 C

NPQTY Number Portability Quantity N 5 M 00003LNUM Line Number N 5 M 00001PORTED # Porting Telephone Number N[+] 17 M 409-555696-

1234NAME Name L8A 60 O Don WallaceLNUM Line Number corresponds to


N 5 M 00002

PORTED # Porting Telephone Number N[+] 17 M 409-555696-1235

NAME Name L8A 60 O J. CustomerLNUM Line Number corresponds to


N 5 M 00003


NAME Name L8A 60 O Tom CustomerREMARKS Remarks L8A 160 M Changed billing

addressNRSELLNM New Reseller Name L8A 20 C



WICIS Release N[+] 6 M 3.0.0





Field Description Type Length Use Sample Value0002


N 2 M 02


N 2 O 02



Sent N 12 M 110520001240





N 5 C 00001


RCODE Reason Code AN[+] 2 C RDET Reason Code Detail L8A 60 C LNUM Line Number corresponds to


N 5 C 00002




N 5 C 00003


RCODE Reason Code AN[+] 2 CRDET Reason Code Detail L8A 60 C

REMARKS Remarks L8A 160 OORSELLNM Old Reseller Name L8A 20 C

Sample Delay WPRR for an SPR (TYPE 3).








RequestN 2 M 02


N 2 O 02

RT Response Type A 1 M DGRESP_NO Group Response Number AN[+] 20 ORESP_NO Response Number AN 18 M 5678104323000


Sent N 12 M 110520001240



1234CHC Coordinated Hot Cut A 1 CDD/T Due Date and Time N 12 M 110520001550NPQTY Number Portability Quantity N 5 CLNUM Line Number corresponds to


N 5 C

PORTED # Porting Telephone Number N[+] 17 CRCODE Reason Code AN[+] 2 CRDET Reason Code Detail L8A 60 C REMARKS Remarks L8A 160 OORSELLNM Old Reseller Name L8A 20 CDCODE Delay Code AN[+] 2 C 6J

Sample record for an SPR (TYPE 3). This sample illustrates removing two TNs, and changing due date.


CWNPGWICIS_REL_NO








N 2 M 03

SUP Supplement Type N[+] 1 C 3NPDI Number Portability Direction

IndicatorA 1 M A


NNSP New Network Service Provider AN 4 M 5678D/TSENT Date and Time Sent N 12 M 110520001800DDD/T Desired Due Date and Time N 12 M 110720001200CHC Coordinated Hot Cut A 1 O AGAUTH Agency Authorization Status A 1 M YDATED Date of Agency Authorization N 8 C 11052000AUTHNM Authorization Name L8A 60 C Bruce WillisGREQ_NO Group Request Number AN[+] 16 OINIT Initiator Identification (creator) L8A 15 M Terry BradshawIMPCON Implementation Contact L8A 15 M Mike ColemanTEL NO (IMPCON)


N[+] 17 M 409-555777-9876-333

BILLPREFIX Billing Name Prefix L8A 10 O ProfessorBILLFIRSTNM Billing First Name L8A 25 C BruceBILLMDINIT Billing Middle Initial L8A 1 O JBILLLASTNM Billing Last Name L8A 25 C WillisBILLSUFFIX Billing Name Suffix L8A 10 O SrBUSNM Business Name L8A 60 CBILLSTNUM Billing Street Number L7A[-] 10 C 5301BILLSTNM Billing Street Name L8A 60 M Morning Creek

CrBILLSTDIR Billing Street Directional A 2 O ECITY City L8A 35 M TorontoSTATE State/Province A[+] 2 C ONZIP CODE Zip Code AN[+] 10 O K1P5G4 COUNTRY Country L8A 3 C CANACCT Account Number AN 20 CPSWD/PIN Password/Pin Number L8A 15 CESN/MEID Equipment Identifier N 17 CNPQTY Number Portability Quantity N 5 M 00001LNUM Line Number N 5 M 00003PORTED # Porting Telephone Number N[+] 17 M 409-555696-

1236NAME Name L8A 60 O J. CustomerREMARKS Remarks L8A 160 M Removed TNs

409-555696-1234, 409-



555696-1235, and changed due date

NRSELLNM New Reseller Name L8A 20 C

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







RequestN 2 M 03


N 2 O 03



Sent N 12 M 110520001830




N 5 C 00003


RCODE Reason Code AN[+] 2 CRDET Reason Code Detail L8A 60 CREMARKS Remarks L8A 160 COORSELLNM Old Reseller Name L8A 20 C

Sample record for an SPR (TYPE 3). This sample illustrates adding a TN.



CWNPGWICIS_REL_NO






N 2 M 04

SUP Supplement Type N[+] 1 C 3NPDI Number Portability Direction

IndicatorA 1 M A


NNSP New Network Service Provider AN 4 M 5678D/TSENT Date and Time Sent N 12 M 110620001100DDD/T Desired Due Date and Time N 12 M 110720001200CHC Coordinated Hot Cut A 1 O AGAUTH Agency Authorization Status A 1 M YDATED Date of Agency Authorization N 8 C 11052000AUTHNM Authorization Name L8A 60 C Bruce WillisGREQ_NO Group Request Number AN[+] 16 OINIT Initiator Identification (creator) L8A 15 M Terry BradshawIMPCON Implementation Contact L8A 15 M Mike ColemanTEL NO (IMPCON)


N[+] 17 M 409-555777-9876-333

BILLPREFIX Billing Name Prefix L8A 10 O ProfessorBILLFIRSTNM Billing First Name L8A 25 C BruceBILLMDINIT Billing Middle Initial L8A 1 O JBILLLASTNM Billing Last Name L8A 25 C WillisBILLSUFFIX Billing Name Suffix L8A 10 O M.D.BUSNM Business Name L8A 60 CBILLSTNUM Billing Street Number L7A[-] 10 C 5301BILLSTNM Billing Street Name L8A 60 M Morning Creek

CrBILLSTDIR Billing Street Directional A 2 O SCITY City L8A 35 M TorontoSTATE State/Province A[+] 2 C ONZIP CODE Zip Code AN[+] 10 O K1P5G4 COUNTRY Country L8A 3 C CANACCT Account Number AN 20 CPSWD/PIN Password/Pin Number L8A 15 CESN/MEID Equipment Identifier N 17 C

NPQTY Number Portability Quantity N 5 M 00002



LNUM Line Number N 5 M 00003PORTED # Porting Telephone Number N[+] 17 M 409-555696-

1236NAME Name L8A 60 O J. CustomerLNUM Line Number N 5 M 00004PORTED # Porting Telephone Number N[+] 17 M 409-555696-

1240NAME Name L8A 60 O J. CustomerREMARKS Remarks L8A 160 M Added TN 409-

555696-1240NRSELLNM New Reseller Name L8A 20 C

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







RequestN 2 M 04


N 2 O 04

RT Response Type A 1 M RGRESP_NO Group Response Number AN[+] 20 O 89598398RESP_NO Response Number AN 18 M 5678104323000


Sent N 12 M 110620001120




N 5 C 00003



Field Description Type Length Use Sample ValueRCODE Reason Code AN[+] 2 C 7ARDET Reason Code Detail L8A 60 CLNUM Line Number corresponds to


N 5 C 00004


RCODE Reason Code AN[+] 2 C 6DRDET Reason Code Detail L8A 60 MC Customer

doesn’t have service on 409-555696-1240

REMARKS Remarks L8A 160 M No service for 404-555696-1240

ORSELLNM Old Reseller Name L8A 20 C

Sample record for a SPR (TYPE 1). This sample illustrates canceling a port request.


CWNPGWICIS_REL_NO







N 2 M 05

SUP Supplement Type N[+] 1 M 1RESP_NO Response Number AN 18 M 567810432300

000002D/TSENT Date and Time Sent N 12 M 110620001600REMARKS Remarks L8A 160 OCNRSELLNM New Reseller Name L8A 20 C





Field Description Type Length Use Sample ValueNNSP New Network Service Provider AN 4 M 1234




RequestN 2 M 05


N 2 O 05



Sent N 12 M 110620001608


representativeN[+] 17 M 409-555-777-



N 5 C 00001


RCODE Reason Code AN[+] 2 C RDET Reason Code Detail L8A 60 C REMARKS Remarks L8A 160 OORSELLNM Old Reseller Name L8A 20 C

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.



CWNPGWICIS_REL_NO






N 2 M 01


IndicatorA 1 M A

RESP_NO Response Number AN 18 MNNSP New Network Service Provider AN 4 M 1234D/TSENT Date and Time Sent N 12 M 110520001150DDD/T Desired Due Date and Time N 12 M 110520001450CHC Coordinated Hot Cut A 1 OAGAUTH Agency Authorization Status A 1 M YDATED Date of Agency Authorization N 8 C 11052000AUTHNM Authorization Name L8A 60 C Don WallaceGREQ_NO Group Request Number AN[+] 16 OINIT Initiator Identification (creator) L8A 15 M TerryIMPCON Implementation Contact L8A 15 M LoriTEL NO (IMPCON)

Telephone Number N[+] 17 M 409-555777-9876

BILLPREFIX Billing Name Prefix L8A 10 O ReverendBILLFIRSTNM Billing First Name L8A 25 C DonBILLMDINIT Billing Middle Initial L8A 1 O DBILLLASTNM Billing Last Name L8A 25 C WallaceBILLSUFFIX Billing Name Suffix L8A 10 O SrBUSNM Business Name L8A 60 CBILLSTNUM Billing Street Number L7A[-] 10 C 5301BILLSTNM Billing Street Name L8A 60 M Morning CreekBILLSTDIR Billing Street Directional A 2 O NE

CITY City L8A 35 M TorontoSTATE State/Province A[+] 2 C ONZIP CODE Zip Code AN[+] 10 O K1P5G4 COUNTRY Country L8A 3 CACCT Account Number AN 20 CPSWD/PIN Password/Pin Number L8A 15 CESN/MEID Equipment Identifier N 17 C 1234567890123

4567NPQTY Number Portability Quantity N 5 M 00001



LNUM Line Number N 5 M 00001PORTED # Porting Telephone Number N[+] 17 M 409-555696-

1234NAME Name L8A 60 O Don WallaceREMARKS Remarks L8A 160 OC RUSHNRSELLNM New Reseller Name L8A 20 MC New Reseller

Inc.

Sample WPRR confirmation response for a single port involving an Old Reseller without an OCN.




OLSP Old Local Service Provider AN 4 M ZZZZONSP Old Network Service Provider AN 4 M 5678REQ_NO Request Number AN 16 M 123400432300


RequestN 2 M 01


N 2 O



Sent N 12 M 110520001145





N 5 C 00001


RCODE Reason Code AN[+] 2 C RDET Reason Code Detail L8A 60 C


Field Description Type Length Use Sample ValueREMARKS Remarks L8A 160 COORSELLNM Old Reseller Name L8A 20 MC 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. 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).


mackc2, 04/21/06,

Note that this section will have to be revised to reflect the use of one ICP if that is the way the industry goes.

A. Port Request example

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.


B. Port Response example

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 won’t 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.


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?


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.ZX range: 1-99Y range :0- 9Z range :0-9

Examples of valid release numbers are:3.0.03.0.33.5.021.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.


The following shows these rules in timeline format:

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

Version N-1

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 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 populatedProhibited - the field must not be populatedConditional - 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-7ELimited 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 definedNumeric Plus (N[+])=Hex 30-39, + additional characters from L7A set as defined Alphanumeric (AN)=Hex 30-39, 41-5A and 61-7AAlpha (A)=Hex 41-5A and 61-7AAlpha Plus (A[+])=Hex 41-5A, 61-7A, + additional characters from L7A set as definedNumeric(N)=Hex 30-39Null (Null)=Hex 00ENUM(ENUM)=List of specific values defined in the IDL structure

Decimal Octal Hex Character0 00 00 Null9 11 09 TAB

10 12 0A LF13 15 0D CR32 40 20 Space/Blank

Decimal Octal Hex Character33 41 21 !34 42 22 "35 43 23 #36 44 24 $37 45 25 %


Decimal Octal Hex Character38 46 26 &39 47 27 '40 50 28 (41 51 29 )42 52 2A *43 53 2B +44 54 2C ,45 55 2D -46 56 2E /47 57 2F .48 60 30 049 61 31 150 62 32 251 63 33 352 64 34 453 65 35 554 66 36 655 67 37 756 70 38 857 71 39 958 72 3A :59 73 3B ;60 74 3C <61 75 3D =62 76 3E >63 77 3F ?64 100 40 @65 101 41 A66 102 42 B67 103 43 C68 104 44 D69 105 45 E70 106 46 F71 107 47 G72 110 48 H73 111 49 I74 112 4A J75 113 4B K76 114 4C L77 115 4D M78 115 4E N79 117 4F O

Decimal Octal Hex Character80 120 50 P81 121 51 Q82 122 52 R83 123 53 S84 124 54 T85 125 55 U86 126 56 V87 127 57 W88 130 58 X89 131 59 Y90 132 5A Z91 133 5B [92 134 5C \93 135 5D ]94 136 5E ^95 137 5F _96 140 60 `97 141 61 a98 142 62 b99 143 63 c

100 144 64 d101 145 65 e102 146 66 f103 147 67 g104 150 68 h105 151 69 i106 152 6A j107 153 6B k108 154 6C l109 155 6D m110 156 6E n111 157 6F o112 160 70 p113 161 71 q114 162 72 r115 163 73 s116 164 74 t117 165 75 u118 166 76 v119 167 77 w120 170 78 x


Decimal Octal Hex Character121 171 79 y122 172 7A z123 173 7B {124 174 7C |125 175 7D }126 176 7E ~161 241 A1 ¡

162 242 A2 ¢

163 243 A3 £

164 244 A4 ¤

165 245 A5 ¥

166 246 A6 ¦

167 247 A7 §

168 250 A8 ¨

169 251 A9 ©

170 252 AA ª

171 253 AB «

172 254 AC ¬

173 255 AD

174 256 AE ®

175 257 AF ¯

176 260 B0 °

177 261 B1 ±

178 262 B2 ²

179 263 B3 ³

180 264 B4 ´

181 265 B5 µ

182 266 B6 ¶

183 267 B7 ·

184 270 B8 ¸

185 271 B9 ¹

186 272 BA º

187 273 BB »

188 274 BC ¼

189 275 BD ½

190 276 BE ¾

191 277 BF ¿

192 300 C0 À

193 301 C1 Á

194 302 C2 Â

195 303 C3 Ã

Decimal Octal Hex Character196 304 C4 Ä

197 305 C5 Å

198 306 C6 Æ

199 307 C7 Ç

200 310 C8 È

201 311 C9 É

202 312 CA Ê

203 313 CB Ë

204 314 CC Ì

205 315 CD Í

206 316 CE Î

207 317 CF Ï

208 320 D0 Ð

209 321 D1 Ñ

210 322 D2 Ò

211 323 D3 Ó

212 324 D4 Ô

213 325 D5 Õ

214 326 D6 Ö

215 327 D7 ×

216 330 D8 Ø

217 331 D9 Ù

218 332 DA Ú

219 333 DB Û

220 334 DC Ü

221 335 DD Ý

222 336 DE Þ

223 337 DF ß

224 340 E0 à

225 341 E1 á

226 342 E2 â

227 343 E3 ã

228 344 E4 ä

229 345 E5 å

230 346 E6 æ

231 347 E7 ç

232 350 E8 è

233 351 E9 é

234 352 EA ê

235 353 EB ë

236 354 EC ì


Decimal Octal Hex Character237 355 ED í

238 356 EE î

239 357 EF ï

240 360 F0 ð

241 361 F1 ñ

242 362 F2 ò

243 363 F3 ó

244 364 F4 ô

245 365 F5 õ

246 366 F6 ö

247 367 F7 ÷

248 370 F8 ø

249 371 F9 ù

250 372 FA ú

251 373 FB û

252 374 FC ü

253 375 FD ý

254 376 FE þ

255 377 FF ÿ

256

Element Medium Description Validation Description

ACCT I Account Number – This field indicates the customer’s account number within the OSP’s 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

Maximum 20 positionAN

AGAUTH I Agency Authorization Status – This field indicates that the NSP has the appropriate authorization from the subscriber to request the port.

Record: WPR, SUP3


Conditions: Mandatory

Valid Values:Y = Authorization on fileN = No Authorization on file

1 positionA



AUTHNM I Authorization Name – This field indicates the end user that authorized the request to port the number.

Record: WPR, SUP3


Conditions: Conditional – mandatory when AGAUTH = Y, optional when AGAUTH = N.

Values: L8A [excluding Hex values 09, 0A, 0D]Format: FirstName MiddleInitial LastName

Maximum 60 positionL8A

BILLFIRSTNM I Billing First Name – This field relates to subscriber information. This is the billing first 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


Conditions: Conditional – mandatory if BUSNM is not populated; optional if BUSNM is populated.Values: L8A [excluding Hex values 09, 0A, 0D]


BILLLASTNM 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


Conditions: Conditional– mandatory if BUSNM is not populated; optional if BUSNM is populated.

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

Maximum 25 position L8A



BILLMDINIT I Billing Name Middle Initial – This field relates to subscriber information. This is the middle initial 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


Conditions: Optional– used if billing middle initial provided.

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

Maximum 1 positionL8A, NULL

BILLPREFIX I Billing Name Prefix – This field is intended to capture the billing name prefix.

Record: WPR, SUP3


Conditions: Optional – used if billing name prefix is provided.

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

Maximum of 10 position L8A



BILLSTDIR 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


Conditions: Optional – used if billing street address direction is provided.

Values: Alpha values

Examples: E = EastW = WestN = NorthS = SouthNE = NortheastNW = NorthwestSE = SoutheastSW = Southwest

Maximum of 2 positionA

BILLSTNM I 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



Values: L8A [excluding Hex values 09, 0A, 0D]Examples:Lucerne WayRural Route 30P. O. Box 1146Peachtree Rd Suite 200Old National Hwy Room 10Milton Lane Apt 2B

Maximum of 60 positionL8A



BILLSTNUM I Billing Street Number – This field is intended to capture the street/house number of the billing address.

Record: WPR, SUP3


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]

Maximum of 10 positionL7A[-]

BILLSUFFIX I Billing Name Suffix – This field is intended to capture the billing name suffix.

Record: WPR, SUP3


Conditions: Optional – used if billing name suffix is provided. Values: L8A [excluding Hex values 09, 0A, 0D]

Examples:JrSrIII


Examples:JrSrIIIM.D.




BUSNM I Business Name – This field relates to subscriber information. This is the Business Name for the company requesting the port. This field identifies the name of the company. However, it is not intended for directory services.

Record: WPR, SUP3


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]


CD/TSENT I Confirmation Date and Time Sent – This field indicates the date and time that the OSP completed the confirmation or validation of the subscriber information.

Record: WPRR

Derivation: OSP process.

Conditions: MandatoryValues: Numeric valuesValid values: MM = 01 – 12 DD = 01 – 31 YYYY = 20x HH = 00 – 23 MM = 00 – 59 x HH = 00 – 23 MM = 00 – 59

12 positionN

MMDDYYYYHHMM



CHC I Coordinated Hot Cut – This field indicates a 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 valuesValid Values: Y, N or Not PopulatedY = Hot Cut Requested by NSP or Agreed to by OSP N = OSP Can not Coordinate Hot CutNot Populated – No Coordinated Hot Cut requested

1 positionA, ENUM

CITY I City – This field identifies the city of the subscriber’s billing address.

Record: WPR, SUP3



Values: L8A




COUNTRY I Country – This field identifies the country of the end user’s billing address.

Record: WPR, SUP3


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


D/TSENT I Date and Time Sent – This field indicates the date and time that the request was sent from the NSP. This date and time is populated within the NSP’s internal process.

Record: WPR, SUP1, SUP2, SUP3

Derivation: NSP process – prior to sending the request. This Date and Time changes with each new Version.


Values: Numeric valuesValid values: MM = 01 – 12 DD = 01 – 31 YYYY = 20xx HH = 00 – 23 MM = 00 – 59

12 position N

MMDDYYYYHHMM



DATED I Date of Agency Authorization– This field indicates the date that the port authorization was received.

Record: WPR, SUP3


Conditions: Conditional – mandatory when AGAUTH = Y, optional when AGAUTH = N

Values: Numeric values MM = 01 – 12 DD = 01 – 31 YYYY = 20xx

8 positionN

MMDDYYYY

DCODE I, Delay Code – populated only for a Delay response (i.e. when the value in the “RT” field is “D”) in a 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], NULLValid Values: 6G = Port Complexity 6H = System Outage 6J = High Volume 6L = Request received outside of business hours 8J = Reseller/MVNO unable to meet timelines.

2 positionAN[+], NULL



DD/T I Due Date and Time – On a Confirm response when NPDI = “A” or “B” for a WPR, SUP 2 or 3, the DD/T should match the NSP Desired Due Date and Time on the Request you are responding 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



Values: Numeric valuesValid Values: MM = 01 – 12 DD = 01 – 31 YYYY = 20xx HH = 00 – 23 MM = 00 – 59

12 positionN

MMDDYYYYHHMM



DDD/T 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



Values: Numeric valuesValid 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).

12 position N

MMDDYYYYHHMM

ESN/MEID I Equipment Identifier – This is the Electronic Serial Number (ESN) / Mobile Equipment Identifier (MEID) used to identify the subscriber’s handset. This field can be collected from the subscriber’s 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


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

Maximum of 17 position

N



GREQ_NO I Group Request Number - This field is used by the NSP to relate multiple requests generated by the 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


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

Maximum of 16 positionAN[+]

GRESP_NO I Group Response Number – This field indicates the unique number assigned by the OSP, used to relate multiple port responses together. This field can be used for internal OSP utilization.

Record: WPRR


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

Maximum of 20 positionAN[+]



IMPCON I Implementation Contact – This field identifies the NSP representative who is in control of the port. 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


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


INIT I Initiator Identification – This field identifies the NSP representative who originated the request.

Record: WPR, SUP3






LNUM I Line Number – On the initial Request, this field 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 valuesValid Values: 00001 – 01000

5 positionN

Right justify-zero fill

NAME I Name – This field identifies the phone end user. Name repeats as part of an array.

Record: WPR, SUP3


Conditions: Optional.





NLSP I New Local Service Provider – This field indicates 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



Values: Alphanumeric valuesValid Values: Any valid OCN, SPID, or “ZZZZ”.

4 position AN

NNSP I New Network Service Provider – This field indicates the NPAC managed SPID of the facility-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.


Values: Alphanumeric values Valid Values: Any valid SPID value

4 positionAN



NPDI 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



Values: Alpha valuesValid Values: Upper Case Values

A = Wireless to Wireless B = Wireless to Wireline C = Wireline to Wireless

1 position or checkboxA, ENUM

NPQTY I Number Portability Quantity – This field indicates the quantity of telephone numbers involved in the port request.


Derivation: NSP process; OSP populates from most recently received WPR or SUP 3.


Values: Numeric valuesValid Values: 00001-10000

5 position N

Right justify-zero fill



NRSELLNM I New Reseller Name – This field indicates the name of the New Reseller involved in the port Request.

Record: WPR, SPR


Conditions: Conditional – mandatory if NLSP is a reseller, otherwise not populated



OLSP I Old Local Service Provider – This field indicates 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



Values: Alphanumeric valuesValid Values: Any valid OCN, SPID, or “ZZZZ”.

4 positionAN



ONSP I Old Network Service Provider – This field indicates the NPAC managed SPID of the facility-based provider (OSP). This information is used by the NSP in generating the subscription version create.


Derivation: NSP process: OSP populated from WPR or SUP.


Values: Alphanumeric values

Valid Values:

Any valid SPID value

4 positionAN

ORSELLNM I Old Reseller Name – This field indicates the name of the Old Reseller involved in the port response.

Record: WPRR


Conditions: Conditional – mandatory if OLSP is a reseller, otherwise not populated



PSWD/PIN I Password/Pin Number – This field indicates the customer’s password or pin number specified on his/her account within the OSP’s internal systems.

Record: WPR, SUP3


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





PORTED# I Porting Telephone Number – This field indicates a single telephone number (TN) or range of consecutive TNs to be ported. Each telephone number can occur only once in any given WPR, SPR, or WPRR this field repeats as part of an array.


Derivation: NSP process; OSP populates from most recently received WPR or SUP 3.


Values: Numeric Plus values [Including Hex value 2D]Examples: Single Telephone Number: 409-696-1234 Range of Consecutive Numbers: 409-696-1000-1999

12 or 17 position N[+]

NPA-NXX-L111-L222Left justified



RCODE I Reason Code – This field indicates the OSP’s port request issue requiring resolution, per each porting 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


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 can’t be met

6F = Due Time can’t be met

1P = Other (Remarks must be DD/T specific)

Values: Alphanumeric Plus values [including Hex value 20], NULLValid Values: 1P = Other6A = MDN not found/doesn’t belong to this SP6B = Same new and old Network Provider6C = Customer information does not match (should only be used in cases where no other RCODEs beginning with 8 are applicable)6D = MDN not active6E = Due Date can’t be met6F = Due Time can’t be met6K = Administrative number-not portable6N = Port request already pending – duplicate request6P = MDN has service provider port protection7A = LNUM/MDN is valid; errors with other LNUMs/MDNs in request7D = VER ID REQ out of sequence8A = Account number incorrect 8C = Password/PIN incorrect8D = Zip code required or incorrect8H = ESN/MEID incorrect (valid on single-lin port requests only)8X = Cancellation of WPR by OSP01 = Name does not match database

2 position AN[+], NULL



RDET I Reason Code Detail – This field indicates the OSP narrative detail as to why the port request requires 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


Conditions: Conditional – mandatory when RT = R ; prohibited when RT = C or D; Values: L8A


REMARKS I Remarks – This field may be used for comments by the NSP or OSP.

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


REP I Representative – This field indicates the OSP Contact Representative for issues surrounding a port Response. (same verbiage as NSP contact)

Record: WPRR






REQ_NO I Request Number – A unique number assigned by the NSP’s 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.


Derivation: NSP Process, OSP populates from WPR

Conditions: MandatoryValues: Alphanumeric valuesRequest Number = NNSPIYYJJJXXXXXXNNSP=NNSP value from WPRI=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)

Minimum 11, Maximum 16 positionAN

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.



RESP_NO I Response Number – This field uniquely identifies 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.


Derivation: OSP process, NSP populates from WPRR or not populated

Conditions: Mandatory Values: Alphanumeric valuesResponse Number = ONSPIYYJJJXXXXXXXXONSP=ONSP value from WPRI=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 WPRNot populated or populated with RESP_NO from WPRR on SUP 1. Populated with RESP_NO from WPRR on SUP 2 or 3.

Minimum 11, Maximum 18 positionAN

For IDL: Zero length field on initial WPR. (For SUP 1 either a zero length field or populated with RESP_NO returned from OSP.)ONSPIYYJJJXXXXXXXX

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.



RT I Response Type – This field indicates the type of response sent from the OSP. If all Porting 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


Conditions: MandatoryValues: Alpha valuesValid Values: C = Confirmation D = Delay R = Resolution

1 position or checkboxA, ENUM

STATE I State/Province – This field identifies the two character postal code abbreviation for the state/province of the subscriber’s billing address.

Record: WPR, SUP3


Conditions: Conditional – Mandatory when Country is USA, CAN or not populated; otherwise optional.Values: Alphanumeric Plus values [including Hex value 20], NULLWhen 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.)

2 positionA[+], NULL



SUP I Supplement Type – This field identifies the reason 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 entirety2 = New Desired Due Date and Time – Indicates that the pending order requires only a change of desired due date and time3 = 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.

1 position or checkboxN[+]

The SUP field is not populated on the initial Request

TEL NO (IMPCON)

I Telephone Number – This is the telephone number for the Implementation Contact (IMPCON). It includes space for a four-digit extension line.

Record: WPR, SUP3



Values: Numeric Plus values [including Hex value 2D]

Minimum 12, maximum 17 positionN [+]

NPA-NXX-LLLL-XXXX

Left justify



TEL NO (REP) I Telephone Number - OSP Contact Representative Telephone Number for issues surrounding this port request and response.

Record: WPRR



Values: Numeric Plus values [including Hex value 2D]

Minimum 12, maximum 17 position N [+]

NPA-NXX-LLLL-XXXX

Left justify

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.


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 valuesValid Values: 01 – 99 beginning with each WPR and incremented by “+01” for each related SPR.

2 position N



VER ID RESP I Version Identification for the Response – This 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 WPRRValues: NumericExamples:01 – 99 – as additional updated Responses are sent from the OSP to the NSP.

2 positionN

CWNPG_REL_NO

I 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


Values: Numeric Plus [including Hex value 2F]

Valid Value: 3.0.0

5 to 6 positionN[+]

X.Y.ZX range: 1-99Y range :0- 9Z range :0-9Left justifiedNo zero padding



ZIP CODE F, I ZIP Code/Postal Code – This field identifies the zip code or postal code of the subscriber’s 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


Conditions: OptionalNOTE: 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)

Maximum 10 positionAN[+]

xxxxx-xxxx for US

xxxxxx for Canadian


14 Glossary of Terms

Term/Acronym DefinitionAMPS Advanced Mobile Phone SystemB&CC Billing & Customer CareBPWG Business Process Working GroupCC Customer CareCDMA Code Division Multiple AccessCISC CRTC Industry Steering CommitteeCMRS Commercial Mobile Radio ServiceCRTC Canadian Radio Television and Telecommuncation CommissionCWNPG Canadian Wireless Number Portability GuidelinesCWTA Canadian Wireless Telecommunicaitons AssociationEDI Electronic Data Interface. A standard mechanized exchange of data. Standards

developed at the national level. FOC 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 TN’s, then the LSR should be rejected.

GMT Greenwich Mean TimeGSM Global System for Mobile CommunicationICP Intercarrier Communication ProcessIDL Interface Definition LanguageIMSI 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.

INS Interoperable Naming ServiceIOR Interoperable Object ReferenceLNP Local Number Portability.LNPA_WG Local Number Portability Administration Working GroupLRN Location Routing Number. A 10 digit number that uniquely identifies a switch.

Every ported subscriber’s 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.

LSMS Local Service Management SystemLSP Local Service ProviderLSR 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


Term/Acronym Definitionindividually as to what method of exchange will be used.

MDN Mobile Directory Number – the 10 digit NANP number that is dialed to reach a specific terminal – see also: MSISDN.

MIN 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).

MSID Mobile Station Identifier—either 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.

MSISDN 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.

NAG Number Advisory GroupNANC North American Numbering CouncilNANP North American Numbering PlanNECA National Exchange Carrier AssociationNICP New Intercarrier Communication ProcessNP Number PortabilityNP DB Number Portability DatabaseNPAC Number Portability Administration Center NPAC-SMS Number Portability Administration Center Service Management SystemNSP New Service ProviderOBF Ordering and Billing ForumOICP Old Intercarrier Communication ProcessORB Object Request BrokerOSP Old Service ProviderOSS Operations Support SystemPOS Point of Sale or Point of ServicePSTN Public Switched Telecommunications NetworkRBOC Regional Bell Operating CompanyRFI Request for InformationSLA Service Level AgreementSMR Specialized Mobile RadioSMS Short Message ServiceSOA 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.

SOE 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.


Term/Acronym DefinitionSPID Service Provider IdentificationSV Subscription Version. NPAC SMS data object that represents a ported telephone

number.TDMA Time Division Multiple AccessTLDN Temporary Local Directory NumberURI Universal Resource IdentifierWNP Wireless Number Portability. Interchangeable with LNP, but often used when

pointing out differences between the Landline and Wireless porting processes.WPR Wireless Port RequestWPRR Wireless Port Request ResponseWSP Wireless Service Provider


15 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?).

15.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.


15.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.

15.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.

15.4 Line Activity Codes

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

16 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 nameo Same due dateo Same purchase order number

16.1 Porting of Suspended and Disconnected Telephone Numbers

This section provides the industry rules for determining whether a suspended or disconnected telephone number is portable between service providers.

16.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.


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.

16.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 it’s eligibility to port at the customer’s 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 customer’s 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 customer’s service is confidential information and must not be disclosed to another service provider without the customer’s consent.

16.2 Hours of Operations

16.2.1 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.

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.


16.2.2 NPAC/Neustar Hours of operations will support the carriers hours of operations across Canada. These

hours of operations will be from TBD

17 Fall Out

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


cwnpg_v1_7_august_15_2006.doc

Documents

jjj system julian date

statutory holidays observed

addressing fallout caused

general rule apply

coordinated hot cut

service provider suspends

bit ascii minus

local service provider