Permanent Version: Document June 1999

Transcription

1 PT SMG GSM Permanent Version: Document June 1999 P Source: MCC / STF 137 Reference: MCC PD/GSM Key words: Digital cellular telecommunications system, Global System for Mobile communications (GSM), Mobile Number Portability (MNP) GLOBAL SYSTEM FOR MOBILE COMMUNICATIONS R Digital cellular telecommunications system (Phase 2+); Mobile Number Portability (MNP) Project scheduling and open issues; (GSM Version: 1.0.0) ETSI European Telecommunications Standards Institute ETSI PT SMG Secretariat Postal address: F Sophia Antipolis CEDEX - FRANCE Office address: 650 Route des Lucioles - Sophia Antipolis - Valbonne - FRANCE Tel.: Fax:

2 Page 2 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 Editing and Committee Support Dept." at the address shown on the title page.

3 Page 3 Contents 1. FOREWORD SCOPE REFERENCES ABBREVIATIONS SUPPORT OF SPECIFICATION WORK GENERAL REQUIREMENTS FUNCTIONAL DESCRIPTION TECHNICAL REALISATION AND AMENDMENTS DOCUMENTATION STRUCTURE OVERVIEW APPROVALS TIME FRAME FOR MNP MNP SPECIFICATIONS NEW SPECIFICATIONS CHANGE REQUESTS FOR MNP HISTORY...9 ANNEX A...10 A.1. EU REGULATION IN RELATION TO NUMBER PORTABILITY...10 A 2. MOBILE NUMBER PORTABILITY - STAGE A 2.1 WORK ITEM DESCRIPTION...11 A 2.2 SERVICE DESCRIPTION OF SUPPORT OF MOBILE NUMBER PORTABILITY...11 A 2.3 CO-OPERATION WITH T1P1 ON MNP STAGE A 2.4 CO-OPERATION WITH ETSI NPTF ON MNP STAGE A 2.5 STF 137 ON MOBILE NUMBER PORTABILITY...12 A 3. MOBILE NUMBER PORTABILITY STAGE A 3.1 TECHNICAL REALISATION OF MOBILE NUMBER PORTABILITY...13 A 3.2 UK SOLUTION...18 A 3.3 PCS 1900 SERVICE PROVIDER PORTABILITY (LOCAL NUMBER PORTABILITY)...20 A 3.4 OTHER PROPOSED SOLUTIONS...23 A 3.5 USAGE OF PREFIXES AND/OR SEPARATE PARAMETER AT SCCP, ISUP, INAP AND MAP PROTOCOLS TO CARRY OUT THE PORTABILITY ROUTING NUMBER...24 A 3.6 INTRODUCTION OF A NEW TT FOR MAP_SEND_ROUTEING_INFORMATION MESSAGE...24 A 3.7 VALIDATION FOR MOBILE ORIGINATED SHORT MESSAGES...25 A 3.8 MNP FUNCTIONALITY IN THE T-BCSM...25 A 3.9 CO-OPERATION WITH T1.P1 ON MNP STAGE A 3.10 CO-OPERATION WITH NPTF ON MNP STAGE A 3.11 SMG3 WPC COLLABORATION WITH SPS1 AND SPS A 4. MOBILE NUMBER PORTABILITY - STAGE ANNEX B LIST OF DOCUMENTS...28

4 Page 4 1. Foreword This Mobile Competence Centre (MCC) Permanent Document has been produced by STF 137 (MNP) for the SMG Technical Committee of the European Telecommunications Standards Institute (ETSI). This MCC-PD describes the schedules of the Mobile Number Portability (MNP) standardisation process and open issues that are still under work. It also lists the necessary amendments to the GSM/DCS phase 2+ specifications for the technical realisation of the work item. This MCC-PD is an informative document resulting from ETSI TC-SMG studies which are not appropriate for European Telecommunication Standard (ETS), Interim European Telecommunication Standard (I-ETS) or ETSI Technical Report (ETR) status.

5 Page 5 2. Scope The purpose of this document is to describe the schedules of the Mobile Number Portability (MNP) standardisation process and open issues that are still under discussion. It also lists the new standards and necessary amendments to 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 References This ETS incorporates by dated and undated reference, provisions from other publications. These references are cited 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 it by 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 of the Support of Mobile Number Portability (MNP) [2] GSM 03.66: Digital cellular telecommunication system; Stage 2 Technical Realisation of the Support of Mobile Number Portability (MNP) 2.2 Abbreviations GSM MNP abbreviations are contained within GSM and The MNP abbreviations used within other GSM standards documents will be included within GSM Support of specification work This document is a living document and permanently updated by MCC. Proposals for change shall be forwarded to MCC (editor direct contact details are on the last page), where the latest version can be obtained at any time. The MNP 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 and Change Request rapporteurs should ensure the latest versions of their material is made available for review and comment 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 are maintained) in../cr/ - The change request to existing specifications.

6 Page 6 3. General See 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 within the same country whilst retaining her original MSISDN or MSISDNs. The ported subscriber can use exactly the same 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 resources so as to minimise costs associated with transport of traffic and/or appropriate signalling and/or processing activities (e.g. optimal routing). 4. Requirements See in particular Stage 1 [1], and Stage 2 [2] documents for MNP requirements. 5. Functional description See Stage 1 [1] and Stage 2 [2] documents. 6. Technical realisation and amendments 6.1 Documentation Structure Overview The following is an overview of the principle GSM standards which together specify MNP. Section 8 following details the full list of GSM standards effected. GSM Stage 1 Service Description of the Support of Mobile Number Portability (MNP) GSM Technical realisation of the Support of Mobile Number Portability (MNP) 7. Approvals Time Frame for MNP In October 1997 SMG#23 decided on a GSM work item GSM number portability (later revised to Mobile Number Portability or MNP) under the main responsibility of SMG1; completion was planned for Stage 1 service description of the Mobile Number Portability was already presented for information to SMG#23. On the 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 for In December 1997 SMG#24 approved the Release 97 version GSM 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 the Mobile Number Portability standard, even if some delegates saw a high importance and main benefits of one single solution for all mobile and fixed networks, as EC was reported to see the priority for a quick solution and to assigns less importance to the international mobile case and the fixed-to-mobile case.adopting the view that main importance to have a solution ready in time. SMG#26 asked SMG3 and SMG12 to produce a Technical Report describing the restrictions and evolution potentials of both solutions. SMG#26 scheduled the core specifications of Mobile Number Portability for completion until SMG#28.

7 The Terms of Reference for STF EU 137 were also approved by SMG#26. Page 7 SMG12 forwarded the Technical Report to SMG3 for consideration when producing the Technical Realisation of Support of Mobile Number Portability (stage2). SMG#28 approved the specifications GSM Support of Mobile Number Portability (MNP) Technical Realization; 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 for completion 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 other services). Due to the high time pressure and the fact that the basic architecture for number portability is different in North America and Europe, it was not practical to seek approval by SMG and review by the STCs prior to approving it as a ANSI standard. Nevertheless, that T1P1 and its interested members intend to include the content of the T1P1 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 be required: one to examine the draft CR and suggest appropriate ways of introducing the information into the specification, 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 Specifications New specifications GSM No Current Version Title: Mobile Number Portability service description Prime resp. STC: SMG1 2ndary resp. STC(s): Presented for information at SMG# Approved at SMG# Rapporteur/Company (1 or more) SMG#23 SMG#24 Comments GSM No Title: Technical realisation of Mobile Number Portability Prime resp. STC: SMG3 2ndary resp. STC(s): Presented for information at SMG# Approved at SMG# Comments Current Version Rapporteur/Company (1 or more) Ulrich WIEHE (Siemens); Ruud Op Den Camp (Libertel) SMG#28 SMG#28

8 Page Change Requests for MNP Note: The up-to-date, definitive list of approved MNP change requests can be seen by examining the current MCC CR 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 SMG meeting, 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 in brackets indicates which TC-SMG plenary document contained the change request. Affected existing specifications GSM No. Specification Title CR number Subject of CR Tdoc rapporteur STC Mobile Number Portability; NEW New GSM specification Peter van der Arend / ETSI SMG1 Stage 1; service description Basic call handling; A030 r5 Introduction of Mobile Ulrich Wiehe / Siemens AG SMG3 Technical realization Number Portability Basic call handling; A038 r1 Introduction of Mobile Franco Settimo / ETSI SMG3 Technical realization Number Portability MAP A175 r4 Addition of Originating IMSI Peter van der Arend / ETSI SMG3 to MO-ForwardSM-Arg MAP A176 r1 Translation Type for MNP Ulrich Wiehe / Siemens AG SMG MAP A193 r2 Mobile Number Portability Alberto Burgaleta / Ericsson SMG Mobile Number Portability; Stage 2; Technical realisation NEW New GSM specification SMG3

9 Page 9 9. History Document history April 1999 First Edition Rapporteur: István KOCSI, ETSI / STF137 ikocsi@pgsm.hu Fax:+

10 Page 10 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 Green Paper on a numbering policy for telecommunications services in Europe. This consultation underlined the importance of equal quantitative and qualitative access to numbering resources for all market players and the crucial significance of adequate numbering mechanisms, in particular for number portability and carrier selection, as key 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 when changing to another operator or service provider). The extension of number portability for users of mobile and personal communications networks as well as for users of special services (e.g. allowing users to retain valuable numbers for freephone or personal communications 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 proposals to the European Parliament and to the Council regarding the accelerated introduction of number portability and regarding the introduction of carrier preselection. Directive 97/33/EC of the European Parliament and of the Council of 30 June 1997 on interconnection in telecommunications with regard to ensuring universal service and interoperability through application of the principles of open network provision was amended, i.e. the first subparagraph of Article 12(5) was replaced by the following (Directive 98/61/EC of the European Parliament and of the Council of 24 September 1998 amending Directive 97/33/EC with regard to operator number portability and carrier pre-selection): National regulatory authorities shall encourage the earliest possible introduction of operator number portability whereby subscribers who so request can retain their number(s) on the fixed public telephone network and the integrated services digital network (ISDN) independent of the organisation providing service, in the case of geographic numbers at a specific location and in the case of other than geographic numbers at any location, and shall ensure that this facility is available by 1 January 2000 at the latest or, in those countries which have been granted an additional transition period, as soon as possible after, but no later than two years after any later date agreed for full liberalisation of voice telephony services. Number Portability is defined as The service that allows customers to change operator, while keeping the same dialable telephone number. The goal is to provide the same quality of service to subscribers, irrespective whether they are ported or not. The following three types of Portability are distinguished (from European Commission DG XIII, equal access & interconnection ): Operator Portability: the ability of an end-user to retain the same telephone number as he/she changes from one 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 one permanent physical location to another Service Portability: the ability of an end user to retain the same telephone number as he/she changes from one type 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 to change SP, keeping the same number.

11 Page 11 A 2. Mobile Number Portability - Stage1 A 2.1 Work Item Description As the very first step of the standardization process of Mobile Number Portability (MNP), SMG1 elaborated a Work Item Description (WID), which was duly approved by SMG#23 (Tdoc ). Most importantly, the WID foresees only Mobile-to-Mobile number portability (between GSM900/GSM 1800 operators). Furthermore, the WID does not consider partial portability (whereas some services forming a GSM subscription being subject to number portability while other services of the same GSM subscription stay with the current operator). SMG , , , np03, np11 SMG , , , A 2.2 Service Description of Support of Mobile Number Portability Following the approval of the MNP WID by SMG #23, SMG1 was invited to prepare the GSM specification Service Description of Mobile Number Portability (GSM 02.66). The specification was elaborated in close co-operation with T1P1 and ETSI NPTF, presented for information to SMG#23, then finally approved by SMG #24. SMG , , , , , , , , , , , , np02, np06, np07, np08, np10, np11, np12, np20 SMG , , , , , , , , SMG3 98P410 SMG3 SA 97S163, 98S010 SMG SMG12 98S663 A 2.3 Co-operation with T1P1 on MNP stage1 In the US, Local Number Portability is defined in the Telecommunications Act of 1996 as the ability of users of telecommunications services to retain, at the same location, existing telecommunications numbers without impairment 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 to ported subscriber numbers anywhere in the United States as of 31 December The order also requires that CMRS providers offer service provider portability, including call delivery to subscribers ported into the 100 largest MSAs (including call delivery to roamers), as of 30 June Service Portability and Location Portability are not required at this time. The portation of subscriber directory numbers between wireline service providers and broadband CMRS providers or among broadband CMRS providers are considered changing service provider and not service. Therefore, service provider portability includes wireless to wireless, wireline to wireless as well as wireline to wireline. Wireless networks required to port between themselves in Europe are all GSM technologybased, unlike US markets which must port between several air interfaces (GSM/CDMA/TDMA/Analogue) and two network protocols (J-STD-023 and IS-41). No stage 1 specification was established for the Local Number Portability. SMG , np17 SMG A 2.4 Co-operation with ETSI NPTF on MNP stage 1 The ETSI Number Portability Task Force was set up in December 1996 by ETSI NA2 to examine the issues of geographic and non-geographic number portability within the Europe. SMG and ETSI NPTF co-operate in the following 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 also outside the scope of this co-operation.

12 Page 12 SMG SMG , , , , , SMG3 98P108, 98C673, 98C701 SMG12 98S563 A 2.5 STF 137 on Mobile Number Portability The EU study mandate 97/M-251 invites ETSI to identify the necessary modifications in the GSM standard to allow the 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 compare solutions currently developed, and to identify the necessary modifications of the GSM standards for the introduction of Number Portability in a harmonized way. SMG , ,

13 Page 13 A 3. Mobile Number Portability Stage2 A 3.1 Technical Realisation of Mobile Number Portability SMG#23 mandated SMG3 SA (promoted to SMG12 in March 1998) to develop the system architecture for MNP stage2. 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 cluster under certain restrictions. The decision on which method (and variation) is the most appropriate to a network depends on the requirements of the national environment (e.g. different national regulatory requirements). None the less, 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 problems between 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) NP and towards UMTS of both solutions) of both methods. Having the system architecture designed, SMG12 relayed the standardisation work on MNP stage2 and stage3 to SMG3. The Technical Realisation of MNP was approved by SMG #28. SMG , , , , , , , , , , , , , , , , np-06, np10, np11, np16, np20 SMG , SMG3 98p211, 98P410 SMG3 SA 97S163, 98S051, 98S087, 98S102, 98S172 SMG3 WPC 98C647, 98C774, 98C786, 99C067, 99C071, 99C166, 99C186, 99C239, 99C240, 99C250, 99C264 SMG , SMG12 98S265, 98S326, 98S402, 98S454, 98S455, 98S456, 98S663, 98S710, 98S751, 98S805 A Signalling Relay Function based solution The detailed description of the SRF based solution for the routeing of calls as well as non-call related signalling messages is found in GSM SMG3 SA 98S003, 98S006, 98S007 SMG3 WPC 99C211, 99C234, 99C269, 99C280, A IN based solution The detailed description of the IN based solution for the routeing of call related signalling messages is found in GSM This solution is closely aligned with the approach taken within PCS1900 Number Portability. It was agreed that for the appropriate routeing of non-call related signalling messages the SRF must be implemented according to the following guidelines: Originally, there was a system architecture proposed whereby all signalling messages would cross the VMSC or GMSC. Furthermore, for interworking with fixed networks, Call Dropback solution was also evoked. During the standardisastion process, both the system architecture was modified and the ISUP release option was rejected. SMG SMG3 SA SMG3 WPC 99P025 98S003, 98S004 98C781, 99C069, 99C070, 99C261, 98C603,99C766, 98C770

14 Page 14 A Comparison of approved technical solutions SMG12 produced a technical report on MNP stage2.this includes the presentation of the two different solutions known as IN solution and the Signaling Relay solution. It also provides the analysis of the two solutions in different terms 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 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 speech numbers, SMS, including the support of GSM Support of Optimal Routeing (SOR) and all other supplementary services 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 handles incoming call establishment MAP messages for ported subscribers. Since there is a need for intelligence at the SCCP level for non-call related signalling e.g. SMS, the operator can re-use this (SRF) functionality for call related 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 for example an STP. The MNP signalling relay functionality can be distributed within a GSM HPLMN or can be centralised 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 the signalling relay solution 6. This solution can provide optimal routing* for mobile originated calls to ported GSM subscribers, provided that the DB is copied to the originating network. (*) Optimal routing in this sentence means the routing from the originating network to the recipient network without the intervention of the donor network.

15 Page 15 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 have circuit established in the donor network), there is a need to get, in the originating network, the information about where to route the call. Several solution are currently being studied: duplication of the PLMN database in the fixed 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 one of the two solutions : to support MAP protocol in the originating network: in fixed networks such a requirement is a strong constrain. to support INAP protocol in the donor database: this represent an additional interface which may be 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 the architectural 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 to have resources used and circuits established in the donor network, several possibilities are offered to the GSM network : duplication of the fixed database in the GSM network, transfer via ISUP, interrogation of the fixed network database by the GSM network. As before, if the third options is chosen there is a need for the GSM network 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 the architectural choice to other solutions. 3) With the signalling relay function the GMSC function is apparently not modified. This means that classical GSM mechanisms are used : consequently no indication is provided to the GMSC that the call is ported or not, except by digits analysis of routing number provided by the NP HLR. If the leg from the GMSC to the recipient network is supposed to be charged differently from a normal re-routeing to an MSRN, extensive post processing (digit analysis 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 additional traffic 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 subscribers and 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 the three 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 traffic leaving the network considered is directed to ported subscribers within a cluster of porting networks the network considered is not member of, commercial and technical reasons will force the network considered to perform all NP services by itself concerning that kind of traffic. E.g. if there is fixed network number portability established and there is no cross-sector number portability, there will be nevertheless a strong need for mobile networks to perform NP services, thereby optimising routing, concerning outgoing traffic to fixed networks. An IN based solution for MNP will be able to use the same data base and the same interrogation procedure as fixed networks. 4. INAP as a standardised interface between switch and SCP for interrogating the NP database guarantees the interoperability of the nodes affected in different environments. 5. In serving an actual telecommunication service request, several identifiers are used in controlling the actual transaction 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 interception These identifiers may be of local (network internal) or global (network external) significance. They may be valid for the originating and/or terminating side of the actual transaction. Some or all of these identifiers may coincide or may be different. Number portability may affect some or all of these identifiers and any of the functionalities addressed above may have the need to be aware of the actual porting status. IN-like solutions are more flexible in 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 call records automatically generated by the switch thus reducing complexity in the postprocessing systems.

16 Page 16 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 not supported by the MSC, this requires strong investment and development. Nevertheless support of CAMEL is becoming a common feature in MSC: these functions require already the support of IN mechanism and IN trigger in the MSC. The additional requirement of the IN solution for MNP is to introduce new triggers. As consequence 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 a limited 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-call related 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 all service 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 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 currently identified. 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 to support the same version of MAP protocol as the one supported by other entities of the network : NP HLR is not fully transparent to MAP evolution. 2. How the SRF determines that the SCCP called party address represents a ported number is implementation dependent. 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 require any enhancement if MAP is modified. 2. The ETSI bodies SPS1, NA2, NA6 and NPTF which are working on fixed network number portability all assume an IN based solution. In adopting that approach for MNP some compatibility problems can be reduced in the perspective of fixed/mobile convergence. 3. Independently of fixed/mobile convergence, the IN solution can allow intersystem interrogation of NP database by 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 in SMG3 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 SMG3 and SPS1. A Generic Considerations with the Introduction of SRF-solution for non-call related 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

17 Optimal Routeing Page 17 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 and implementation 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 in the Number Range Owner network a mechanism to route SCCP message (containing MAP send routing information) to the HLR based on the Called subscriber MSISDN. So independently of MNP there is a requirement to have a Signal Relay function. MNP requires to enhanced such a Signal Relay Function to be able to route messages 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 will have to be delivered to ported-out subscribers. Consequently in such a case only ported-in subscribers will require new 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 Range Owner network, a mechanism to route SCCP message (containing MAP send routing information for SM) to the HLR based on the MSISDN. So independently of MNP there is a requirement to have a Signal Relay function. MNP requires 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 SCCP message to the HLR based on MSISDN. Such a requirement is independent of MNP. MNP requires to enhanced such 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 be possible without MNP to have based on Number Range Analysis in the SRF. Capacity and complexity of SRF will be increased because of MNP. SMG SMG3 98P211 SMG12 98S120, 98S222, 98S454, 98S455, 98S557, 98S574, 98S612, 98S613, 98S710, 98S751, 98S763, 98S805

18 Page 18 A 3.2 UK Solution The specificity of the service requirement in the United Kingdom is that MNP covers subscriber numbers allocated to GSM 900, GSM 1800, and TACS based technologies. The MNP specification deals only with MT transactions and specifies requirements on Qualifying Networks. The SRF principle is that the donor network forwards the routeing enquiry or other signal addressed to a ported number to the appropriate recipient network for treatment; the SRF acts like an intelligent STP holding a database of ported subscribers and their respective recipient networks. The recipient network can provide the routeing number or other result to complete the routeing of the call or transaction. To achieve this functionality, the SRF determines for which directory numbers relaying is applicable, then identifies the network relaying should be directed to, and finally modifies SCCP addressing to relay signals to the recipient network. Originating Donor Recipient Originatin /Gateway Node Service Service Other Result SRF Enquiry/Othe Signal Service Gateway/Transi Node Relayed signal Enquiry Result Location Register Signalling Relay Operation The effect of this solution is that the recipient network controls the routeing of the call from a gateway in the donor network. The result is that there is a direct routeing between the donor s gateway and the ultimate destination of the call. Therefore, if the called party is roaming in another network, or has set an unconditional divert to an off-net number, the call will be routed direct from the donor network to this destination and will not enter the recipient network. In this case the recipient network is unable to raise its own CDRs relating to the call; proprietary services in the recipient network relying on functionality in its own gateway may be compromised; the calling party may receive donor-network announcements and announcement charges when calling ported numbers. Therefore in the UK solution calls to ported numbers shall route through the recipient network. To achieve this a Direct Routeing Override (DRO) function is defined, the purpose of which is to force calls to ported numbers into the recipient network. DRO can be initiated by the Recipient Network or the Donor Network. DRO is only applicable to routeing enquiries for CS calls. Recipient initiated DRO is achieved by sending an Intermediate Routeing Number (IRN) to the donor s gateway node. The intermediate routeing number contains a prefix which has the effect of routeing the call into the recipient network. 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 in the recipient network, the call enters the standard routeing enquiry stage.

19 The signaling messages affected by MNP and their applicability to DRO: Page 19 Operation Name Protocol Applicable for DRO sendrouteinginformation SRI MAP Yes sendrouteinginformation (OR) SRI(with OR parameters) MAP Yes 1 sendrouteinginfoforsm SRI-SM MAP No setmessagewaitingdata SMWD MAP No reportsm-deliverystatus Report SM Delivery Status MAP No CcbsRequest CCBS Request CCBS ASE No CcbsSuspension CCBS Suspension CCBS ASE No CcbsResume CCBS Resume CCBS ASE No CcbsCancel CCBS Cancel CCBS ASE No sendimsi Send IMSI MAP No anytimeinterrogation Any Time Interogation MAP No 1 If optimal routeing is not allowed, the DROF in the Recipient network may either return an OR not allowed error (in which case the call will be routed to the donor network) or (preferably) return an IRN in the MSRN field of the acknowledgement, thus causing the call to be routed directly to the recipient network. In order to allow OR the donor network 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 mobile terminated ported calls is now dependent on the donor network as well as the recipient network. Direct routeing can be achieved by two methods, call trap and call drop back both of which require network development. Finally, only the Call Trap method (the recipient network traps calls to numbers which have been ported into the recipient network and which originated in the recipient network) is mentioned in the MNP specification. Call Trap can apply to both circuit-related calls and non-circuit related signalling. SMG SMG3 SA np01 97S359, 98S003

20 Page 20 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 the initiating MSC determines that the call is to a portable number (i.e., the called party number lies within a portable range), it initiates a query using the Called Party Number (dialled number) to the NP database. If the subscriber has ported, the Query Response message returns an LRN to the initiating MSC. If the subscriber is not ported, the Query response message returns the called party number (dialled number) to the initiating MSC. The LRN identifies the serving switch, which uses the LRN and the called party number to complete the call to the end user. The switch that obtains the LRN (the initiating MSC) sends an indication in the forward call set-up information (Forward Call Indicator in ISUP) that the NP status of the called party number has been determined, thus inhibiting subsequent queries at the succeeding switches/network. The call is routed using the called party number if the subscriber is not ported or error/time-out occurs. For numbers ported into the PLMN, the LRN will be used to route the call to at least one 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 made either in the terminating network or in a preceding network. HLR NP- database LSMS NPAC-SMS query & response STP STP Initiating MSC PSTN Serving MSC. Donor Switch MSC or Landline Switch Call Path Signaling Path Other NPAC-SMS is a Service Management System (SMS) responsible for storing and broadcasting to the Local Service Management System(s) (LSMSs) NP data updates within a service providers area. The LSMS is then responsible for 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 to carry 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 shall progress the call in one of two ways: - Interrogating the HLR before querying the NP database If an originating call or an incoming call with called party number is received by the MSC, the MSC sends a 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 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 releases the call). - Query the NP database before interrogating the HLR If a originating call or an incoming call with called party number is received by the MSC, the MSC detects the called party number is within a portable range and 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 party number. The MSC analyses the results and reacts

21 Page 21 accordingly (sets-up the call using LRN, sets-up the call with the called party number or interrogates the HLR 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 basic voice calls. A second specification, Number Portability for PCS 1900 SMS and Other Services addresses supplementary services and Intelligent Network services impacted by number portability (Calling Name Presentation, Call Forwarding, Multi-Party, Call Barring, Calling and Connected Line Identity, Call Hold, Call Waiting). The impact of Number Portability on CAMEL, GPRS, optimal routing, and roaming is outside the scope of the document. The following functional architecture is proposed by the specification: LSMS NPAC-SMS LSMS NP GTT NPDB NP GTT NPDB CNDB GSTP Signaling GSTP HLR SMS GMSC SMS- IWMSC SMS-IWMSC SC SC SMS GMSC MSC GMSC PSTN GMSC Recipient Network ng y Originating Network GMSC(*) GSTP(*) Visited Network Called party MSC(*) Call path These network entities will reside in the recipient network if the called Signaling path party is not roaming.

22 Page 22 A GSTP of the originating network may perform the non-final GTT that results in the routing of non-call related signalling messages to the NP GTT function. If the NP GTT function is resident on the GSTP, this non-final GTT is unnecessary. 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 and routeing for portable numbers. The NP GTT function translates all digits of any portable number into a 24 bit ANSI DPC of either the destination endpoint (final GTT) or some other entity capable of routing the message to the destination endpoint (non-final GTT). A service provider is expected to perform non-final GTTs for messages destined for other networks. The NP GTT function may be provided by any suitable node, such as a STP or SCP and 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 s network that are to be routed on a GTT basis where the GTA in the SCCP Called Party Address indicates a portable number. The systems originating the messages may either MTP address the messages directly to the system performing the NP GTT function or MTP address the messages to a system that performs a GTT and selectively routes (non-final GTT) messages with an SCCP Called Party Address indicating a portable number to the system performing the NP GTT function. In the latter case if the GTA in the SCCP called party address contains a nonportable 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 to be 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 in the NP GTT table for this destination, the NP GTT discards the SCCP message. If the portable number in the SCCP called party address is not ported, the NP GTT function default routes the message to either the final destination or to an intermediate STP. For the former, 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 indicate should indicate route on the Global Title (i.e., non-final translation). If the portable DN in the SCCP called party address is ported, the NP GTT function routes the message to either the final destination or to an intermediate STP. For the former, 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 legitimate MSISDN to its HPLMN. In the NP environment, to reduce incoming traffic to the NP GTT function, a new Translation Type 14 has been introduced to be used in conjunction with Translation Type 10 (prior to NP, used for SCCP routeing of all MAP messages that use the E.164 global title address). The recommended usage of the two Translation Types in NP environment 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 some modifications 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 setup. This routing information would be used when requesting, suspending, resuming or cancelling CCBS and again when the destination subscriber becomes idle, in order to set up the call. This modification of the ISUP 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 the LRN of the recipient network. Once the Donor network determines the LRN, the GMSC drops back the call to the transit network the LRN populated in the ISUP Release message. When the donor network releases the call back to the transit network, the transit network may release the call as far back within the network as necessary to efficiently route the call, or may just route the call forward from the tandem serving the donor 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 a change to the SRI Return Message. The reception of the SRI with a zero value for the IMSI causes the gateway MSC to release the call back to the transit network with the LRN as the redirecting number.