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.
Other useful Documents:
Following types of numbers can be ported in Switzerland among operators:
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.
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 220.127.116.11.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".
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.
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).
Incremental files can be generated manually with appropriate selection criteria (e.g. on the activation date/time):
LPN Files always contain the full history of all port activity on the number.
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.
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.
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.
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:
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:
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).
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):
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).
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).
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.
Other useful documents:
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):
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?".
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).
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.
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).
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.
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.
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.
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 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.
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.
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.
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.
Merge operations are only possible when joining contiguous number ranges.
No, a DDI range remains a DDI range. A conversion to single numbers (PSTN/ISDN) is not possible on the INet-Server.
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.
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.
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>/...):
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.