Contactez-nous

partie centrale qui "pousse"

1. List of Ported Numbers and Routing to Ported Numbers

This set of questions is targeted at TSPs interested in knowing where to route correctly the traffic to ported numbers in Switzerland. It deals with downloading an initial file with all ported numbers, with the daily incremental files and with the general portability routing principles. The targeted TSPs are not part of the porting process ("read-only" TSPs).

A quick start guide is also available here.

/

What are the main reference documents?

Other useful Documents:

What numbers are contained in the Swiss central database of ported numbers (INet-Server)?

Following types of numbers can be ported in Switzerland among operators:

  • mobile numbers pre-paid
  • mobile numbers postpaid
  • PSTN / ISDN
  • DDI
  • INA (Value Added Service and Directory Numbers)

The INet-Server only contains ported numbers and their history. Numbers not contained in the INet-Server are held by the Number Range Owner and can be found under www.eofcom.ch. Note that geographical number portability is not supported by the INet-Server.

For INA, all numbers allocated by the Regulator are contained in the database. The ONP Service only permits to obtain the routing information (NPRNs) of an INA number; for tariff information, the INA service is needed.

How to download the information about all ported numbers in Switzerland (initial file)?

Each week, a file containing all ported number (allnumbers_XXX) as well as all the subsequent delta files (generated each 2 hours) is available under the SSH directory …/tsp<TSP_ID>/lpn. The sum of all these files will provide all the ported numbers as per today.

 

It is also possible to generate a customized all-numbers file (.lpn file - LIST Ported Numbers): this can either be ordered via file transfer (cf. SSH File Transfer Detailed Technical Specifications ONP, chapter 2.2.1.3.12 & 13, commands LIST & LISTZ) or via GUI LIST Ported Number. Be careful how to generate this file to ensure it contains the correct information. It is highly recommended to use the File Transfer method.

SSH File Transfer Method:

You can order it by means of the LIST command in the upl file (File Transfer)
The records of the .lpn files are described under chapter. 2.2.5 of SSH File Transfer Detailed Technical Specifications ONP. Note that the .lpn file contains the current state of the number, but also includes the history of porting activity for the given number. A number only appears in the lpn file once the handover has taken place (WO status = OK = 006) or when the number has been returnd to number range holder (WO status = RET_TO_NRH = 008). For a first file of ported numbers, you should exclude WO status = 008.

If a TSP has a requirement for recurring data extracts, it is recommended to create automated procedures for obtaining zipped .lpn data. For the full automation of processes, it is recommended to also look at the Functional Specifications ONP, specifically the chapters related to "periodic downloads" and "time based lpn processing".

 

GUI Method:

Under "List Ported Numbers", click on Download in the display "Ported Numbers List". Because of the amount of records, it is necessary to request for zipped result files. In this way you can submit a single request for obtaining all ported numbers of a single connection type in one result set. It is important to specify in the selection criteria the work-order status to be "OK".

In case you have no direct Internet access, the connection can be broken before you obtain the results. Therefore it is recommended to use the file transfer interface: send an upl file via the SSH interface and look at the resulted file under your SSH Home Directory.

How do I get incremental files with ported numbers in Switzerland?

Incremental files are generated on the INet-Server every 2 hours and are called lpn files (if a number is ported on 08:44, the number will appear in the lpn file of 10:00). For proper routing to ported numbers, it is important to use these files to update the List of Ported number on a periodic basis.

It is strongly recommended to use automated processes for this task, see the download of files via SSH, as per SSH File Transfer Detailed Technical Specification ONP.

Note that automatically generated lpn files can also be downloaded manually from the GUI Menu bar "Download lpn files".

Note that a number only appears in the automatically generated lpn file once the handover has taken place (status OK) or once it has been returned to Number Range Holder (status RET_TO_NRH).

What if I incur a loss of data in the ported numbers files? Can I generate the delta of ported numbers in Switzerland or should I download a whole initial file again?

Incremental files can be generated manually with appropriate selection criteria (e.g. on the activation date/time):

Can I get the history of ported numbers ?

LPN Files always contain the full history of all port activity on the number.

How can I determine if a number has become inactive (not in use) or no longer ported?

If an outported number is no longer used, the current operator does a return-to-NRH. Therefore, the status of the number is RET_TO_NRH (The record "WO_Status" of the lpn file contains the field 008 = RET_TO_NRH), but the number will still appear in the ported number list (.lpn files).

Note however that not all numbers in status "RET_TO_NRH" are inactive numbers. Fact is that the system recognizes when the Recipient of a porting transaction is the same as the Number Range Holder (NRH). In this case, some time after the porting transaction, the system generates a RET_TO_NRH transaction in order to reflect the fact that the customer has returned his original operator.

Whether the number is then in operations at the NRH or not is irrelevant to the INet-Server, fact is that the number is no longer in the status ported.

--> the RET_TO_NRH numbers don't appear in the "allnumbers" .lpn file. There you only see the numbers which are in status ported.

What is contained in an .lpn file and how to read its content?

An .lpn file contains information about ported numbers (and their history). Here is a template of the fields of an lpn file.

An .lpn file can be extracted using Notepad++ (http://notepad-plus.sourceforge.net/) and then pasted into Excel (e.g. into the template above), so that the different fields are shown correctly in different columns.  

What is required to be able to retrieve automatically the available lpn files ?

The transmission of files to/from TSP-INet is based on a secure protocol (SSH) which requires cryptographic keys installed on both the sending and the receiving computer. Therefore, if you wish to send files directly from your PC, you need: an SSH client program and SSH keys.

Also consider that file transfers are controlled by sequence numbers. If you send files from your PC, your sequence may interfere with other transfer sequences of your company.

What are the general Routing Principles for Number Portability ?

Main reference documents are the Technical specification for number portability in fixed networks and the Technical specification for number portability in mobile networks.
All TSPs wanting to Port-In Numbers (as Recipient) need a Number Portability Routing Number (NPRN) address issued by the National Regulatory Authority OFCOM.
The Number Range Holder (NRH) principle applies to geographical and mobile numbers allocated by OFCOM in number blocs. All originating networks (except the Recipient) can route calls to the NRH who is required to add the NPRN of the current Recipient and forwards the call to it. In practice, mobile originating networks make all the query check themselves for mobile numbers and Swisscom as main transit network in Switzerland makes it for all numbers to ensure more adequate routing to the Recipient.
The direct routing principle applies to Value Added Services (VAS) and Directory services numbers allocated by OFCOM to the number owner according to the Individual Number Allocation (INA) rules, with the direct routing from the originating network to the Recipient by adding the NPRN.

The recipient network is addressed with a prefix in the Called Party Number, the Number Portability Routing Number. The Called Party Number Parameter in the ISUP IAM must be coded in the following way:

  • Nature of address indicator: national significant number
  • Numbering plan indicator: ISDN telephony numbering plan (E.164)
  • Address signals: Number Portability Routing Number + national significant number (the NPRN identifies the recipient network and is assigned from BAKOM to each operator).

INA routing principles:

With the introduction of INA, the definition of number range holder for service numbers is lost. Originally all numbers are owned by BAKOM and a service number customer can apply for those numbers. Following rules are applicable for INA service numbers:

  • when the number is taken into service or ported from one service provider to another service provider all originating carriers have to use the NPRN of the service provider which implements the INA number.
  • The CDP-ID of the selected carrier is added between NPRN and INA service number, i.e 980xx 107yy 900333111
  • The NPRN and CDP-ID cannot be modified by any transit network
  • The transition time period functionality is not applicable for subsequent porting of INA service numbers.
  • If a PTS receives a INA call with his own NPRN, and he detects that this INA number is now serviced by another PTS, the call has to be released.

 

 

What is the Number Portability Routing Number (NPRN) needed for ?

The Number Portability Routing Number (NPRN) is allocated by the Regulator (OFCOM / BAKOM) and is always under the format 98xxx. On the INet-Server, the NPRN is used also to identify the User Account.
The NPRN is used in the call signaling information to route correctly the traffic. More details on the technical process can be found in the documents Technical specification for number portability in fixed networks and in Technical specification for number portability in mobile networks.
Note that an official NPRN is only necessary for TSPs wanting to participate in the Portability Process as a Recipient (port in numbers). All other TSPs can request a dummy NPRN from Teldas as User Account Identifier. These dummy NPRN are under the format 99xxx and they cannot be used to port-in numbers (read-only accounts). Same is valid for INA (read-only with dummy NPRN).

Where can I get a list of all Number Ranges and their respective holder?

You can go on the INet Menu "Donor Lookup" and enter a SUB_NR to find where the number is implemented. It provides the last Recipient (for numbers having already ported) or the Number Range Owner (for numbers never ported and thus not referenced in the Inet-Database of ported numbers) or an error message in case the number doesn't belong to an allocated number bloc.

OFCOM publishes a list of number ranges with the operator owning them (i.e. the NRH in INet "Server terminology"). This gives you the information for all subscriber numbers, regardless of whether or not they have been ported. In the INet-Server, you will only find the numbers which have been ported.

The OFCOM List is also available on the INet-Server. You can find it under the reports menu (SSH or GUI):

  • OFCOM_List_Original_YYYYMMDD contains the raw information uploaded every night by OFCOM
  • OFCOM_List_New_YYYYMMDD contains the information enhanced by INet (unambiguous NPRN allocated to the number block for TSPs owning different NPRNs / dummy NPRN 99900 for number blocks belonging to TSPs not active on INet-Server...). This is the list that is used in INet to determine the operator where a number is currently in service (if not already ported).
What is the meaning of the status RET_TO_NRH?

There are 2 ways to have a number in status RET_TO_NRH. Either the subscriber wants to port his number back to the Number Range Holder (NRH), in this case the NRH initiates a work order (port-in request), which results in a status OK. 30 days after this operation, the INet-Server automatically changes the status of the work-order into RET_TO_NRH.
Or the subscriber has cancelled his contract with his Operator and therefore the current operator initiates a Return to NRH, with as result a status RET_TO_NRH.

Therefore, a number in the status RET_TO_NRH can be either active (--> port back) or inactive (--> number returned to NRH by the last Recipient).

What is the difference between .lpn files and .lpw files ?

The lpn (short for List Ported Numbers) is used by telephone companies to configure the routing tables of their switches. Therefore, it contains only data about COMPLETED ports. You order it by means of the LIST command in the upl file (cf. SSH File Transfer Detailed Technical Specification ONP). The system also generates every week an "all numbers" .lpn file and delta .lpn files every 2h. These are available under the LPN SSH Directory or GUI menu.

The lpw (short for List Pending Workorders) is used by telephone companies to manage porting activities and is not available to all TSPs. A read-only TSP cannot generate/see lpw files. LPW files may contain completed or open work orders, depending on the selection. You order it by means of the READ command in the upl file (cf. SSH File Transfer Detailed Technical Specification ONP). 

2. ONP Administrative Process

This set of questions is focused on TSPs who are themselves part of a portability process, either as a Donor or as a Recipient. For the routing questions, refer to the ONP section above.

A quick start guide is also available here.

/

What are the main documents?
  • ONP Document for Implementation: This document describes the general operational processes among operators for the porting of numbers in Switzerland. This document is focused at operators being an active part in the portability process (as Donor or as Recipient). It is the main reference document.
  • SSH File Transfer Detailed Technical Specifications ONP: This document describes the automatic file transfer interface (notably how to download portability orders via automatic interface for a Donor and a Recipient). This concerns operators wanting to fully automate their portability processes and creating an automatic interface between their systems and the INet-Server for the sending of batch orders.

Other useful documents:

  • General User Manual (GUM) for the Inet-Server: This document describes how to open a user account or modify a user profile on the INet-Server and how to interact with the TELDAS Helpdesk (notably also for the timeout management).
How to port in a number ?

There are 2 types of processes available, depending on the level of process automation wanted by the user.

Work-orders can be initiated by the Recipient either via file transfer (see SSH File Transfer Detailed Technical Specifications ONP) or manually via GUI.

The Donor on its side has also the choice of using the file transfer interface or the GUI. A portability can be a any mix of GUI & File Transfer. 

The main steps of the porting process are described below (for more information about the process, see ONP Document for Implementation):

  1. The customer signs a Power of Attorney (PoA) of the Recipient TSP or sends a departure SMS to 499 (if Mobile Prepay customer at Recipient)
  2. The Recipient initiates the porting in the INet-Server with the necessary data (wish date/time if any, customer data) and sends the PoA to the Donor TSP*
  3. The Donor verifies the data and accepts or rejects the porting request (using valid rejection reasons as defined and adding the contract end date as activation whenever applicable). At this point, the activation date and time are fixed**
  4. After Acceptance by the Donor, the Recipient sends the synchronization order to the Donor. This is the point of no return (not possible anymore to cancel the WO)
  5. Donor and Recipient adapt the Routing within a time window of 2x15min
  6. The Recipient issues a hand-over order (=notification to all other TSPs about the successful porting)

Note that the Inet-Server supports and controls all steps in the process with the exception of step 1 and 5.

* PoA only exchanged if no specific agreement exists among Donor / Recipient.

** Note that if the Donor TSP = 99900 (Dummy), then the Donor Role must be performed by the Recipient, refer to the question "What if the Number I want to port belongs to a TSP which is not a user of the INet-Server?".

List of Workorders (Lpw data / READ & READZ)

The work-order history is available during 5 years. Work-orders older than 5 years are archived outside of the INet-Server.

The .lpw files (List Pending Workorders) is used by telephone companies to manage porting activities. It may contain completed or open work orders, depending on the selection criteria. You order it by means of the READ command in the upl file (file transfer, see SSH File Transfer Detailed Technical Specifications ONP) or you can also get it from the web GUI (Select Work Order), when you click on "Download lpw" in the display "Work Order Summary". The "Select Work Orders" screen will be used to handle the work orders. The button Download compressed will present the results as a downloadable compressed .lpw file. 

Note that contrarily to the lpn files (list of ported numbers), the list of work-orders contains confidential information (customer data) and therefore the TSPs can only see work-orders in which they participated as a Donor or Recipient (own NPRN is present on the transaction as Donor or Recipient).

With which program should I open the lpw files?

First, the files should be extracted using Notepad++ (http://notepad-plus.sourceforge.net/) and then pasted into Excel, so that the different fields are shown correctly in different columns. Attached a template for the lpw file.

Excel for LPW File

Why has a work-order gone in status Cancel_D ?

Status Cancel_D is generated automatically by the application when the activation date (Handover) falls on a non-working day. This happens when a new non-working day has been added in the Non-Working Days List, for example because of a maintenance window.

The Recipient Operator is then obliged to initiate a new work-order (the Recycle function can be used).

Timeouts: What are they and how to handle them ?

Work-orders go in timeout status if an action was not performed timely by one of the parties. Timeouts are used by TSPs to calculate SLA Penalties (See the SLA ONP for details on penalties).

A timer is set-up after every transaction to ensure TSP response times are kept. If a timer fires, the work order is moved to WO_STATUS = (TIMEOUT_A, then to TIMEOUT_B, then to TIMEOUT_H) and finally to Cancel_H (through the TSP Manager). SLA penalties usually increase at each timeout level.

Timeout times are calculated based on the System Parameters BUSINESS_TIME_START, BUSINESS_TIME_END and can defer for the different connection types.

Whenever a work order goes into a timeout state, only a person with "supervisor rights" can bring the work-order into the next state. For example, if a TSP fails to do a SYNC before it times out, the TSP (Recipient) Supervisor can either CANCEL or SYNC the work order; normal users cannot do it.

At each timeout, notifications are sent out to the failure contact email address.

Timeouts: What to do when a work-order goes into timeout state ?

Whenever a work order goes into a timeout state, only a person with "supervisor rights" can bring the work-order into the next state.

For example, if a TSP fails to do a SYNC before it times out, the TSP (Recipient) supervisor can either CANCEL or SYNC the work order; normal users cannot do it.

Timeouts: How can a TSP subscribe to timeout notifications ?

Timeout notifications are sent to the failure contact email address (see General User Manual (GUM) for the Inet-Server).

Other e-mail reminders can be defined. Ordering form can be found under in the General User Manual (GUM) for the Inet-Server, with possibility to define how much advance warning is wanted.

Timeouts: What are the different types of timeouts ?

Timeout 1: late acceptance/rejection by the Donor
Timeout 2: late represent by the Recipient
Timeout 3: late acceptance after Represent by the Donor
Timeout 4: late synchronisation by the Recipient
Timeout 5: late Handover by the Donor, Recipient or NRH

For each of these timeouts, there is always first a "timeout A", then if no reaction within x hours, "timeout B" follows, then if no reaction "timeout H" follows. The different Timeout levels are used by Operators to calculate SLA penalties (see ONP SLA).

When should an operator make a Return to Number Range Holder ?

When a subscriber gives up his/her ported number it must be returned to the Number Range Holder within 40 but at earliest 20 working days. More information to be found in the "ONP Document for Implementation".

The last Recipient initiates a RNRH in the INet-Server, which will generate an entry in the ported number database (periodic .lpn file, work-order status = 006 = return to NRH).

How to perform the Return to Number Range Holder function is described in the document ONP Document for Implementation, chapter Return to Number Range Holder.

How can I find information about a Donor of a Number?

Note that when porting a number, the Donor field is optionnal. INet will find out the correct Donor based on following rules:

The Donor of a number is either the Number Range Holder (to be found in the OFCOM_List_new, NPRN of allocated number blocs) or the last Recipient (to be found in the INet-Server List of Ported Numbers / .lpn files).

The OFCOM_List_new can be found under the Report menu, scroll down until the end where all the OFCOM_Lists are stored.

A GUI menu "Donor Lookup" is available to find at which operator a number is currently, even if the number was never ported.

What if the Number I want to port belongs to a TSP which is not a user of the INet-Server ?

In this case, you should contact your Supervisor to ask to create (if not yet available) a User Account on the Dummy TSP 99900, which enables you to play the Donor role on the INet-Server on behalf of the Non-User TSP. See the "ONP Document for Implementation", chapter "ONP Process with a Donor as non-user of the INet-Server" for the detailed process.

Note that you need only to ask once for a User Account on the Dummy TSP, this User Id can then be used for future portings with the Donor = 99900.

DDI Operations - What does splitting mean ?

A split operation is something the NRH can do, but only if he is operating the range. This happens usually when part of a range goes to another operator. If a split operation would result in a piece with less than 10 numbers, TSP-INet will refuse to split.
Whenever a range is split, each resulting part of the range becomes a normal DDI range. It is possible to split it further. The only restriction for a split operation is that a range must include at least 10 consecutive numbers. If a resulting range doesn't have a main number, the lowest number should be assigned.

DDI Operations - When is Merging possible ?

Merge operations are only possible when joining contiguous number ranges.

DDI: Can I change the DDI Type into PSTN/ISDN ?

No, a DDI range remains a DDI range. A conversion to single numbers (PSTN/ISDN) is not possible on the INet-Server.

 

DDI: What does the Main Number of a DDI range represent ?

DDI ranges are used by companies with a PABX. They publish a single number (i.e. the main number) for people to call in, but multiple concurrent calls are possible. So the main number serves an identification purpose for everything connected to the PABX, while the number of concurrent calls is limited by the size of the number block.

In Inet though, the main number field (=SUB_NR1 field) is only informative and in some cases also incorrect when DDI blocs are splitted and might not contain anymore the main number. In INet, the main number field is validated as being always part of the lower (=SUB_NR2 field)-upper (=SUB_NR3 field) DDI range.

3. High level overview of GUI and SSH interface for ONP

/

1. Web Interface (GUI)

This is good for manual request only. There is no way to automate recurrent requests for .lnp file download via this interface in order to retrieve files either on the web site or via ssh.

  • Menu Download lnp files allows download of daily files uploaded every 2 hours. Files from last 7 days are usually available + a weekly file with "all numbers".
  • Menu Download tsp files allows download of files with + or - information on the different carriers. Delta files and full files are available for the last month. Note that a search tool is available under the menu "TSP Info".
  • Menu "Donor Lookup" permits to find the NPRN and TSP name of the TSP operating a specific SUB_NR.
  • Menu "TSP Info" permits to search specific information about TSPs (CDP-Ids, second party TSPs...).
  • Menu List Ported Numbers allows download of lpn files based on different criteria's (WO number, date, # type, etc.). 
  • Menu Select Work Orders allows download of WO files based on different criteria's.
  • Menu Initiate Work Order allows to perform a number portability : all steps from the Initiation by the Recipient, the Acceptance / Rejection by the Donor and Handover Message once the porting has taken place.

Screenshot

2. SSH Interface (Automatic File Transfer)

This is the way to proceed in order to be able to automate the process for file download. Logic can be defined via a script in order to exchange files in the appropriate sequence to query data information and retrieve files. Exchanges are possible using ssh, scp and sftp only.

Useful directories in the user's SSH login directory (/tsp<TSP_ID>/...):

  • clsn (to retrieve the clsn lists for all your GUI users)
  • reports (to retrieve ofcom lists for example)
  • tsp (list of the operators: NPRN, company names...)
  • lpn (list of ported numbers: the file allnumbers is generated weekly, then every 2 hours a delta file)

To generate manually .lpn files: LIST or LISTZ record must be used in a .upl file. It can be used to get the daily delta (instead of using the files generated every 2 hours) or to get a dump of all entries. The usual logic to retrieve files consists in uploading a request file with the .upl extension. Once transfer is completed, a .rdy file must be uploaded to confirm previous step. The request is then processed and downloaded to the TSP server. Once download is completed, TSP must upload a .rdy file to confirm successful download. The file will then be moved to the archive.