source: mcc / stf 137 reference: mcc pd/gsm digital ... · a 3.8 mnp functionality in the t-bcsm...

Key words: Digital cellular telecommunications system, Global System for Mobile communications (GSM), MobileNumber Portability (MNP)

P-99-430

PT SMG GSM 10.66

Permanent Version: 1.0.0

Document June 1999

Source: MCC / STF 137 Reference: MCC PD/GSM

GLOBAL SYSTEM FORMOBILE COMMUNICATIONS

R

Digital cellular telecommunications system (Phase 2+);Mobile Number Portability (MNP)

Project scheduling and open issues;(GSM 10.66 Version: 1.0.0)

ETSI

European Telecommunications Standards Institute

ETSI PT SMG Secretariat

Postal address: F-06921 Sophia Antipolis CEDEX - FRANCEOffice address: 650 Route des Lucioles - Sophia Antipolis - Valbonne - FRANCE

Tel.: +33 4 92 94 42 66 - Fax: +33 4 93 65 28 17

SMG-TR (GSM 10.66 Version: 1.0.0): June 1999

Whilst every care has been taken in the preparation and publication of this document, errors in content,typographical or otherwise, may occur. If you have comments concerning its accuracy, please write to "ETSI Editingand Committee Support Dept." at the address shown on the title page.


Contents

1. FOREWORD ........................................................................................................................................................................4

2. SCOPE...................................................................................................................................................................................5

2.1 REFERENCES ...................................................................................................................................................................52.2 ABBREVIATIONS ..............................................................................................................................................................52.3 SUPPORT OF SPECIFICATION WORK ..................................................................................................................................5

3. GENERAL ............................................................................................................................................................................6

4. REQUIREMENTS ...............................................................................................................................................................6

5. FUNCTIONAL DESCRIPTION.........................................................................................................................................6

6. TECHNICAL REALISATION AND AMENDMENTS....................................................................................................6

6.1 DOCUMENTATION STRUCTURE OVERVIEW......................................................................................................................6

7. APPROVALS TIME FRAME FOR MNP .........................................................................................................................6

8. MNP SPECIFICATIONS ....................................................................................................................................................7

8.1 NEW SPECIFICATIONS ......................................................................................................................................................78.2 CHANGE REQUESTS FOR MNP.........................................................................................................................................8

9. HISTORY..................................................................................................................................................................................9

ANNEX A....................................................................................................................................................................................10

A.1. EU REGULATION IN RELATION TO NUMBER PORTABILITY...........................................................................10

A 2. MOBILE NUMBER PORTABILITY - STAGE1............................................................................................................11

A 2.1 WORK ITEM DESCRIPTION ...............................................................................................................................................11A 2.2 SERVICE DESCRIPTION OF SUPPORT OF MOBILE NUMBER PORTABILITY..........................................................................11A 2.3 CO-OPERATION WITH T1P1 ON MNP STAGE1 .................................................................................................................11A 2.4 CO-OPERATION WITH ETSI NPTF ON MNP STAGE 1 ......................................................................................................11A 2.5 STF 137 ON MOBILE NUMBER PORTABILITY ..................................................................................................................12

A 3. MOBILE NUMBER PORTABILITY – STAGE2...........................................................................................................13

A 3.1 TECHNICAL REALISATION OF MOBILE NUMBER PORTABILITY.........................................................................................13A 3.2 UK SOLUTION .................................................................................................................................................................18A 3.3 PCS 1900 SERVICE PROVIDER PORTABILITY (LOCAL NUMBER PORTABILITY) ...............................................................20A 3.4 OTHER PROPOSED SOLUTIONS.........................................................................................................................................23A 3.5 USAGE OF PREFIXES AND/OR SEPARATE PARAMETER AT SCCP, ISUP, INAP AND MAP PROTOCOLS TO CARRY OUT THE

PORTABILITY ROUTING NUMBER ...............................................................................................................................................24A 3.6 INTRODUCTION OF A NEW TT FOR MAP_SEND_ROUTEING_INFORMATION MESSAGE.....................................................24A 3.7 VALIDATION FOR MOBILE ORIGINATED SHORT MESSAGES .............................................................................................25A 3.8 MNP FUNCTIONALITY IN THE T-BCSM...........................................................................................................................25A 3.9 CO-OPERATION WITH T1.P1 ON MNP STAGE2 ................................................................................................................26A 3.10 CO-OPERATION WITH NPTF ON MNP STAGE 2 .............................................................................................................26A 3.11 SMG3 WPC COLLABORATION WITH SPS1 AND SPS3 ..................................................................................................27

A 4. MOBILE NUMBER PORTABILITY - STAGE 3...........................................................................................................27

ANNEX B LIST OF DOCUMENTS.........................................................................................................................................28


1. ForewordThis Mobile Competence Centre (MCC) Permanent Document has been produced by STF 137 (MNP) for the SMGTechnical Committee of the European Telecommunications Standards Institute (ETSI).

This MCC-PD describes the schedules of the Mobile Number Portability (MNP) standardisation process and openissues that are still under work. It also lists the necessary amendments to the GSM/DCS phase 2+ specifications forthe technical realisation of the work item.

This MCC-PD is an informative document resulting from ETSI TC-SMG studies which are not appropriate forEuropean Telecommunication Standard (ETS), Interim European Telecommunication Standard (I-ETS) or ETSITechnical Report (ETR) status.


2. ScopeThe purpose of this document is to describe the schedules of the Mobile Number Portability (MNP) standardisationprocess and open issues that are still under discussion. It also lists the new standards and necessary amendmentsto the GSM/DCS phase 2+ specifications for the technical realisation of the functionality.

The new standards and Change Requests (CR) necessary for MNP are listed in clause 8.

2.1 ReferencesThis ETS incorporates by dated and undated reference, provisions from other publications. These references arecited at the appropriate places in the text and the publications are listed hereafter. For dated references,subsequent amendments to or revisions of any of these publications apply to this ETS only when incorporated in itby amendment or revision. For undated references, the latest edition of the publication referred to applies.

[1] GSM 02.66: “Digital cellular telecommunication system; Stage 1 Service Description ofthe Support of Mobile Number Portability (MNP)”

[2] GSM 03.66: “Digital cellular telecommunication system; Stage 2 Technical Realisation ofthe Support of Mobile Number Portability (MNP)”

2.2 AbbreviationsGSM MNP abbreviations are contained within GSM 02.66 and 03.66. The MNP abbreviations used within otherGSM standards documents will be included within GSM 01.04.

2.3 Support of specification workThis document is a ‘living document’ and permanently updated by MCC. Proposals for change shall be forwarded toMCC (editor direct contact details are on the last page), where the latest version can be obtained at any time. TheMNP specification rapporteur should make sure that this document always reflects the latest status of work.

Latest versions of the material are intended to be made available to interested parties within SMG. Specification andChange Request rapporteurs should ensure the latest versions of their material is made available for review andcomment by the following mechanisms:ETSI FTP Server (docbox.etsi.fr or docbox.etsi.org):

in /Tech-Org/smg/Document/smg3/mnp/- The draft MNP specifications. (Once specifications are approved see/Tech-Org/smg/Document/smg/specs/Phase2pl/ where all current version approved specifications aremaintained)

in ../CR/- The change request to existing specifications.


3. GeneralSee Stage 1 [1] and Stage 2 [2] documents for a general description of the Mobile Number Portability.

In brief:

Mobile Number Portability (MNP) is the ability for a mobile subscriber to change GSM subscription network withinthe same country whilst retaining her original MSISDN or MSISDNs. The ported subscriber can use exactly thesame services as non-ported customers in the same subscription network.

The technical implementation of MNP shall support optimisation of the use of network and inter-network resourcesso as to minimise costs associated with transport of traffic and/or appropriate signalling and/or processing activities(e.g. optimal routing).

4. RequirementsSee in particular Stage 1 [1], and Stage 2 [2] documents for MNP requirements.

5. Functional descriptionSee Stage 1 [1] and Stage 2 [2] documents.

6. Technical realisation and amendments

6.1 Documentation Structure OverviewThe following is an overview of the principle GSM standards which together specify MNP. Section 8 following detailsthe full list of GSM standards effected.

GSM 02.66 Stage 1 Service Description of the Support of Mobile Number Portability (MNP)”

GSM 03.66 Technical realisation of the Support of Mobile Number Portability (MNP)

7. Approvals Time Frame for MNPIn October 1997 SMG#23 decided on a GSM work item “GSM number portability” (later revised to “Mobile NumberPortability or MNP)” under the main responsibility of SMG1; completion was planned for 1998.

Stage 1 service description of the Mobile Number Portability was already presented for information to SMG#23. Onthe basis of this service description SMG#23 mandated SMG3 and SMG10 to study the Mobile Number Portability.

In parallel, SMG#23 also decided on a separate GSM work item “GSM 1900 Service Provider Number Portability”for North-America under the main responsibility of T1P1 Number Portability SWG; completion was planned for1998.

In December 1997 SMG#24 approved the Release 97 version GSM 02.66 “Support of Mobile Number Portability(MNP) Service Description; Stage 1”. This Release 97 version was later superseded by the Release 98 version of“Support of Mobile Number Portability (MNP) Service Description; Stage 1”.

On the basis of consensus established within SMG12, SMG#26 approved that different solutions co-exist in theMobile Number Portability standard, even if some delegates saw a high importance and main benefits of one singlesolution for all mobile and fixed networks, as EC was reported to see the priority for a quick solution and to assignsless importance to the international mobile case and the fixed-to-mobile case.adopting the view that mainimportance to have a solution ready in time. SMG#26 asked SMG3 and SMG12 to produce a Technical Reportdescribing the restrictions and evolution potentials of both solutions. SMG#26 scheduled the core specifications ofMobile Number Portability for completion until SMG#28.


The Terms of Reference for STF EU 137 were also approved by SMG#26.

SMG12 forwarded the Technical Report to SMG3 for consideration when producing the “Technical Realisation ofSupport of Mobile Number Portability (stage2)”.

SMG#28 approved the specifications GSM 03.66 “Support of Mobile Number Portability (MNP) TechnicalRealization; Stage 2; V2.0.0, R98”. (Rapporteurs: Ulrich WIEHE, Siemens (Part 1 and 2), Ruud Op Den Camp,Libertel (Part 3 and 4)). SMG#28 agreed that GSM Mobile Number Portability (EURO) MNP is outstanding forcompletion at SMG#29.

SMG#28 approved CRs on Mobile Number Portability.

T1P1 presented for information to SMG#28 the phase I version of GSM 1900 Service Provider Number Portability;next focus is phase II version of PCS 1900 service provider number portability (pursuing to SMS and otherservices). Due to the high time pressure and the fact that the basic architecture for number portability is different inNorth America and Europe, it was not practical to seek approval by SMG and review by the STCs prior to approvingit as a ANSI standard. Nevertheless, that T1P1 and its interested members intend to include the content of theT1P1 specification into the common SMG/T1P1 GSM specifications as the work in SMG progresses.

For CRs on existing standards, at least two meetings of the appropriate SMG groups (STCs) are likely to berequired: one to examine the draft CR and suggest appropriate ways of introducing the information into thespecification, and a second to approve the revised CR. After this it can be presented directly to SMG plenary.

More details on the MNP standardisation process are found in Annex A.

8. MNP Specifications

8.1 New SpecificationsNew specifications

GSMNo.

02.66

Title:

Mobile Number Portability servicedescription

Prime resp.STC:

SMG1

2ndary resp.STC(s):

Presented forinformation at SMG#

Approved atSMG#

Comments

CurrentVersion7.0.0

Rapporteur/Company (1 or more) SMG#23 SMG#24

GSMNo.

03.66

Title:

Technical realisation of MobileNumber Portability

Prime resp.STC:

SMG3

2ndary resp.STC(s):

Presented forinformation at SMG#

Approved atSMG#

Comments

CurrentVersion7.0.0

Rapporteur/Company (1 or more)

Ulrich WIEHE (Siemens); Ruud Op Den Camp (Libertel)

SMG#28 SMG#28


8.2 Change Requests for MNPNote: The up-to-date, definitive list of approved MNP change requests can be seen by examining the current MCCCR database on the ETSI ftp server ftp://docbox.etsi.fr/Tech-Org/smg/Document/smg/plenary//report/CRxx_r.mdb or .zip. Search for changes with WORKITEM=MNP. That database is revised after every SMGmeeting, whereas this document will only be revised on an ad-hoc basis.

Note: The following list is the current set of changes that are required for MNP. The Tdoc number indicated inbrackets indicates which TC-SMG plenary document contained the change request.

Affected existing specifications

GSMNo.

Specification Title CRnumber

Subject of CR Tdoc rapporteur STC

02.66 Mobile Number Portability;Stage 1; service description

NEW New GSM specification 97-981 Peter van der Arend / ETSI SMG1

03.18 Basic call handling;Technical realization

A030 r5 Introduction of MobileNumber Portability

99-189 Ulrich Wiehe / Siemens AG SMG3

03.18 Basic call handling; Technical realization

A038 r1 Introduction of MobileNumber Portability

99-189 Franco Settimo / ETSI SMG3

09.02 MAP A175 r4 Addition of Originating IMSIto MO-ForwardSM-Arg

99-189 Peter van der Arend / ETSI SMG3

09.02 MAP A176 r1 Translation Type for MNP 99-189 Ulrich Wiehe / Siemens AG SMG3

09.02 MAP A193 r2 Mobile Number Portability 99-189 Alberto Burgaleta / Ericsson SMG3

03.66 Mobile Number Portability;Stage 2; Technical realisation

NEW New GSM specification 99-204 SMG3


9. History

Document history

April 1999 First Edition

Rapporteur: István KOCSI, ETSI / STF137

Email: [email protected] Fax:+


Annex A

A.1. EU regulation in relation to number portability

In November 1996, the European Commission (EC) organised a broad public consultation on the basis of a GreenPaper on a numbering policy for telecommunications services in Europe. This consultation underlined theimportance of equal quantitative and qualitative access to numbering resources for all market players and thecrucial significance of adequate numbering mechanisms, in particular for number portability and carrier selection, askey facilitators of consumer choice and effective competition in a liberalised telecommunications environment.

The Green Paper, published by the EC in November 1996, proposed:

• The implementation as soon as possible of number portability for the local loop and, at the latest by 2000 (i.e.allowing users in all major centres of population to keep their telephone number at a particular location whenchanging to another operator or service provider).

• The extension of number portability for users of mobile and personal communications networks as well as forusers of special services (e.g. allowing users to retain valuable numbers for freephone or personalcommunications services), taking into account the state of network development and the level of demand.

In 1997, the European Parliament and the Council adopted resolutions inviting the Commission to submit proposalsto the European Parliament and to the Council regarding the accelerated introduction of number portability andregarding the introduction of carrier preselection. Directive 97/33/EC of the European Parliament and of the Councilof 30 June 1997 on interconnection in telecommunications with regard to ensuring universal service andinteroperability through application of the principles of open network provision was amended, i.e. the firstsubparagraph of Article 12(5) was replaced by the following (Directive 98/61/EC of the European Parliament and ofthe Council of 24 September 1998 amending Directive 97/33/EC with regard to operator number portability andcarrier pre-selection):

“National regulatory authorities shall encourage the earliest possible introduction of operator number portabilitywhereby subscribers who so request can retain their number(s) on the fixed public telephone network and theintegrated services digital network (ISDN) independent of the organisation providing service, in the case ofgeographic numbers at a specific location and in the case of other than geographic numbers at any location, andshall ensure that this facility is available by 1 January 2000 at the latest or, in those countries which have beengranted an additional transition period, as soon as possible after, but no later than two years after any later dateagreed for full liberalisation of voice telephony services.”

Number Portability is defined as “The service that allows customers to change operator, while keeping the samedialable telephone number.” The goal is to provide the same quality of service to subscribers, irrespective whetherthey are ported or not. The following three types of Portability are distinguished (from “European Commission DGXIII, equal access & interconnection”):

• Operator Portability: the ability of an end-user to retain the same telephone number as he/she changes fromone operator to another. In addition, emphasis on operator portability carries the constraint of a fixed location,the assumption that the end user has not changed his/her permanent physical location or rate centre.

• Location Portability: the ability of an end user to retain the same telephone number as he/she moves from onepermanent physical location to another

• Service Portability: the ability of an end user to retain the same telephone number as he/she changes from onetype of service to another (e.g. POTS to ISDN)

Note: In addition, a fourth category exists, Service Provider portability whereby the customer should be able tochange SP, keeping the same number.


A 2. Mobile Number Portability - Stage1

A 2.1 Work Item DescriptionAs the very first step of the standardization process of Mobile Number Portability (MNP), SMG1 elaborated a WorkItem Description (WID), which was duly approved by SMG#23 (Tdoc 97-867). Most importantly, the WID foreseesonly Mobile-to-Mobile number portability (between GSM900/GSM 1800 operators). Furthermore, the WID does notconsider partial portability (whereas some services forming a GSM subscription being subject to number portabilitywhile other services of the same GSM subscription stay with the current operator).

Background information is found in:

SMG 97-328, 97-719, 97-867, np03, np11SMG1 97-316, 97-317, 97-328, 97-492

A 2.2 Service Description of Support of Mobile Number PortabilityFollowing the approval of the MNP WID by SMG #23, SMG1 was invited to prepare the GSM specification “ServiceDescription of Mobile Number Portability” (GSM 02.66). The specification was elaborated in close co-operation withT1P1 and ETSI NPTF, presented for information to SMG#23, then finally approved by SMG #24.


SMG 97-029, 97-312, 97-322, 97-420, 97-463, 97-510, 97-547, 97-650, 97-724, 97-798, 98-271, 98-315,np02, np06, np07, np08, np10, np11, np12, np20

SMG1 97-035, 97-412, 97-525, 97-527, 98-004, 98-065, 98-067, 98-068, 98-079SMG3 98P410SMG3 SA 97S163, 98S010SMG10 97-138SMG12 98S663

A 2.3 Co-operation with T1P1 on MNP stage1In the US, Local Number Portability is defined in the Telecommunications Act of 1996 as “the ability of users oftelecommunications services to retain, at the same location, existing telecommunications numbers withoutimpairment of quality, reliability, or convenience when switching from one telecommunications carrier to another.”

The US Federal Communications Commission (FCC) Number Portability Report and Order dated July 2, 1996,mandates that all Commercial Mobile Radio Service (MRS) have the ability to deliver calls from their networks toported subscriber numbers anywhere in the United States as of 31 December. 1998. The order also requires thatCMRS providers offer service provider portability, including call delivery to subscribers ported into the 100 largestMSAs (including call delivery to roamers), as of 30 June 1999. Service Portability and Location Portability are notrequired at this time. The portation of subscriber directory numbers between wireline service providers andbroadband CMRS providers or among broadband CMRS providers are considered changing service provider andnot service. Therefore, service provider portability includes wireless to wireless, wireline to wireless as well aswireline to wireline. Wireless networks required to port between themselves in Europe are all GSM technology-based, unlike US markets which must port between several air interfaces (GSM/CDMA/TDMA/Analogue) and twonetwork protocols (J-STD-023 and IS-41).

No stage 1 specification was established for the Local Number Portability.


SMG 97-278, np17SMG1 97-467

A 2.4 Co-operation with ETSI NPTF on MNP stage 1The ETSI Number Portability Task Force was set up in December 1996 by ETSI NA2 to examine the issues ofgeographic and non-geographic number portability within the Europe. SMG and ETSI NPTF co-operate in thefollowing areas:

- efficient routing of calls,- transparency of supplementary services,- information needed for accounting purposes,- common fix/mobile terminology.

The portability between mobile and fixed networks is outside the scope of current ETSI standardisation and alsooutside the scope of this co-operation.



SMG 97-314SMG1 97-245, 97-526, 98-188, 98-302, 98-608, 98-789SMG3 98P108, 98C673, 98C701SMG12 98S563

A 2.5 STF 137 on Mobile Number PortabilityThe EU study mandate 97/M-251 invites ETSI to identify the necessary modifications in the GSM standard to allowthe introduction of GSM Number Portability. Consequently, ETSI has decided to set up a Special Task Force(STF137) to identify and clarify the European regulatory requirements as well as world-wide needs, to comparesolutions currently developed, and to identify the necessary modifications of the GSM standards for the introductionof Number Portability in a harmonized way.


SMG 98-275, 98-303, 98-762


A 3. Mobile Number Portability – Stage2

A 3.1 Technical Realisation of Mobile Number PortabilitySMG#23 mandated SMG3 SA (promoted to SMG12 in March 1998) to develop the system architecture for MNPstage2. SMG12 proposed two methods of implementing MNP:

- Signalling Relay Function (SRF) based solution,- IN based solution.

Each of these methods can have variations on the basic theme and may co-exist within the same portability clusterunder certain restrictions. The decision on which method (and variation) is the most appropriate to a networkdepends on the requirements of the national environment (e.g. different national regulatory requirements). None theless, SMG12 underlined that a unified solution for the MNP requirements is strongly desirable from the operators’and manufacturers’ point of view. Moreover, a unified solution is supposed to prevent interworking problemsbetween different portability clusters of networks (i.e. interworking problems due to cross-sector transactions).

The decisions of SMG#26 were:

- to approve both IN and SRF based solutions,- to produce specifications for both solutions which include support for all GSM services,- to ask SMG3 and SMG12 to produce a Technical Report describing the restrictions (technical and

administrative merits and/or drawbacks) and evolution potentials (towards fixed/mobile (cross-sector) NPand towards UMTS of both solutions) of both methods.

Having the system architecture designed, SMG12 relayed the standardisation work on MNP stage2 and stage3 toSMG3. The Technical Realisation of MNP was approved by SMG #28.


SMG 98-298, 97-463, 97-282, 97-510, 97-648, 97-724, 98-047, 98-141, 98-427, 98-477, 98-585, 98-717,98-734, 98-746, 99-148, 99-220, np-06, np10, np11, np16, np20

SMG1 97-406, 97-422SMG3 98p211, 98P410SMG3 SA 97S163, 98S051, 98S087, 98S102, 98S172SMG3 WPC 98C647, 98C774, 98C786, 99C067, 99C071, 99C166, 99C186, 99C239, 99C240, 99C250, 99C264SMG10 97-138, 97-173SMG12 98S265, 98S326, 98S402, 98S454, 98S455, 98S456, 98S663, 98S710, 98S751, 98S805

A 3.1.1 Signalling Relay Function based solution

The detailed description of the SRF based solution for the routeing of calls as well as non-call related signallingmessages is found in GSM 03.66.


SMG3 SA 98S003, 98S006, 98S007SMG3 WPC 99C211, 99C234, 99C269, 99C280,

A 3.1.2 IN based solution

The detailed description of the IN based solution for the routeing of call related signalling messages is found inGSM 03.66. This solution is closely aligned with the approach taken within PCS1900 Number Portability. It wasagreed that for the appropriate routeing of non-call related signalling messages the SRF must be implementedaccording to the following guidelines:

Originally, there was a system architecture proposed whereby all signalling messages would cross the VMSC orGMSC. Furthermore, for interworking with fixed networks, Call Dropback solution was also evoked. During thestandardisastion process, both the system architecture was modified and the ISUP release option was rejected.


SMG 99P025SMG3 SA 98S003, 98S004SMG3 WPC 98C781, 99C069, 99C070, 99C261, 98C603,99C766,

98C770


A 3.1.3 Comparison of approved technical solutions

SMG12 produced a technical report on MNP stage2.This includes the presentation of the two different solutionsknown as IN solution and the Signaling Relay solution. It also provides the analysis of the two solutions in differentterms such as :

• Technical and administrative merit and/or drawbacks

• Evolution paths towards fixed/mobile (cross-sector) NP and towards UMTS (e.g. UMTS TS 22.75)

A 3.1.3.1 Technical and administrative merits and/or drawbacks

Merits of SRF Call-related

1. The solution completely complies to the service description requirements, including data, fax and speechnumbers, SMS, including the support of GSM Support of Optimal Routeing (SOR) and all other supplementaryservices as identified in MNP Stage 1. This is a common merit which hold for both methods.

2. The solution solves the problem at the SCCP level.3. In order to support MNP, the signalling relay solution requires two additional functional entities to handle call

related cases: The relay function which handles messages at SCCP level and the NP HLR which handlesincoming call establishment MAP messages for ported subscribers. Since there is a need for intelligence at theSCCP level for non-call related signalling e.g. SMS, the operator can re-use this (SRF) functionality for callrelated signalling and only need to add the NP HLR.

4. The solution can be built into existing equipment (HLR/STP) or can be built as stand-alone function in forexample an STP. The MNP signalling relay functionality can be distributed within a GSM HPLMN or can becentralised as required by the network operator.

5. The call handling at the GMSC is not modified by MNP and does not need additional capacity for MNP with thesignalling relay solution

6. This solution can provide optimal routing* for mobile originated calls to ported GSM subscribers, provided thatthe DB is copied to the originating network. (*) Optimal routing in this sentence means the routing from theoriginating network to the recipient network without the intervention of the donor network.


Drawbacks of SRF Call Related

1) If there is a need to optimise call routing from a fixed network to a GSM ported subscriber (i.e. to avoid to havecircuit established in the donor network), there is a need to get, in the originating network, the information aboutwhere to route the call. Several solution are currently being studied: duplication of the PLMN database in thefixed network, transfer via ISUP, interrogation of the PLMN database by the fixed network In case of option 3,there is a need to have between fixed and mobile network a real time interface imposing to chose between oneof the two solutions :

• to support MAP protocol in the originating network: in fixed networks such a requirement is astrong constrain.

• to support INAP protocol in the donor database: this represent an additional interface which maybe difficult to implement if SRF and MN HLR are integrated.

Such a constrain may prevent to use the inter-network database interrogation solution and to limit thearchitectural choice to other solutions.

2) Similarly, if the calls to a fixed ported subscriber from a GSM network are to be optimised in order to avoid tohave resources used and circuits established in the donor network, several possibilities are offered to the GSMnetwork : duplication of the fixed database in the GSM network, transfer via ISUP, interrogation of the fixednetwork database by the GSM network. As before, if the third options is chosen there is a need for the GSMnetwork to chose between one of the two solutions :

• to support INAP protocol in the GSM network.• to support MAP protocol in the fixed network database.

Such a constrain may prevent to use the inter-network database interrogation solution and to limit thearchitectural choice to other solutions.

3) With the signalling relay function the GMSC function is apparently not modified. This means that classical GSMmechanisms are used : consequently no indication is provided to the GMSC that the call is ported or not, exceptby digits analysis of routing number provided by the NP HLR. If the leg from the GMSC to the recipient networkis supposed to be charged differently from a normal re-routeing to an MSRN, extensive post processing (digitanalysis of the routing number) is to be performed on every re-routeing call record.

4 The capacity of the SRF introduced for non-call related traffic will have to be enhanced to support the additionaltraffic generated by call related traffic.

Merits of IN Call-related

1. The query on HLR-release option gives the opportunity that only the call set-up procedure for ported subscribersand that for misdialled unallocated numbers has to be touched.

2. Based on the ratio of ported and non-ported subscribers the IN solution is scaleable by choosing one of thethree options (i.e. QoD, QoR and allQuery).

3. The service of number portability is not restricted to mobile networks. If a considerable amount of outgoing trafficleaving the network considered is directed to ported subscribers within a cluster of ‘porting’ networks the networkconsidered is not member of, commercial and technical reasons will force the network considered to perform allNP services by itself concerning that kind of traffic. E.g. if there is fixed network number portability establishedand there is no cross-sector number portability, there will be nevertheless a strong need for mobile networks toperform NP services, thereby optimising routing, concerning outgoing traffic to fixed networks. An IN basedsolution for MNP will be able to use the same data base and the same interrogation procedure as fixednetworks.

4. INAP as a standardised interface between switch and SCP for interrogating the NP database guarantees theinteroperability of the nodes affected in different environments.

5. In serving an actual telecommunication service request, several identifiers are used in controlling the actualtransaction by different functionalities. Identifiers used are e.g.:- routing id, used to route the actual transaction- billing id, used to bill the subscriber, this may be not the actual user- screening id, used to screen the actual request- user id, used to identify/authenticate the actual user- juridical id, used for lawful interceptionThese identifiers may be of local (network internal) or global (network external) significance. They may be validfor the originating and/or terminating side of the actual transaction. Some or all of these identifiers may coincideor may be different. Number portability may affect some or all of these identifiers and any of the functionalitiesaddressed above may have the need to be aware of the actual porting status. IN-like solutions are more flexiblein embedding some application requests within the existing protocol.

6. For charging purposes the standard INAP procedures can be used in order to add further information to the callrecords automatically generated by the switch thus reducing complexity in the postprocessing systems.


Drawbacks of IN call related

1. The IN solution requires to have IN mechanism and IN trigger in MSC. On a short term perspective, if IN is notsupported by the MSC, this requires strong investment and development. Nevertheless support of CAMEL isbecoming a common feature in MSC: these functions require already the support of IN mechanism and INtrigger in the MSC. The additional requirement of the IN solution for MNP is to introduce new triggers. Asconsequence of this MT call handling will be impacted.

2. Invocation of an IN SSF in an MSC creates additional load on the call handling processing. Nevertheless if only alimited number of subscribers are ported, the load on the total MSC load will not be significant if QoR is used.

3. Based on implementation there might be the need to have two databases, one for call-related, one for non-callrelated signalling traffic. This might cause synchronisation problems between these two databases

4. The IN-solution requires IN for call-related traffic and for the non-call related traffic the SRF technique to meet allservice requirements whereas the SRF technique can be applied to both kinds of traffic.

SRF Non-call related

Since there is no alternate option for non-call related signalling this section will not list merits/drawbacks.

A 3.1.3.2 Evolution paths towards fixed/mobile (cross sector) NP and towards UMTS

No additional requirements for UMTS (UMTS 22.75) beyond those identified for GSM networks are currentlyidentified.

Signalling relay based solution for call related signalling

1. The SRF solution provides MNP capability at the SCCP level; this insures that all protocols built on top of SCCP(e.g. MAP) will stay working correctly. The solution is future proof: future changes in Application Parts will work.Nevertheless because the NP HLR will need to handle messages at MAP level, such NP HLR will require tosupport the same version of MAP protocol as the one supported by other entities of the network : NP HLR is notfully transparent to MAP evolution.

2. How the SRF determines that the SCCP called party address represents a ported number is implementationdependent. It will not be specified and does not preclude an IN based solution.

3. The solution can be extended to support cross-sector portability (between fixed and mobile).4. Compatibility with fixed network portability is possible; For calls originating in the fixed network, IN can be used in

the fixed network to route calls to ported MSISDNs directly to the recipient network.

Intelligent network (IN) based solution for call related signalling

1. For call related issues, the IN solution is independent on MAP evolution. Consequently IN-platform will requireany enhancement if MAP is modified.

2. The ETSI bodies SPS1, NA2, NA6 and NPTF which are working on fixed network number portability all assumean IN based solution. In adopting that approach for MNP some compatibility problems can be reduced in theperspective of fixed/mobile convergence.

3. Independently of fixed/mobile convergence, the IN solution can allow intersystem interrogation of NP databaseby any originating network to optimise call routing.

Commonalties with ISUP signalling

1. For the ISUP routing for Number portability the same procedures and methods should be used as defined inSMG3 and SPS1. internal of the mobile network it is allowed to use the methods marked as 'network option'.

For the SCCP routing for Number portability the same procedures and methods should be used as defined in SMG3and SPS1.

A 3.1.3.3 Generic Considerations with the Introduction of SRF-solution for non-callrelated signalling

The requirements on MNP for non call related signalling are :• handling of Optimal Routeing Interrogation for Mobile to Mobile SOR• handling of SMS• handling of CCBS.• others


Optimal Routeing

Optimal Routeing for Late call forwarding is not impacted by MNP and is part of release 96 of GSM Phase 2+.Optimal Routeing for Mobile to Mobile was part of release 96 but because of management problem andimplementation problem, it was decided in SMG#26 to link it with CAMEL phase 3.

Nevertheless if Optimal Routeing for mobile to mobile is to be used by a network, there is a requirement to have inthe Number Range Owner network a mechanism to route SCCP message (containing MAP send routinginformation) to the HLR based on the Called subscriber MSISDN. So independently of MNP there is a requirementto have a Signal Relay function. MNP requires to enhanced such a Signal Relay Function to be able to routemessages to the recipient network.

SMS

If SMS are only sent from the Home PLMN to its subscribers (for example for Voice Mail notification), no SMS willhave to be delivered to ported-out subscribers. Consequently in such a case only ported-in subscribers will requirenew mechanism to deliver MAP messages to the appropriate HLR. An SRF will then be necessary.

If SMS are sent from another network than the home PLMN, there is a requirement to have in the Number RangeOwner network, a mechanism to route SCCP message (containing MAP send routing information for SM) to theHLR based on the MSISDN. So independently of MNP there is a requirement to have a Signal Relay function. MNPrequires to enhanced such a Signal Relay Function to be able to route messages to the recipient network.

CCBS

CCBS is a release 97 feature. Exchange of CCBS messages between network will require routeing of SCCPmessage to the HLR based on MSISDN. Such a requirement is independent of MNP. MNP requires to enhancedsuch a Signal Relay Function to be able to route messages to the recipient network.

Conclusion

Based on the previous analysis, all the traffic impacted by MNP is SCCP traffic that already requirement an SRF.Nevertheless it should be noted that MNP requires a specific handling of each ported MSISDN whereas it may bepossible without MNP to have based on Number Range Analysis in the SRF. Capacity and complexity of SRF willbe increased because of MNP.


SMG 98-507SMG3 98P211SMG12 98S120, 98S222, 98S454, 98S455, 98S557, 98S574, 98S612, 98S613, 98S710, 98S751, 98S763,

98S805


A 3.2 UK SolutionThe specificity of the service requirement in the United Kingdom is that MNP covers subscriber numbers allocatedto GSM 900, GSM 1800, and TACS based technologies. The MNP specification deals only with MT transactionsand specifies requirements on Qualifying Networks.

The SRF principle is that the donor network forwards the routeing enquiry or other signal addressed to a portednumber to the appropriate recipient network for treatment; the SRF acts like an intelligent STP holding a databaseof ported subscribers and their respective recipient networks. The recipient network can provide the routeingnumber or other result to complete the routeing of the call or transaction. To achieve this functionality, the SRFdetermines for which directory numbers relaying is applicable, then identifies the network relaying should bedirected to, and finally modifies SCCP addressing to relay signals to the recipient network.

Gateway/TransitNode

ServiceRequest

LocationRegister

Signalling Relay Operation

Enquiry/OtherSignal

ServiceResult

RelayedsignalSRF

EnquirySignalResult

DonorNetwork

RecipientNetwork

OriginatingNetwork

Originating/GatewayNode

OtherSignalResult

ServiceResult

The effect of this solution is that the recipient network controls the routeing of the call from a gateway in the donornetwork. The result is that there is a direct routeing between the donor’s gateway and the ultimate destination of thecall. Therefore, if the called party is roaming in another network, or has set an unconditional divert to an off-netnumber, the call will be routed direct from the donor network to this destination and will not enter the recipientnetwork. In this case the recipient network is unable to raise its own CDRs relating to the call; proprietary services inthe recipient network relying on functionality in its own gateway may be compromised; the calling party may receivedonor-network announcements and announcement charges when calling ported numbers. Therefore in the UKsolution calls to ported numbers shall route through the recipient network. To achieve this a Direct RouteingOverride (DRO) function is defined, the purpose of which is to force calls to ported numbers into the recipientnetwork. DRO can be initiated by the Recipient Network or the Donor Network. DRO is only applicable to routeingenquiries for CS calls.

Recipient initiated DRO is achieved by sending an Intermediate Routeing Number (IRN) to the donor’s gatewaynode. The intermediate routeing number contains a prefix which has the effect of routeing the call into the recipientnetwork. Once in the recipient network the call undergoes a second routeing enquiry for the final stage of routeing.

Donor initiated DRO is achieved by sending an intermediate routeing number to the donor gateway node, as before,except in the donor initiated case the SRF generates the enquiry result rather than the recipient network. Once inthe recipient network, the call enters the standard routeing enquiry stage.


The signaling messages affected by MNP and their applicability to DRO:

Operation Name Protocol Applicable for DROsendRouteingInformation SRI MAP YessendRouteingInformation (OR) SRI(with OR parameters) MAP Yes1

sendRouteingInfoForSM SRI-SM MAP NosetMessageWaitingData SMWD MAP NoreportSM-DeliveryStatus Report SM Delivery Status MAP NoCcbsRequest CCBS Request CCBS ASE NoCcbsSuspension CCBS Suspension CCBS ASE NoCcbsResume CCBS Resume CCBS ASE NoCcbsCancel CCBS Cancel CCBS ASE NosendImsi Send IMSI MAP NoanyTimeInterrogation Any Time Interogation MAP No1If optimal routeing is not allowed, the DROF in the Recipient network may either return an ‘OR not allowed’ error (inwhich case the call will be routed to the donor network) or (preferably) return an IRN in the MSRN field of theacknowledgement, thus causing the call to be routed directly to the recipient network. In order to allow OR the donornetwork should relay SRIs transparently to the recipient network.

If optimal routeing is not in operation, ported calls transit the donor network. The reliability of completing mobileterminated ported calls is now dependent on the donor network as well as the recipient network. Direct routeing canbe achieved by two methods, call trap and call drop back both of which require network development. Finally, onlythe Call Trap method (the recipient network ‘traps’ calls to numbers which have been ported into the recipientnetwork and which originated in the recipient network) is mentioned in the MNP specification. Call Trap can apply toboth circuit-related calls and non-circuit related signalling.


SMG np01SMG3 SA 97S359, 98S003


A 3.3 PCS 1900 Service Provider Portability (Local Number Portability)PCS 1900 has implemented Number Portability according to the Location Routing Number method. When theinitiating MSC determines that the call is to a portable number (i.e., the called party number lies within a portablerange), it initiates a query using the Called Party Number (dialled number) to the NP database. If the subscriber hasported, the Query Response message returns an LRN to the initiating MSC. If the subscriber is not ported, theQuery response message returns the called party number (dialled number) to the initiating MSC. The LRN identifiesthe serving switch, which uses the LRN and the called party number to complete the call to the end user. The switchthat obtains the LRN (the initiating MSC) sends an indication in the forward call set-up information (Forward CallIndicator in ISUP) that the NP status of the called party number has been determined, thus inhibiting subsequentqueries at the succeeding switches/network. The call is routed using the called party number if the subscriber is notported or error/time-out occurs. For numbers ported into the PLMN, the LRN will be used to route the call to at leastone GMSC of the PLMN. It may be necessary to assign multiple LRNs to the same GMSC or same set of GMSCs.All LRNs routed to a particular GMSC shall be recognised by that GMSC. The NP database query may be madeeither in the terminating network or in a preceding network.

NP- database

query & response

ServingMSC

STP STP

MSCorLandline Switch

Call Path

Signaling Path

Other

HLR

DonorSwitch

NPAC-SMSLSMS

PSTN MSC

Initiating

.

NPAC-SMS is a Service Management System (SMS) responsible for storing and broadcasting to the Local ServiceManagement System(s) (LSMSs) NP data updates within a service providers area. The LSMS is then responsiblefor distributing the NP data updates from the NPAC-SMS to the service providers NP database (NP GTT function).

All interfaces are standardised. The interface between the MSC and PSTN supports the enhanced ANSI ISUP tocarry the following information when the number is ported:

a) The LRN in the Called Party Number parameter (CdPN)b) The called party number in the Generic Address Parameter (GAP)c) An indication in the Forward Call Indicators (FCI) bit M to indicate that a query to the NP database has

been done, thus inhibiting subsequent queries at the succeeding switches.

When a MO call or an incoming call arrives at a MSC and a NP database query has not been done, the MSC shallprogress the call in one of two ways:

- Interrogating the HLR before querying the NP databaseIf an originating call or an incoming call with called party number is received by the MSC, the MSC sendsa SRI to the HLR with the called party number. The HLR returns “unknown_subscriber” in the SRI result.The MSC interrogates via an IN dialogue the NP database with the called party number as service key.The NP database returns either the 10 digit LRN for the called party number or the actual called partynumber. The MSC analyses the results and reacts accordingly (sets-up the call using LRN, sets-up thecall with the called party number or releases the call).

- Query the NP database before interrogating the HLRIf a originating call or an incoming call with called party number is received by the MSC, the MSC detectsthe called party number is within a portable range and interrogates via an IN dialogue the NP databasewith the called party number as service key. The NP database returns either the 10 digit LRN for thecalled party number or the actual called party number. The MSC analyses the results and reacts


accordingly (sets-up the call using LRN, sets-up the call with the called party number or interrogates theHLR with a SRI message).

The above mentioned In dialogue is a generic IN service which is independent of the subscriber specific service(s)(supported via CAMEL).

The PCS 1900 Service Provider Portability addresses only the core requirements necessary for delivery of basicvoice calls. A second specification, Number Portability for PCS 1900 SMS and Other Services addressessupplementary services and Intelligent Network services impacted by number portability (Calling NamePresentation, Call Forwarding, Multi-Party, Call Barring, Calling and Connected Line Identity, Call Hold, CallWaiting). The impact of Number Portability on CAMEL, GPRS, optimal routing, and roaming is outside the scope ofthe document.

The following functional architecture is proposed by the specification:

NPAC-SMS

LSMS

NP GTT

LSMS

NP GTT

CNDB

SMSGMSCSCSC

SMSGMSC

Originating Network

Recipient Network

GMSC

Signaling

network

Visited Network

GSTP(*)

PSTN

GMSC(*)

These network entities will reside in the recipient network if the called

party is not roaming.

ng

y

Call path

Signaling path

GSTP

NPDB NPDB

SMS-IWMSC

MSC

MSC(*)

Called party

HLR

SMS-IWMSC

GMSC

GSTP


A GSTP of the originating network may perform the non-final GTT that results in the routing of non-call relatedsignalling messages to the NP GTT function. If the NP GTT function is resident on the GSTP, this non-final GTT isunnecessary.

A GSTP of the terminating network may perform the SCCP routing non-call related signalling messages to the HLR.A second NP GTT may be necessary depending on the architecture of the terminating network.

The NP GTT function is an extension to the existing SCCP that provides SCCP Global Title Translation androuteing for portable numbers. The NP GTT function translates all digits of any portable number into a 24 bit ANSIDPC of either the destination endpoint (final GTT) or some other entity capable of routing the message to thedestination endpoint (non-final GTT). A service provider is expected to perform non-final GTTs for messagesdestined for other networks. The NP GTT function may be provided by any suitable node, such as a STP or SCPand it may reside in any network (e.g., originating, donor, transit, or recipient network).

The NP GTT function may need to be performed on SCCP messages originated within the service provider’snetwork that are to be routed on a GTT basis where the GTA in the SCCP Called Party Address indicates a portablenumber. The systems originating the messages may either MTP address the messages directly to the systemperforming the NP GTT function or MTP address the messages to a system that performs a GTT and selectivelyroutes (non-final GTT) messages with an SCCP Called Party Address indicating a portable number to the systemperforming the NP GTT function. In the latter case if the GTA in the SCCP called party address contains a non-portable number, the SCCP message is default routed either to its final destination or to an intermediate STP.

Also, the NP GTT function may need to be performed on SS7 messages received from other networks that are tobe routed on a GTT basis where SCCP CdPA indicates a portable number.

The NP GTT function translates all digits in the SCCP called party address. If no translation information is found inthe NP GTT table for this destination, the NP GTT discards the SCCP message. If the portable number in theSCCP called party address is not ported, the NP GTT function default routes the message to either the finaldestination or to an intermediate STP. For the former, the address indicator in the SCCP called party addressshould indicate routing on the DPC and SSN (i.e., final translation); for the latter, the address indicate shouldindicate route on the Global Title (i.e., non-final translation). If the portable DN in the SCCP called party address isported, the NP GTT function routes the message to either the final destination or to an intermediate STP. For theformer, the address indicator in the SCCP called party address should indicate routing on the DPC and SSN (i.e.,final translation); for the latter, the address should indicate routing on the Global Title (i.e., non-final translation).

For SM MO, the SC may need to verify that the originating or terminating MSISDDN for the receive SM is legitimateMSISDN to its HPLMN.

In the NP environment, to reduce incoming traffic to the NP GTT function, a new Translation Type 14 has beenintroduced to be used in conjunction with Translation Type 10 (prior to NP, used for SCCP routeing of all MAPmessages that use the E.164 global title address). The recommended usage of the two Translation Types in NPenvironment is as follows:

• All MAP messages that are SCCP routed to a Network Entity should use TT 10.• All MAP messages that are SCCP routed to a MSISDN should use TT 14

During the standardisation of MNP, several proposals were made to re-use the LNP concept with somemodifications as follows:

- Interrogating the HLR before querying the NP database (MAP SRI) was proposed to be optional.- MT SM: the SM-SC was proposed to store the HLR address (obtained from SRI_ack) until the SM is

delivered.- CCBS: the ISUP Release was proposed to be modified to reflect routing information determined at call set-

up. This routing information would be used when requesting, suspending, resuming or cancelling CCBS andagain when the destination subscriber becomes idle, in order to set up the call. This modification of theISUP Release would remove the need to perform multiple NP database queries.

- From the PSTN or other PLMN the call is first routed to the Donor network, that must therefore store theLRN of the recipient network. Once the Donor network determines the LRN, the GMSC drops back the callto the transit network the LRN populated in the ISUP Release message. When the donor network releasesthe call back to the transit network, the transit network may release the call as far back within the networkas necessary to efficiently route the call, or may just route the call forward from the tandem serving thedonor network. If the former is allowed, then it may release all the way back to the originating network,which should also be prepared to redirect.

- The LRN could also be stored in the HLR at the donor network. In this case, GSM could standardize achange to the SRI Return Message. The reception of the SRI with a zero value for the IMSI causes thegateway MSC to release the call back to the transit network with the LRN as the redirecting number.


Alternatively, it is proposed to have the MAP operation modified to return a different parameter, onespecifically identified as the LRN for the ported number. The MSC in the donor network, when it receivedthe SRI Return with an indication that the number was ported, would have to setup the call to the transitnetwork with the LRN.


SMG 97-661, 97-1084, 99-243, np16, np18SMG1 97-389, 99-069SMG3P 97P387SMG3 SA 98S003, 98S023, 98S104, 98S118SMG3 WPC 99C235

A 3.4 Other Proposed Solutions- CFU in the HLR of the donor network

- Call Dropback. The GMSC of the donor network receiving IAM with the Parameter „RedirectionCapability“ set informs the HLR thereof in the MAP SRI request by setting the new parameter „re-direction possible“. For ported out subscribers the HLR answers the routeing information request with theError „Number Changed“ and the stored re-direction information. The GMSC then releases the call usingthe ISUP message Release with Cause ‘re-route to new destination’, including the received re-directioninformation.

- Using CAMEL. The subscriber which has changed his service provider/network operator is marked in theHLR with a CAMEL T-CSI. In the acknowledgement of the MAP SRI to the GSMC the HLR includes theCAMEL T-CSI. Thereupon, the GMSC suspended the call handling and initiates an IN dialogue to theCSE in order to obtain re-routeing information.

- Using common IN service. If the HLR receives a MAP SRI and no such subscription exists the HLR sendthe error „unknown subscriber“ to the GMSC. Thereupon the GMSC suspends the call handling andinitiates an IN -dialogue to a predefined „common“ CSE in order to obtain re-routing information. As anoption it is possible that the GMSC releases the call with the Release message with the release cause‘unallocated number’ and the interrogation of the common CSE is done by the originating MSC.


SMG1 97-198SMG3 SA 97S360


A 3.5 Usage of prefixes and/or separate parameter at SCCP, ISUP, INAP and MAPprotocols to carry out the portability Routing NumberIt is essential that any MNP related information transferred across interfaces between GSM networks supportingMNP in a given country is consistent and independent of the option chosen to support call related functions for MNPby the donor or recipient network. For example, a common structure and format of the Routing Number informationcarried in ISUP will have to be used in any one country.

Usage of Separate Parameter

- At SCCP level, it has been already agreed that prefix technique is the only suitable option for release 98due to the huge impacts that separate parameters could have.

- In ISUP IAM message, the present ISUP version does not allow the usage of Separate addressing;nevertheless, it seems that the new ISUP version will include this new feature, so it seems reasonable toinclude that facility as part of MNP - R98.

- At MAP level, if separate addressing is selected, a new parameter must be used to carry the RouteingNumber in the SRIack message. On one side this gives more flexibility and capability to this RN; on theother side, MAP versions under v3 cannot include this new parameter.

- About INAP protocol, if separate addressing method is used, it has implications similar to MAP: INAPversion shall be upgraded to allow the new parameter for the Routeing Number to be handled.

Usage of Prefixes (Concatenate addressing)

- Subscriber ported number = CC + prefix + NDC + Subscriber Number- Minimised impact at SCCP level, as far as there is no need to modify the protocols. The only impact

identified is that CdPA parameter is longer (as longer as the size of the routeing Number), and the updatingof routeing tables to be able to distinguish the destination network based in the Routeing Number used.

- At ISUP level, the only impact identified is again longer B-numbers, depending on the Routeing Numberlength, and the need to remove the prefix from the B-number in the destination network GMSC when theIAM message is received, to avoid this prefix to be analysed again by other Nodes (e.g. HLR). As far as thisremoval of the prefix can be part of the B-number analysis, the impact in GMSC is only administrative,having to include the prefixes as part of the B-number analysis trees.

- At MAP level, usage of prefixes minimise the impact in nodes, as far as all MAP versions can be supportedusing this method, being the modification transparent for the application (prefix is only included at MAP levelin SRIack message). The only drawback identified is that the MSISDN length at MAP level is restricted,having only 15 digits available to carry both Routeing Number and Subscriber Number. Anyway, at thepresent most of the PLMN's numbering plans do not make use of all these 15 digits, therefore in manycases this is not a big issue (3 digits should be enough length to carry the Routeing Numbers needed for alloperators in a country).

- About INAP, the main advantage of using prefixes is that no upgrading of INAP version is required to carrythe Routeing Number Digits.


SMG3 3P99-009SMG3 WPC 98C764, 98C765, 98C776, 98C777, 98C786, 99C066, 99C077, 99C081, 99C107, 99C109, 99C251SMG12 98S222

A 3.6 Introduction of a new TT for MAP_Send_Routeing_Information messageIn case MNP is implemented using SRF, call related and not call related signalling messages must be discriminatedfor appropriate treatment. MAP SRI messages for ported subscribers shall end up in the MATF, whereas non callrelated messages shall be routed to the appropriate HLR in the subscription network.

Discrimination of call related and non call related messages can be performed in several ways. One straightforwardsolution is to analyse signalling messages at application level using the MATF (in the donor and/or the subscriptionnetwork). This is only feasible if the dialogue is terminated. However, if the result of this analysis shows that themessage is non-call related, the dialogue is already terminated and there is no possibility to relay the SCCPmessage to the correct HLR. Instead a new dialogue has to be opened from the MATF to the HLR and the resultmessage from the HLR cannot go directly to the entity that first sent the message. This implies that the MATF isalso a MAP originating function and that the HLR closes the second dialogue by sending the result message to theMATF, which then closes the first dialogue by sending the result message to the originating entity.


Another means of discriminating signalling messages at SCCP level. During the Austin meeting, 11 to 15 January1999, it was agreed that if SCCP discrimination is used, it shall be based on a new Translation Type (TT) for MAPSRI (without the OR parameter set). However, changing the SRI TT impacts the TT handling functionality of theGMSC, which would incur additional costs for those operators introducing MNP. In addition, in case of option “MATFin the subscription network” call related messages are relayed from the number range owner network to thesubscription network. Therefore, the use of a different TT for SRI can cause interworking problems, unlessappropriate regulatory measures are taken. Finally, the use of a new TT to discriminate call related and non callrelated messages was agreed to be optional.

At the SMG3 WPC ad hoc meeting on MNP in Madrid, 14 - 16 December 1998, a request was made to SPS1representatives to have a TT value standardised in SCCP. In its response, SPS1 proposed to allocate TT value 128(This is the first TT value in the range of ‘reserved for ETSI allocation’.)


SMG3 WPC 98C655, 98C656, 98C771, 98C778, 98C784, 99094, 99C106, 99C160

A 3.7 Validation for Mobile Originated Short MessagesThis functionality is an add-on feature which is neither required by the MNP stage 1 specification nor any SMSspecification.Many PLMN operators have a requirement to validate that a mobile subscriber is allowed to use their ShortMessage Service Centres (SMSCs). Currently this is usually done by checking the MSISDN (in the Forward ShortMessage) belongs to the number space served by the operator. With the advent of mobile number portability, theMSISDN will not be sufficient without the SMSC somehow looking up whether the MSISDN is a subscriber to theoperator’s network.

Although it would be possible for the SMSC to look-up the validity of the MSISDN, all possible methods will entailunnecessary performance overheads and unnecessary complexity to the network and/or managementinfrastructure. Possible methods include

• Maintenance of a table of valid and/or invalid subscribers in the SMSC. Unless an operator wishes to maintaina subscription list for outgoing short messages, not only does this add a performance overhead on the SMSC, itadds an additional provisioning requirement with a significant impact to operations and support systems.

• Query of a number portability database by the SMSC. This places a performance overhead on the SMSC and,of course, the database.

• It would also be possible for the SMSC to query the operator’s HLR, implied by the MSISDN (taking account ofpossible in-porting and avoiding any signalling relay function), e.g. with a pseudo SRI operation. If the replywere not rejected, then the subscriber would belong to that network. Again this would have performanceoverheads, not only on the SMSC but, more important, on the HLRs and on the SS7 signalling network.

As IMSIs are not portable, if the IMSI is available to the SMSC for mobile originated messages, that can be used forvalidation. Therefore the Forward Short Message MAP operation has been enhanced to carry the IMSI of theoriginating mobile.


SMG3 WPC 98C680SMG12 98S265

A 3.8 MNP functionality in the T-BCSMPlacing the MNP functionality to the terminating BCSM serves to avoid interworking problems with services usingexisting IN protocols in the Originating BCSM (which B-Party number is to be used). The need for starting this newtype of T-BCSM could be detected in e.g. the originating side number analysis or it could be based on call origin.The concept was rejected.


SMG3 WPC 98C768, 98C769, 98C770


A 3.9 Co-operation with T1.P1 on MNP Stage2The FCC did not mandate a specific method for number portability but supports the decision of the industry toimplement the Location Routing Number (LRN) method. The US Federal Communications Commission (FCC) hasassigned responsibility to its advisory boy, the North American Numbering Council (NANC), for regional numberportability databases and their content and administration. It has also mandated the creation of 7 Number PortabilityAdministration Centers and Service Management Systems (NPAC-SMSs) to develop and maintain numberportability databases for use by all carriers on impartial basis. Information format and exchange procedures,synchronisation of service activation, and conflict resolution are all regulated by the FCC as referred in the NorthAmerican Numbering Council Functional Requirement Specification.

The North American solution impacts ISUP signalling to accomplish network interoperability, as mandated by theFederal Communications Commission (FCC). Additionally, PCS 1900 Service Provider Number Portability utilisesthe IN/1 query.

ANSI has not developed Stage 1 specification. Instead, ANSI Standards “PCS 1900 Number Portability.” (includingStage 2 definitions for the NP trigger, the query and response messages, and the network element interfaces) and“Number Portability for PCS 1900 Short Message Service (SMS) and Other Services.” were produced.


SMG 97-314, 97-484, 97-661, 97-1084, 98-221, 98-459, 98-572, 99-221, 99-243, np09, np13SMG1 97-227, 97-389, 97-390, 99-069SMG3 97P386, 97P387SMG3 WPC 99C235

A 3.10 Co-operation with NPTF on MNP Stage 2Areas for co-operation:

- Efficient routing of calls,- Transparency of supplementary services,- Information needed for accounting purposes,- Common terminology.

At its meeting in Turin, 3-5 December 1997, the NA Number Portability Task Force (NPTF) decided to start a workpackage titled “fixed-mobile calls in the context of number portability”. The aim of this work package is to look at theconsequences of and possible solutions for the effects of number portability in mobile networks on fixed networks.Topics that the NPTF wants to study are related handling of calls to ported, mobile numbers in fixed networks, butalso include handling of circuit-unrelated signalling in fixed networks if ported, mobile numbers are involved.

There are basically four methods discussed within ETSI SPS/NA/NPTF and ITU-T for Number Portability. Theseare as follows• All call Query (AcQ)• Onward Routing (OR)• Query on Release (QoR)• Call Dropback (CDB)

The solutions “Query on Release” and “Call Dropback are not compatible with the MNP solutions.

There are also alternatives for how to transfer the routing information in ISUP:• Separete directory addressing. This method puts the Routing number in the existing Called Party Number

(CdPN) in ISUP IAM message and the Directory Number (comparable with MSISDN) in a new Called DirectoryNumber parameter (CDN).

• Concatenated addressing method. This method concatenates the Routing number and the Directory numberinto the existing Called party number parameter in ISUP IAM.

• Separate network routing addressing method. This method puts the Directory number into the existing CalledParty Number (CdPN) in ISUP IAM and the Network routing number in a new Network Routing Numberparameter (NRN).


SMG np04SMG1 97-526, 98-188, 98-302, 98-321, 98-608, 98-789SMG3 98108, 98C673, 98C686, 98C701SMG12 98S260, 98S261, 98S271, 98S563


A 3.11 SMG3 WPC Collaboration with SPS1 and SPS3SMG3 WPC collaborated with SPS1 and SPS3 on the technical solutions and terminology for Number Portability,including signalling relay level and ISUP/INAP signalling capability issues.

At the SMG3 WPC ad hoc meeting on Mobile Number Portability (MNP) in Madrid, 14 - 16 December 1998, theprinciple was agreed to support in the MAP protocol the full set of ISUP options for NP support. The MAPenhancements are needed to interwork with the ISUP codings as defined in draft ITU-T recommendation Q.npwhich was endorsed as EN and approved for public enquiry.

Since ITU-T and SPS3 are following the same approach with the INAP enhancements for NP support, it was agreedto align the MAP enhancements for MNP with those for INAP. This ensures that national agreements for ISUP canbe met and contributes to possible solutions for Fixed Mobile Convergence.


SMG3 99P009SMG3 WPC 98C765, 98C776, 98C777, 99C106, 99C107, 99C108, 99C251

A 4. Mobile Number Portability - Stage 3The following items were identified as candidates for the Stage 3 specification of MNP:

• The Protocol used for IN query e.g. INAP, CAP etc.

• The structure and format of the Routing Number information carried in ISUP e.g. a prefix + MSISDN or arouting number parameter or other NPTF proposal etc.

• The value of, for example, the Translation Type fields in use in SCCP e.g. for message carrying the SRIoperation (see section 6.2).

• Compatibility and interworking of MNP related enhancements with existing network signalling systems e.g.ISUP, SCCP.


Annex B List of Documents

Tdoc Subject By Sta- Venue Date

SMG 97-029 Number Portability for Users of Mobile and Personal Communication Networks Mannesmann N Paris 97 02SMG 97-278 Work Item description for Local Number Portability (NA) T1.P1 A Paris 97 02SMG 97-282 Number Portability – Collaboration with T1P1 SMG ad hoc on MNP N Paris 97 02SMG 97-312 SMG1 Status Report to SMG#22 SMG1 N Kristiansand 97 06SMG 97-314 Number Portability (complements SMG 97-322) NPTF N Kristiansand 97 06SMG 97-322 Number Portability within GSM (900 and 1800 MHz) SMG Chairman N Kristiansand 97 06SMG 97-328 Proposed Work Item description for Number Portability KPN R Kristiansand 97 06SMG 97-420 Number Portability within GSM Networks GSM MoU N Kristiansand 97 06SMG 97-463 Number Portability SMG ad hoc on MNP N Kristiansand 97 06SMG 97-484 LS Work plan for Local Number Portability T1.P1 N Kristiansand 97 06SMG 97-510 Status of Number Portability in the Netherlands Libertel N Kristiansand 97 06SMG 97-547 Number Portability SMG ad hoc on MNP N Kristiansand 97 06SMG 97-648 GSM Standardization Issues Relating to Number Portability (SERG Doc 80/97) BellSouth NZ N Budapest 97 10SMG 97-650 SMG1 Status Report to SMG#23 SMG1 N Budapest 97 10SMG 97-661 PCS (GSM) 1900 Service Provider Number Portability - ANSI T1P1.5/97-133R4:

08/97T1P1 N Budapest 97 10

SMG 97-719 Proposed Work Item Description for GSM Number Portability KPN R Budapest 97 10SMG 97-724 Report of the Workshop on GSM Number Portability Amsterdam, July 1997 SMG ad hoc on MNP N Budapest 97 10SMG 97-798 Comments on Stage 1 of Number Portability France Telecom N Budapest 97 10SMG 97-867 Work Item description on GSM Number Portability Mannesmann, KPN,

T-Mobil, Libertel,Vodafone

A Budapest 97 10

SMG 97-1084 Revised Work Plan for 1900 Service Provider Number Portability;PCS (GSM) 1900 Service Provider Number Portability - ANSI T1P1.5/97-133R7:11/97

T1.P1 N Madrid 97 12

SMG 98-047 SMG's Results from April 1996 to April 1998 SMG Chairman N Sophia 98 03SMG 98-141 SMG3 Status Report to SMG#25 SMG3 N Sophia 98 03SMG 98-221 T1P1.5 Report to SMG # 25 T1P1.5 N Sophia 98 03SMG 98-271 From SMG#25 to SMG#26 – Chairman's report SMG Chairman N Helsinki 98 06SMG 98-275 Terms of Reference for STF EU (NP) and STF 80V (GPRS) SMG Chairman N Helsinki 98 06SMG 98-298 LS The Rationale for the Multiplicity of the MNP Solutions SMG12 A Helsinki 98 06


SMG 98-303 Proposed Terms of Reference for STF EU (GSM NP); Change request for STF 80VTerms of Reference (GPRS)

PT SMG A Helsinki 98 06

SMG 98-315 SMG1 Status Report to SMG#26 SMG1 N Helsinki 98 06SMG 98-427 SMG3 Status Report to SMG#26 SMG3 N Helsinki 98 06SMG 98-459 T1P1.5 Status Report to SMG#26 T1.P1 N Helsinki 98 06SMG 98-477 SMG12 Status Report to SMG#26 SMG12 N Helsinki 98 06SMG 98-507 Scope statement for proposed report on MNP to be elaborated by SMG12 SMG12 A Helsinki 98 06SMG 98-572 T1P1.5 Status Report to SMG #27 T1.P1 N Prague 98 10SMG 98-585 SMG3 Status Report to SMG#27 SMG3 N Prague 98 10SMG 98-717 SMG3 Status Report to SMG#27 SMG3 N Prague 98 10SMG 98-734 SMG12 Status Report to SMG#27 SMG12 N Prague 98 10SMG 98-746 PT SMG status report PT SMG N Prague 98 10SMG 98-762 Call for Experts for STF12 (GSM), 83 (UMTS) and for STF EU (Study and

investigation of the introduction of NP in the GSM family) – CL 1899STF 12 A Prague 98 10

SMG 99-148 SMG3 Status Report to SMG#28 SMG3 N Milan 99 02SMG 99-220 SMG3 Status Report to SMG#28 SMG3 N Milan 99 02SMG 99-221 T1P1.5 Status report to SMG#28 T1.P1 N Milan 99 02SMG 99-243 Number Portability for PCS 1900 Short Message Service and other Services T1.P1 Chairman N Milan 99 02SMG-NP 01 UK solution for Mobile Number Portability UK PNO-IG

& MNP-TGN Amsterdam 97 07

SMG-NP 02 Support of Number Portability; Service Description; Stage 1 v0.0.1 (SMG1 97-332) KPN N Amsterdam 97 07SMG-NP 03 Proposed Work Item description for Number Portability (SMG 97-328) KPN N Amsterdam 97 07SMG-NP 04 Draft deliverables of ETSI NA task force on fixed network Number Portability (NA) NPTF N Amsterdam 97 07SMG-NP 06 Letter from the Dutch minister responsible for telecommunications on NP N Amsterdam 97 07SMG-NP 07 Number Portability within GSM (SMG 97-322) SMG Chairman Amsterdam 97 07SMG-NP 08 Number Portability (SMG 97-547) SMG ad hoc on MNP N Amsterdam 97 07SMG-NP 09 Workplan for Number Portability (SMG 97-484) T1.P1 N Amsterdam 97 07SMG-NP 10 Number Portability (SMG 97-463) SMG ad hoc on MNP N Amsterdam 97 07SMG-NP 11 Status of Number Portability in The Netherlands (SMG 97-510) Libertel N Amsterdam 97 07SMG-NP 12 Number Portability within GSM Networks (SMG 97-420) GSM MoU N Amsterdam 97 07SMG-NP 13 Proposed Work Item description sheet of Local Number Portability (SMG 97-278) T1.P1 N Amsterdam 97 07SMG-NP 16 Support of Local Number Portability by GSM Nortel N Amsterdam 97 07SMG-NP 17 North American Number Portability – Overview T1.P1 N Amsterdam 97 07SMG-NP 18 North American Local Number Portability T1.P1 N Amsterdam 97 07SMG-NP 20 Report of the workshop on GSM Number Portability, Schiphol 1997 07 PT SMG N Amsterdam 97 07SMG1 97-035 NP for Users of Mobile and Personal Communication Networks (SMG 97-029) Mannesmann A Madrid 97 01SMG1 97-198 Number Portability – Proposed Technical Solutions Siemens N Göteborg 97 06SMG1 97-227 LS Work Plan for Number Portability (SMG 97-484) T1.P1 N Göteborg 97 06SMG1 97-245 Notes from the 4th Number Portability Task Force (NPTF) meeting SMG1/NPTF N Göteborg 97 06

SMG-TR (GSM 10.66 Version: 1.0.0): June 1999SMG1 97-316 Number Portability in Mobile Networks KPN N Göteborg 97 06SMG1 97 317 Proposed Work Item description for MNP KPN N Göteborg 97 06SMG1 97-328 Proposed Work Item description for Number Portability (SMG NP 03) KPN N Göteborg 97 06SMG1 97 389 PCS 1900 Service Provider Number Portability (SMG 97-661) T1.P1 N Dresden 97 11SMG1 97-390 Service Provider Number Portability for PCS 1900 (SMG3 97p386) T1.P1 N Dresden 97 11SMG1 97-406 Number Portability to Services in the GSM Family Australian Comm.

AuthorityN Dresden 97 11

SMG1 97-412 LS Number portability and Fraud Potential SMG10 N Dresden 97 11SMG1 97-422 GSM Standardization Issues Relating to Number Portability (SMG 97-648) BellSouth NZ N Dresden 97 11SMG1 97 467 T1P1.5 NP SWG Comments on: “Proposed Service Description (Stage 1) for NP T1.P1 N Dresden 97 11SMG1 97-492 Work Item Description for GSM Number Portability Mannesmann A Dresden 97 11SMG1 97-525 LS to SMG6 and MoU SERG Admin. Porting Process for MNP SMG1 A Dresden 97 11SMG1 97-526 LS to SMG3 and NPTF MNP (Info for Accounting, Transparency of SS, Routing of

calls)SMG1 A Dresden 97 11

SMG1 97-527 LS to MoU-BARG and Mou-CAGE2+ Charging aspects of MNP SMG1I A Dresden 97 11SMG1 98-004 Report to SMG1 from SMG#24 SMG1 N Sophia 98 01SMG1 98-065 MNP - Some Key requirements Mannesmann N Sophia 98 01SMG1 98-067 GSM MNP; AoC Interworking Mannesmann R Sophia 98 01SMG1 98-068 Report from SERG#29 SERG#29 N Sophia 98 01SMG1 98-079 Clarification of MNP requirements BT, Cellnet N Sophia 98 01SMG1 98-188 LS ETSI Fixed/Mobile Number Portability Terminology Differences (SMG3 98P108) NPTF N Dublin 98 02SMG1 98-302 LS to NPTF ETSI Fixed/Mobile Number Portability Terminology Differences SMG1 A Dublin 98 02SMG1 98-321 LS from NPTF to SMG3 and SMG1 on “Fixed-mobile calls in the context of NP” NPTF N Dublin 98 02SMG1 98-608 Fixed/Mobile Number Portability Terminology Differences NPTF N Rome 98 04SMG1 98-789 LS to SMG12, SMG3 and SMG3 WPC on NP Terminology SMG1 A Rome 98 04SMG1 99-069 Wireless Number Portability for PCS 1900 SMS and other Services (SMG 99-243) T1P1 N Edinburgh 99 01SMG3 97P386 Service Provider Number Portability for PCS 1900 (SMG1 97-390) T1P1 N Malmö 97 09SMG3 97P387 PCS (GSM) 1900 Service Provider Number Portability (SMG 97-661) T1P1 N Malmö 97 09SMG3 97P410 Report of the Workshop on GSM Number Portability Amsterdam, July 1997 (SMG

97-724)SMG ad hoc on MNP N Malmö 97 09

SMG3 98P108 LS ETSI Fixed/Mobile Number Portability Terminology Differences (SMG1 98-188) NPTF N Chester 98 06SMG3 98P211 Outcome of working session on MNP report requested by SMG#26 SMG ad hoc on MNP A Bonn 98 09SMG3 3P99-009 LS from SPS1 on Looking for collaboration between SMG and SPS1 on Number

PortabilitySPS1 N Sophia 99 01

SMG3 3P99-025 CRs to GSM 09.02 on MNP SMG3 WPC,Ericsson

A Sophia 99 01

SMG3C 98c647 Report of SMG3 ad hoc meeting on MNP in Turin, October 1998 SMG3 ad hoc N Hungerford 98 11SMG3C 98C655 MNP – SRF solution for call-related. Handling if SRI TT is not changed Ericsson Hungerford 98 11SMG3C 98c656 MNP – SRF solution for non-call-related messaging. Handling if SRI TT is not Ericsson Hungerford 98 11


changedSMG3C 98c673 Definitions for NP/MNP from NPTF and SMG1 Alcatel Hungerford 98 11SMG3C 98c680 Number Portability and Validation for Mobile Originated Short Messages Aldiscon Hungerford 98 11SMG3C 98c686 Message Sequence Charts for NP methods Ericsson Hungerford 98 11SMG3C 98c701 LS to SMG1 Definitions for MNP in GSM 02.66 Logica Aldiscon A Hungerford 98 11SMG3C 98c763 Report of the SMG3-WPC plenary meeting Hungerford, November 1998 PT SMG N Madrid 98 12SMG3C 98c764 Draft EN for ISUP Enhancements for Number Portability N Madrid 98 12SMG3C 98c765 LS Looking for collaboration on Number Portability (SMG3 98P-009) SPS1 N Madrid 98 12SMG3C 98c766 CR A027r2-03.18 Introduction of Mobile Number Portability Siemens D Madrid 98 12SMG3C 98c768 MNP BCSM NOKIA R Madrid 98 12SMG3C 98c769 Changes to MNP IN Call-relate; Technical Realization; stage2 (Tdoc 98c767) NOKIA R Madrid 98 12SMG3C 98c770 CR A036 to GSM 03.18 on Mobile Number Portability NOKIA R Madrid 98 12SMG3C 98c771 SRF Based Solution Functionality SMG3 MNP ad hoc Madrid 98 12SMG3C 98c774 Proposal to change the Acronym SRF Logica Aldiscon A Madrid 98 12SMG3C 98c776 Draft TR “Non-circuit related signaling functionality for Number Portability” SPS Chairman N Madrid 98 12SMG3C 98c777 Draft EN with the ISUP enhancements for Number Portability SPS1 Chairman N Madrid 98 12SMG3C 98c778 Clarification of the SRF solution without SRI TT modification. Ericsson Madrid 98 12SMG3C 98c781 Proposed change to procedure mobile_number_portability_AcQ regarding Number

range conditionTelia Mobile R Madrid 98 12

SMG3C 98c784 Proposed text for GSM 03.66 recommendation Ericsson Madrid 98 12SMG3C 98c786 Final meeting report from Madrid meeting ad hoc on MNP, 14 -16 December 1998 SMG3 WPC

MNP ad hocN Austin 99 01

SMG3C 3c99-066 INAP support for Number Portability Ericsson Austin 99 01SMG3C 3c99-067 Proposed modifications to IN Call Related stage 2 specification Ericsson Austin 99 01SMG3C 3c99-069 Proposed proceed option in procedure MNP_OQoD in GSM 03.66A v0.3.0 Telia R Austin 99 01SMG3C 3c99-070 CR A037 to GSM 03.18 Proposed proceed option in procedure MNP_OQoD Telia R Austin 99 01SMG3C 3c99-071 Standardized interface between MNP-SRF and NPDB with IN call related Telia N Austin 99 01SMG3C 3c99-077 Proposal to avoid subsequent NPDB dips for non-ported numbers Ericsson N Austin 99 01SMG3C 3c99-081 Usage of prefixes and/or separate parameter at SCCP, ISUP, INAP and MAP

protocols to carry the portability Routing NumberEricsson N Austin 99 01

SMG3C 3c99-094 MNP- SRF call and non call related cases - Addressing and routing issues Alcatel Austin 99 01SMG3C 3c99-106 SMG3 WPC request for allocation of a TT value for MNP SPS1 Chairman N Austin 99 01SMG3C 3c99-107 Alignment of MAP enhancements for MNP with INAP CS3 enhancements for NP SPS1 Chairman N Austin 99 01SMG3C 3c99-108 Draft TR “Non-circuit related signaling functionality for Number Portability” SPS1 N Austin 99 01SMG3C 3c99-109 Analysis of MNP solutions with fixed NP for Fixed Mobile Convergence reasons KPN Austin 99 01SMG3C 3c99-160 Implications on not having a new Translation Type for MNP Siemens Austin 99 01SMG3C 3c99-166 CR A176r1 to GSM 09.02 Translation Type for MNP Siemens A Austin 99 01SMG3C 3c99-186 CR A175r4 to GSM 09.02 “Addition of Originating IMSI to MO-ForwardSM-Arg” Logica Aldiscon A Austin 99 01SMG3C 3c99-203 Meeting report from Austin, 11 to 15 January 1999 N Austin 99 01SMG3C 3c99-211 CR A178r1 to GSM 09.02 on Mobile Number Portability R Sophia 99 01

SMG-TR (GSM 10.66 Version: 1.0.0): June 1999SMG3C 3c99-234 CR to GSM 03.66/4 on Introduction of Mobile Number Portability Ericsson A Sophia 99 01SMG3C 3c99-235 Wireless Number Portability for PCS 1900 SMS and other Services Logica Aldicson N Sophia 99 01SMG3C 3c99-239 Same interface between MNP-SRF and NPDB as between GMSC and NPDB in the

IN-alternativeTelia, KPN N Sophia 99-01

SMG3C 3c99-240 MNP specific cause value in abnormal situations Telia R Sophia 99 01SMG3C 3c99-250 SCCP hop counter and ETSI reference for SCCP standards SPS1 Chairman N Sophia 99 01SMG3C 3c99-251 Submission of MNP deliverables to next ITU-T SG 11 meeting SPS1 Chairman N Sophia 99 01SMG3C 3c99-261 CR A030r5 to GSM 03.18 Siemens A Sophia 99 01SMG3C 3c99-264 Proposed Section 1 for 03.66 part 4 Logica Aldicson A Sophia 99 01SMG3C 3c99-269 CR A038r1 to GSM 03.18 Ericsson A Sophia 99 01SMG3C 3c99-280 CR A193r2 to GSM 09.02 Ericsson A Sophia 99 01SMG3-97S163 Number Portability (SMG 97-463) SMG ad-hoc on MNP N Sophia 97-06SMG3-97S359 UK Mobile Number Portability v9 MNP ad hoc N Stockholm 97 11SMG3-97S360 Number Portability (SMG1 97-198) Siemens N Stockholm 97 11SMG3 98S003 Concepts for Supporting Mobile Number Portability Siemens Malmö 98 01SMG3 98S004 Signalling Scenarios for MNP Siemens Malmö 98 01SMG3 98S006 Mobile Number Portability v 1.1 KPN/Libertel N Malmö 98 01SMG3 98S007 Mobile Number Portability KPN/Libertel Malmö 98 01SMG3 98S010 GSM Mobile Number Portability - Some Key Requirements Mannesmann N Malmö 98 01SMG3 98S023 Mobile Number Portability Nortel N Malmö 98 01SMG3 98S051 MNP – Conclusion on the two proposed solutions KPN/Libertel N Malmö 98 01SMG3 98S087 LS CCBS - Mobile Number Portability (MNP) interaction SMG3-WPB N Munich 98 03SMG3 98S102 Mobile Number Portability – Proposed solution Telia N Munich 98 03SMG3 98S104 Local Number Portability Proposal for GSM Lucent Technologies N Munich 98 03SMG3 98S106 New Concept for Supporting Mobile Number Portability Siemens N Munich 98 03SMG3 98S118 Mobile Number Portability – Proposed solution Nortel N Munich 98 03SMG3 98S120 Analysis of proposed Mobile Number Portability Solutions BT, Cellnet, Libertel,

KPN, One2One,Orange PCS,Vodafone

N Munich 98 03

SMG3 98S172 Promotion of SMG3/SA to SMG12, as an STC in charge of System Architecture SMG 12 Chairman A Munich 98 03SMG10 97-138 Number Portability (SMG 97-463) SMG ad hoc on MNP N Torino 97 09SMG10 97-173 LS to SMG, SMG1 on Number Portability (SMG1 97-412) SMG 10 A Torino 97 09SMG12 98S222 Considerations on MNP T-Mobil N Lisbon 98 04SMG12 98S260 LS Work item in NPTF on fixed-mobile calls in the context of Number Portability to

NA Number Portability Task Force on NP for fixed-mobile calls.NPTF N Lisbon 98 04

SMG12 98S261 LS “Scenarios for interworking between fixed and mobile networks for calls fromfixed networks to ported, mobile numbers”

NPTF N Lisbon 98 04

SMG12 98S265 Mobile Number Portability – Conclusion on the two solutions Cellnet, One2one,KPN

N Lisbon 98 04


SMG12 98S271 LS to NPTF on interworking between fixed and mobile networks SMG12 A Lisbon 98 04SMG12 98S326 Report of the SMG12 ad hoc on MNP in Paris SMG12 MNP ad hoc N Chicago 98 06SMG12 98S402 Revised Report of the SMG12 ad hoc on MNP Swindon SMG12 MNP ad hoc N Chicago 98 06SMG12 98S454 LS to SMG#26 on solution of the support of MNP SMG12 A Chicago 98 06SMG12 98S455 Solutions for supporting MNP (revision 1) SMG12 A Chicago 98 06SMG12 98S456 LS to SMG#26 on the rationale for the multiplicity of the MNP solutions SMG12 A Chicago 98 06SMG12 98S557 MNP Report Proposal KPN, Cellnet, Orange N Sophia 98 08SMG12 98S563 LS on ETSI Fixed/Mobile Number Portability Terminology Differences NPTF N Sophia 98 08SMG12 98S574 Scope statement for proposed report on MNP (SMG 98-507) SMG#26 N Sophia 98 08SMG12 98S612 Proposal for a structure of the MNP report France Telecom,

Mannesmann, T-Mobil

N Sophia 98 08

SMG12 98S613 Proposal for IN based solution of the MNP report required by SMG#26 France Telecom,Mannesmann, T-Mobil

N Sophia 98 08

SMG12 98S663 Draft Proposed LS to SMG1 and SMG10, CC to SMG2 on the lack of a UMTS RoleModel

Vodafone N Sophia 98 08

SMG12 98S710 Proposed Draft MNP report requested by SMG stage 2 Cellnet N Rome 98 09SMG12 98S751 Comments on Tdoc SMG12 98S710 France Telecom N Rome 98 09SMG12 98S763 Comments on Tdoc SMG12 98S710 Alcatel N Rome 98 09SMG12 98S805 Outcome of working session on MNP report requested by SMG#26 MNP ad hoc N Rome 98 09ITU 9811_067 Proposal for an additional annex in Q.np for non-circuit related signalling N Sophia 99 01ITU 9811_071 Proposal for “ISUP enhancements to support NP CS1 N Sophia 99 01