This Document Addresses the Inter-Operator IT Systems Requirements to Support the Generic

© 2003 IN CONFIDENCE

IN CONFIDENCE
mobile number portability
process group
porting process
IT systems requirements
version 14.3

SCOPE

This document addresses the inter-Operator IT systems requirements to support the generic MNP business processes for porting an MSISDN between networks.

These system requirements are driven by the business processes agreed by the MNP Process Group, and described in detail in the MNP Porting Process Manual.

The system requirements presented in this document have been proposed by the MNP Process IT Sub-Group, which was formed specifically to address and agree the technical solution to the MNP business process requirements. This technical solution may be subject to change following review and on-going discussion by the MNP Process IT Sub- Group.

PURPOSE

This document is intended to describe the interface used by network operators to initiate mobile number ports.

DOCUMENT TABLE OF CONTENTS

SCOPE...... 1

PURPOSE...... 1

1.introduction (including intro of a new operator)...... 3

1.1background...... 4

1.2assumptions...... 5

2.IT technical requirements...... 7

2.1scope...... 7

2.2interface media...... 7

2.3security...... 7

2.4file transfer process...... 7

2.4.1 Port Files...... 7

2.4.2 File Naming Convention...... 8

2.4.3 File Transfer Method...... 9

2.4.4 Backups...... 9

2.5port files...... 9

2.5.1 Port Request File...... 9

2.5.2 Port Response File...... 11

2.5.3 Repatriation Request File...... 12

2.5.4 Repatriation Response File...... 13

2.5.5 Error Reply Files - i.e. .BRQ, .BRP, .BPT, BPR, or .BAD...... 14

2.5.5.1File Fails Validation...... 15

2.5.5.2Detail Record(s) Fail Validation...... 15

2.6 availability...... 15

2.7 resilience options...... 15

2.8 PORTED TEST NUMBERS……………………………………………………………………..16-18

appendix A - action codes...... 19

appendix B - action statuS...... 19-20

APPENDIX C - PROCESS AMENDMENT REQUEST FORM...... 21

Document History……………………………………………………………………………………22

INTRODUCTION OF A NEW MOBILE OPERATOR

In any instance where a new mobile network operator is introduced, it is the responsibility of each existing mobile network operator to provide a single point of contact to co-ordinate all activities involved with the introduction of the new operator.

DEFINITION OF TERMS

ONOOriginal Network Operator

DNODonor Network Operator

RNORecipient Network Operator

DSPDonor Service Provider

RSPRecipient Service Provider

Current NetworkCurrent Network Operator once porting has occurred

(used for clarity when describing subscription

termination)

Current SubscriptionThe entity on the Current Network which supports the provision of service against a porting MSISDN

New SubscriptionThe entity on the Recipient Network which supports the provision of service against a porting MSISDN

Residual SubscriptionThe entity on the Original Network which supports the re-routing of mobile-terminating traffic for a ported MSISDN

REFERENCES

1. Mobile Number Portability Process Group – Porting Process Manual

1. introduction

1.1background

The scope of this document extends only to MNP business processes which involve inter-Operator transactions. These are extracted from the Porting Process Manual, ref [1] and summarised below.

Porting Processes

Figure 1 presents the generic porting process to cover all porting scenarios (i.e. initial and subsequent ports). Where the port is an initial port, the DNO and ONO are the same, and all processes attributed to the ONO shall be performed by the DNO.

indicates a response to the action is required

The relevant inter-Operator processes are as follows:

7A – DNO proceeds with port-out actions

7A.2On the porting date, for valid porting MSISDNs, the DNO shall request the ONO to re-route incoming traffic to the porting MSISDN towards the RNO.

7A.3The DNO shall provide the ONO with the following porting data:

7A.3.1porting MSISDN(s)

7A.3.2RNO

7A.3.3porting date (for audit purposes only)

7B – ONO modifies residual subscription

7B.1The ONO may validate the “ownership” of the porting MSISDN(s).

7B.2The ONO shall either:

7B.2.1modify the residual subscription to re-route traffic as requested, and return a confirmation to the DNO and the RNO, or

7B.2.2reject the re-direction request and identify to the DNO the invalid porting data

9 – RNO confirms successful re-routing (optional)

After the agreed porting window on the porting date the RNO may query the residual subscription for the ported MSISDN on the ONO, to determine whether incoming traffic to the ported MSISDN is being correctly re-routed to the RNO. The RNO/RSP may escalate the problem with the DNO/DSP if the query indicates that the re-route has not been successfully completed.

Repatriation Processes

Repatriation is the return of complete control over the ported MSISDN to the ONO.

The only inter-Operator transaction is as follows:

1. The Current Network records the termination date of the ported MSISDN and notifies the ONO of the MSISDN(s) and termination date, upon expiry of the MNP holding period of six months.

assumptions

The ONO will accept port requests between the hours of 09.00am and 16.00pm, Monday to Friday. The ONO does not perform any scheduling of port activities. Port requests are actioned on receipt by the ONO.

It the responsibility of the DNO to agree with the DSP when port requests can be accepted.

It is the responsibility of the DNO to schedule port requests. Each NO should size their systems appropriately.

Some of the porting transactions are time dependent. It is expected that the NO’s system clock will be checked weekly to ensure it is recording the correct time.

Service Level Agreements between DSP, DNO and ONO will be agreed after inter-operator testing for mobile number portability. (This need to be agreed in next ORG meeting)

It is the responsibility of each NO to size their systems according to the volume of porting transactions they expect to get.

2.IT technical requirements

2.1 scope

The scope of the technical requirements addressed here is limited to the transactions which relate to the inter-Operator processes described previously, namely:

porting transactions 7A, 7B and 9 presented in section 2.1

the repatriation transaction presented in section 2.2

Other processes fall outside the scope of this document since they are either:

inter-SP transactions (fax is assumed to be the lowest common interface)

interactions between SPs and their associated NO (the nature of the technical solution to these “internal” transactions is “private” to the individual Nos)

processing which is internal to each NO or SP

The specification of the technical solution comprises:

Inter-Operator system interface media and data protocols

System interface data flows and data definitions

2.2 interface media

Inter-operator transactions will be exchanged via a file transfer mechanism. Files shall be transferred either via dedicated point-to-point links between operators or via the internet as summarised in Figure 1.

Figure 1: Protocols Used for File Transfers Between Operators

For mobile operators incorporated into the porting process prior to 2007 (referred to as “imcumbents” in Figure 1):

• Secure, point-to-point links shall be used to pass data between Network Operators.
• operators currently use dedicated ISDN lines to link their data networks such that MNP-related files can be transmitted between network operators.
• Port request files, port response files, repatriation files and error reply files shall be transmitted via FTP over TCP/IP.

All file transfers between operators incorporated during or after 2007 shall transmit the files as follows:

• Transmission shall be via the public internet
• Files shall be transferred using the SSH secure FTP protocol as defined in the specification “Use of Secure File Transfer over SSH to facilitate the exchange of Mobile Number Port Information files between UK Mobile Networks v1.5” which is attached below.

Operators currently using FTP over ISDN may wish to standardise their file handling processes to the SFTP solution via mutual agreement. It is not anticipated that any operator currently using SFTP would wish to downgrade to an FTP over ISDN solution.

2.3 security

The information contained within the port requests is not classified as sensitive data. No customer details are contained within the request. Stringent security measures are not expected to be put in place.

Despite the security already afforded by the use of dedicated ISDN lines all operators had agreed to encrypt the MNP files transmitted over these links through the use of Secure FTP. Specifically, operators were to use version 2 of the SSH protocol with keys generated using DSA at a bit strength of 1024 bits. This requirement for files to be transmitted via Secure FTP has subsequently been rescinded.

2.4 file transfer process

2.4.1Port Files

There are 9 types of port files which are exchanged between network operators:

port-out request file

port-out response file

repatration request file

repatriation response file.

port-out request error file

port-out reponse error file

repatriation request error file

repatriation response error file

suffix error file

The data within each file is in ASCII( ISO 646 7 bit characters ) format. The default value for a numerical field is 0, right justified. The default value for an alphanumeric field is <space>, left justified. All data within each file should be in upper case.

Each of these files is subject to the same file naming convention, file transfer mechanism and backup strategy. These are defined in the following sections.

2.4.2File Naming Convention

The NO shall write up to 1000 detail records in a porting file before closing the file. A port file has the following naming convention:

SNYYYYMMDDHHMMDNXXX.ZZZ

where:

YYYYMMDDHHMM represents the date and time. The date and time will be the actual date and time the file was created.

SN represents the source network operator sending the port file

DN represents the destination network operator receiving the port file

XXX represents the daily file sequence number, from 001 to 999

and ZZZ indicates a type of file.

The file names should be in upper case characters.

Valid codes for network operators are:

VF- Vodafone

CN- O2

HM – Orange

• ME - T-Mobile

TG – Three

Valid codes for file type are:

REQ – port request

RSP – port response

PAT – repatriation request

PAR – repatriation response

BRQ – port request error file

BRP – port-response error file

BPT – repatriation request error file

BPR – repatriation response error file

BAD – suffix error file

2.4.3 Transaction number

Section 2.5 Port Files refers to a transaction number that is contained in the detail record for all files. The transaction number is commonly known as the 'Request ID'. The transaction number needs to be a unique number.

Field / Size / Description
Transaction number / X(10) / GSM International standard alphabetic
NO identifier + 8 digit number
This is the transaction number from the port request transaction.

The transaction number identifies the port. The transaction number has the following naming convention:

SN00000000

SN represents the source network operator sending the port file.

00000000 represents 8-digit number.

The numbers in the file convention are limited. These numbers should be recycled every 12 months to avoid a duplicate. If the transaction number is duplicated the port file will fail.

2.4.4File Transfer Method

The source network operator is responsible for establishing an ftp session and pushing the file onto a designated directory on the destination network operator’s system. The source network operator is responsible for implementing ftp retry mechanisms to allow for engaged telephone lines, or other connection problems.

It is suggested that the source network operator transfers port files to the destination network operator when required. It is suggested that the source network operator should send port files every 15 minutes, or sooner if a complete file of 1000 detail records is available. It is suggested that the destination network operator scans for new port files every 15 minutes. If there are no port files to send, no file is sent to the destination network operator.

If files arrive out of sequence, it is suggested that the NO should still process the files. However, an alert should be triggered to notify the operations staff of a potential problem.

2.4.5Backups

It is suggested that the source network operator maintains an on-line archive of the port files for a period of 3 months. This should allow sufficient time for any port problem to be resolved.

It is suggested that the destination network operator maintains an on-line archive of the port files for a period of 3 months. This should allow sufficient time for any port problem to be resolved.

2.5port files

2.5.1Port Request File

Header record

Field / Size / Description
Record Id / X(3) / Record id, value ‘HDR’
Spare / 9(5) / Set to 00000
Date / 9(14) / Date in yyyymmddhhmmss format
Time is in 24hour format
Version Number / 9(2) / Indicates version of record for future use
Initial value = 01
Current file name / X(23) / Actual file name of request file
Previous file name / X(23) / Previous port request file name
New line / X(1) / end of line marker, ASCII hex 0A

Detail record

Field / Size / Description
Transaction number / X(10) / GSM International standard alphabetic
NO identifier + 8 digit number
Unique across all request transactions
Request date / 9(14) / Date & time of port request in
yyyymmddhhmmss format
Time is in 24hour format
Action Code / X(2) / Indicates type of request
Action Status / X(2) / Indicates result of the transaction
set to FF in request files
MSISDN / X(15) / CCITT E.164 standard for MSISDN
( international format)
MSISDN SIZE / 9(2) / May be used to assist in change over to new NNGs. Number of digits in the MSISDN field.
DNO / X(2) / Donor Network Operator
in GSM International standard
ONO / X(2) / Original Network Operator
in GSM International standard
RNO / X(2) / Recipient Network Operator
in GSM International standard
Spare / rest
New line / X(1) / End of line marker, ASCII hex 0A

Trailer record

Field / Size / Description
Record Id / X(3) / Record id, value ‘TRL’
Number of records / 9(5) / Number of detail records
Date / 9(14) / Date in yyyymmddhhmmss format
Time is in 24hour format
Version Number / 9(2) / Indicates version of record for future use
Initial value = 01
Current file name / X(23) / Actual request file name
Previous file name / X(23) / Previous port request file name
New line / X(1) / end of line marker, ASCII hex 0A

2.5.2Port Response File

Header record

Field / Size / Description
Record Id / X(3) / Record id, value ‘HDR’
Spare / 9(5) / Set to 00000
Date / 9(14) / Date in yyyymmddhhmmss format
Time is in 24hour format
Version Number / 9(2) / Indicates version of record for future use
Initial value = 1
Current file name / X(23) / Actual response file name
Previous file name / X(23) / Previous response file name
New line / X(1) / end of line marker, ASCII hex 0A

Detail record

Field / Size / Description
Transaction number / X(10) / GSM International standard alphabetic
NO identifier + 8 digit number
This is the transaction number from the port request transaction.
Response date / 9(14) / Date & time of port request in
yyyymmddhhmmss format
Time is in 24hour format
Action Code / X(2) / Indicates type of request
Action Status / X(2) / Indicates result of the transaction
MSISDN / X(15) / CCITT E.164 standard for MSISDN
MSISDN SIZE / 9(2) / May be used to assist in change over to new NNGs.Action numbers of digit in MSISDN field.
DNO / X(2) / Donor Network Operator
in GSM International standard
ONO / X(2) / Original Network Operator
in GSM International standard
RNO / X(2) / Recipient Network Operator
in GSM International standard
Spare / rest
New line / X(1) / End of line marker, ASCII hex 0A

Trailer record

Field / Size / Description
Record Id / X(3) / Record id, value ‘TRL’
Number of records / 9(5) / Number of detail records
Date / 9(14) / Date in yyyymmddhhmmss format
Time is in 24hour format
Version Number / 9(2) / Indicates version of record for future use
Initial value =01
Current file name / X(23) / Actual response file name
Previous file name / X(23) / Previous response file name
New line / X(1) / end of line marker, ASCII hex 0A

2.5.3Repatriation Request File

Header record

Field / Size / Description
Record Id / X(3) / Record id, value ‘HDR’
Spare / 9(5) / set to 00000
Date / 9(14) / Date in yyyymmddhhmmss format
Time is in 24hour format
Version Number / 9(2) / Indicates version of record for future use
Initial value = 1
Current file name / X(23) / Actual file name
Previous file name / X(23) / Previous repatriation request file name
New line / X(1) / end of line marker, ASCII hex 0A

Detail record

Field / Size / Description
Transaction number / X(10) / GSM International standard alphabetic
NO identifier + 8 digit number
Unique across all request transactions
Termination date / 9(14) / Date & time of MSISDN disconnection
yyyymmddhhmmss format
Time is in 24hour format
Action Code / X(2) / Indicates type of request
Action Status / X(2) / Indicates result of the transaction
Set to FF in request files
MSISDN / X(15) / CCITT E.164 standard for MSISDN
( international format)
MSISDN SIZE / 9(2) / May be used to assist in change over to new NNGs. Action number of digits in MSISDN field
DNO / X(2) / Donor Network Operator
in GSM International standard
ONO / X(2) / Original Network Operator
in GSM International standard
Spare / rest
New line / X(1) / End of line marker, ASCII hex 0A

Trailer record

Field / Size / Description
Record Id / X(3) / Record id, value ‘TRL’
Number of records / 9(5) / Number of detail records
Date / 9(14) / Date in yyyymmddhhmmss format
Time is in 24hour format
Version Number / 9(2) / Indicates version of record for future use
Initial value = 01
Current file name / X(23) / Actual file name
Previous file name / X(23) / Previous repatriation request file name
New line / X(1) / end of line marker, ASCII hex 0A

2.5.4Repatriation Response File

Header record

Field / Size / Description
Record Id / X(3) / Record id, value ‘HDR’
Spare / 9(5) / set to 00000
Date / 9(14) / Date in yyyymmddhhmmss format
Time is in 24hour format
Version Number / 9(2) / Indicates version of record for future use
Initial value = 1
Current file name / X(23) / Actual file name
Previous file name / X(23) / Previous repatriation response file name
New line / X(1) / end of line marker, ASCII hex 0A

Detail record

Field / Size / Description
Transaction number / X(10) / GSM International standard alphabetic
NO identifier + 8 digit number
This is the transaction number from the repatriation request transaction.
Termination date / 9(14) / Date & time of MSISDN disconnection
yyyymmddhhmmss format
Time is in 24hour format
Action Code / X(2) / Indicates type of request,
Action Status / X(2) / Indicates result of the transaction
MSISDN / X(15) / CCITT E.164 standard for MSISDN
( international format)
MSISDN SIZE / 9(2) / May be used to assist in change over to new NNGs. Actual number of digits in MSISDN field.
DNO / X(2) / Donor Network Operator
in GSM International standard
ONO / X(2) / Original Network Operator
in GSM International standard
Spare / rest
New line / X(1) / End of line marker, ASCII hex 0A

Trailer record