Docstoc

MNP Luxembourg Bid

Document Sample
MNP Luxembourg Bid Powered By Docstoc
					Proposal – Bid document




    Table of contents
    0  Executive summary ............................................................................................... 2
    1  Introduction ......................................................................................................... 4
     1.1 General remarks.............................................................................................. 4
     1.2 MNP context in Luxembourg.............................................................................. 5
       1.2.1 Expected porting scenario ........................................................................... 5
       1.2.2 Fixed number portability ............................................................................. 5
       1.2.3 Numbering issues....................................................................................... 6
     1.3 Selection criteria.............................................................................................. 6
    2 General terms and conditions ................................................................................. 7
     2.1 Definitions ...................................................................................................... 7
     2.2 Instructions to bidders ..................................................................................... 7
       2.2.1 Intent of bidding process............................................................................. 7
       2.2.2 Invitation to bid ......................................................................................... 8
       2.2.3 Specific instructions to bidders................................................................... 11
     2.3 Contract issues.............................................................................................. 13
       2.3.1 Risk of loss.............................................................................................. 13
       2.3.2 Laws, ordinances, codes, etc. .................................................................... 13
       2.3.3 Patent infringements ................................................................................ 13
       2.3.4 Implementation schedule .......................................................................... 13
       2.3.5 Project responsibilities .............................................................................. 15
       2.3.6 Contract duration ..................................................................................... 17
       2.3.7 Payment schedule .................................................................................... 17
     2.4 Installation process ........................................................................................ 17
       2.4.1 Documentation ........................................................................................ 17
       2.4.2 Progress report ........................................................................................ 19
       2.4.3 Changes to the contract ............................................................................ 19
       2.4.4 Responsibility of the purchaser during the installation process ....................... 19
       2.4.5 Testing ................................................................................................... 19
     2.5 Warranty ...................................................................................................... 21
     2.6 Maintenance ................................................................................................. 21
     2.7 Training........................................................................................................ 27
     2.8 Final system acceptance policy ........................................................................ 28
     2.9 Penalties....................................................................................................... 28
       2.9.1 Delays and non-performance ..................................................................... 28
    3 System requirements........................................................................................... 29
     3.1 Functional description .................................................................................... 29
     3.2 Architecture .................................................................................................. 30
       3.2.1 Fully automated process ........................................................................... 30
       3.2.2 Architectural options................................................................................. 31
       3.2.3 Central reference database........................................................................ 32
       3.2.4 Core protocols ......................................................................................... 33
       3.2.5 Transaction modules and related protocols .................................................. 35
     3.3 Technical aspects........................................................................................... 37
       3.3.1 Application server .................................................................................... 37
       3.3.2 Communication network ........................................................................... 38
     3.4 Management and reports ................................................................................ 38
     3.5 MNP look-up ................................................................................................. 42
     3.6 Quality of service........................................................................................... 42
       3.6.1 Capacity ................................................................................................. 42
       3.6.2 Availability .............................................................................................. 44
       3.6.3 Security .................................................................................................. 45
       3.6.4 Test equipment........................................................................................ 46
    4 Pricing ............................................................................................................... 47




2.01 MNP Luxembourg - RFP Response.doc                                                                                Page 1
Proposal – Bid document




    0 Executive summary

    The bidder

    The Bidder, Systor Trondheim as, based in Norway, is designing and developing innovative
    high performance & availability transactional database systems and applications for state-of-
    the-art internet usages. Systor has implemented and delivered full-scale Number Portability
    solutions in Norway and Portugal using their own product line NPS – Number Portability
    Server.

    The proposal

    The Bidder submits a proposal that is fully compliant in all aspects of the “full service” offer
    of the RFP.

    The technical solution

    The Bidder proposes for the MNP in Luxembourg a “full service” solution based on an
    adaptation of the Bidder’s existing NPS – Number Portability Server software.

    The NPS system is already developed and proven successful in other countries, ensuring a
    supreme phase of delivery to meet the Purchaser’s project timing requirements and also that
    the delivery is being executed by an experienced organization.

    Being language sensitive the NPS can be presented in several languages, according to the
    preferences of each user. Included in this offer is a bi-lingual system in English and French.

    The infrastructure

    The delivery comprises of three installation sites, the Production Site, the Test Site and the
    Disaster Recovery Site. The Bidder proposes that the Production Site and the Test Site are
    located in the production environment of the Bidder Systor Trondheim as, Trondheim,
    Norway, and that the Disaster Recovery Site is located in the disaster recovery environment
    of the Bidder Systor Trondheim as, Trondheim, Norway.

    Note: As an option the Purchaser is offered the possibility to locate the Production Site in the
    production environment of the Bidder’s server co-location partner Web Technologies S.A in
    Luxembourg.

    The internet, utilizing security mechanisms like VPN and firewalls, is used as the carrier for
    communication between the parties taking part in the NPS infrastructure.

    The relation to the operators

    An operator has the choice whether to connect his back office system to the MNP production
    Site writing his own Mediation Device (using the provided and specified NPS Interfaces), or
    to purchase a Mediation Device from the Bidder.

    The Bidder offers (out of scope for the MNP main delivery) its standardized Mediation Devices
    as a standalone manageable server unit, in a configuration suitable to be placed inside of the
    LAN of the operator. To adapt the Mediation Device to each operator’s back office system,
    one only adapts the back office specific parts of the Mediation Device, resulting in a short
    time of delivery and high quality of the transaction processing.




2.01 MNP Luxembourg - RFP Response.doc                                                        Page 2
Proposal – Bid document


    The day-to-day operation

    An SLA agreement to be entered between the succesfull Bidder and the Purchaser will govern
    the day-to-day operation of the MNP services.

    Systor will provide helpdesk support from their application support center based in
    Trondheim, Norway, where their multi-lingual staff with NP expertise will be available via the
    internet as well as by email and regular phone / fax.

    Systor will provide a local phone number in Luxembourg for access to helpdesk support
    services.

    Systor will provide technical system support, surveillance and maintenance from their
    technical support center based in Trondheim, Norway, where qualified personnel will be on
    duty on a 7:24:365 schedule.

    The MNP system operation will be targeted for a 99,7 % minimum availability schedule.

    Note: Even if the Purchaser chooses to locate the Production Site in Luxembourg, Systor will
    be responsible for the technical system support by a dedicated remote surveillance setup,
    supplementing the domestic partner’s pure hosting oriented services.

    The fee structure

    There are no upfront fees to pay before the MNP system goes into production.

    The bidder provides the MNP services as a pay-per-portation model, following a transaction
    oriented payment schedule.

    The fee is calculated, assessing the expected porting scenario for Luxembourg, and based on
    a relatively modest fixed amount per operator connected to the MNP system (an initial
    connection fee and a yearly service subscription fee), and a flat level per number ported fee.

    The per number ported fee is set at € 9,00.

    Note: If the Purchaser chooses to locate the Production Site in Luxembourg the extra cost
    arising from this is covered by a small increase to the per number ported fee only.

    The delivery schedule

    The Bidder proposes a delivery schedule replicating the requirements issued by the
    Purchaser in the RFP. This delivery schedule supports a proposed MNP system for
    Luxembourg being available to go live prior to the intended week 48 2003 deadline.

    Proposal validity

    This proposal with current terms and specifications is valid until 01.09.2003, and may be
    extended upon request.




2.01 MNP Luxembourg - RFP Response.doc                                                     Page 3
Proposal – Bid document




    1 Introduction

    Structure of this document:
    Each section in this bid document corresponds to the original numbering in the RFP [1]. An
    answer is included for each numbered item in the RFP, according to the instruction in section
    2.2.3 of the RFP. For section 3, a statement is also included for each numbered item,
    according to the instruction in section 3 of the RFP.

    Reference documentation:

    Ref.ID    Doc. no.    Description                                        Version
    1         RFP         Request for Proposal concerning Common             2.2 / 28-04-03
                          Facilities for the Introduction of Mobile Number
                          Portability in Luxembourg
    2         Annex-1     Number Portability Administrative Procedures       1.0 / 02.06.03
                          for Luxembourg
    3         Annex-2     Company profile and legal documentation
    4         Annex-3     Project personell resources
    5         Sample      NPS (UK) NRDB Interface Specification
    6         Sample      NPS (UK) NRDB Test Specification
    7         Sample      NPS (UK) NRDB Number Reselling Specification
    8         Sample      NPS (NO) NRDB Web User Manual
    9         Sample      NPS (NO) NRDB Web Interface Specification
    10        Annex-4     Software escrow agreement framework

    The original RFP document [1] is provided from the Purchaser, the escrow agreement
    framework [10] is provided from Escrow Europe B.V., the other reference documents are
    created from the bidder. All referenced documents (except the sample documents) form an
    integral part of the bid.

    1.1   General remarks

    Section   Description                                                    Answer
    (a)       The current Request for Proposal (‘RFP’) is established …      Acknowledged
    (b)       The Institute is defining the rules regarding the …            Acknowledged
    (c)       The Request for Proposal is further made with …                Acknowledged

    Section   Description                                                    Answer
    (d)       The Request for Proposal is further made with …                Acknowledged

    Detailed description/explanation:
    Realizing the sensitive kind of data contained in a MNP system, and especially due to the
    multi-national approach of the proposed system infrastructure solution, the bidder has put
    special emphasis on obeying the current legislation, first of all in relation to the NP
    requirements, but also that the bid and the proposed data processing is fully compliant
    according to this legislation and the framework issued by Commission Nationale pour la
    Protection des Données.

    The bidder will furthermore execute and be responsible for all required actions in relation
    with the Commission Nationale for the approval of the proposed solution, especially with
    regards to either the “prior notification model” or the “prior authorization model” models,
    dependant of the Purchaser’s choice of the proposed data processing solution.




2.01 MNP Luxembourg - RFP Response.doc                                                        Page 4
Proposal – Bid document


    The bidder carries a personal data processing approval according to the Norwegian Personal
    Data Act of 2000 issued by the Data Inspectorate, an independent administrative body under
    the Norwegian Ministry of Labour and Government Administration. The Norwegian Personal
    Data Act of 2000 implements the Directive 95/46/EC on the protection of individuals with
    regards to the processing of personal data and on the free movement of such data.

    A copy of the bidder’s data processing certificate, license number 99/1572-2, is contained in
    the Annex-2 [3] section F.

    Section   Description                                                  Answer
    (e)       The objective of the current Request for Proposal …          Acknowledged
    (f)       The ‘Institut Luxembourgeois de Régulation’ is the …         Acknowledged
    (g)       The Request for Proposal is given in cooperation with …      Acknowledged
    (h)       The order will be passed on the basis of a contract …        Acknowledged
    (i)       The contract will be established with the bidder …           Acknowledged
    (j)       All bidders have to comply with the instructions for …       Acknowledged
    (k)       The Institute may set up a penalties scheme …                Acknowledged
    (l)       The contract is governed by Luxembourg Law. Any …            Acknowledged


    1.2   MNP context in Luxembourg

    Section   Description                                                  Answer
    (a)       The aim of this request for proposal is to introduce …       Acknowledged
    (b)       In a first phase, Mobile Number Portability will be …        Acknowledged

    Detailed description/explanation:
    The bidder proposes for the MNP in Luxembourg a NPS system that is already developed and
    proven successful in other countries (Norway and Portugal). This ensures a supreme phase
    of delivery, to meet the Purchaser’s project timing requirements, and also that the delivery is
    being executed by an experienced organization. The bidder’s skilled project team is used to
    establishing NPS production quality systems, and also enrolling telecom operators into the
    use of the NPS system utilizing various interfaces to their back-end systems.

    1.2.1 Expected porting scenario

    Section   Description                                                  Answer
    (a)       Luxembourg’s mobile telecom landscape is marked by …         Acknowledged
    (b)       The expected growth of the number of subscribers …           Acknowledged
    (c)       The expected churn rate over the next few years is …         Acknowledged

    Detailed description/explanation:
    The expected porting scenario as described by the RFP resembles the analysis of the bidder,
    and is the one used for the transaction based pricing schedule in section 4 later in this
    document. Any major deviations from the stated porting scenario is on the risk of the bidder.

    1.2.2 Fixed number portability

    Section   Description                                                  Answer
    (a)       There are 11 fixed network operators with a licence …        Acknowledged
    (b)       Fixed number portability has been introduced in …            Acknowledged

    Detailed description/explanation:
    The bidder proposes for the MNP in Luxembourg a NPS system that is already developed and
    proven successful in other countries (Norway and Portugal). In both of these countries the




2.01 MNP Luxembourg - RFP Response.doc                                                      Page 5
Proposal – Bid document


    NPS handles mobile number portability as well as fixed number portability, through the
    implementation of national specific sets of administrative routines for MNP and NP.

    If desired the proposed MNP system in Luxembourg can be extended (option) to also cover
    the fixed number portability services, supporting the already established routing mechanism
    (onward routing). The bidder welcomes a discussion on these possibilities.

    1.2.3 Numbering issues

    Section   Description                                                    Answer
    (a)       The ILR is expecting a technical tool for managing the …       Acknowledged
    (b)       Beside the management of the reference data base …             Acknowledged

    Detailed description/explanation:
    Facilities for the management of the national numbering plan are provided as an integrated
    part of the proposed MNP solution, which is done by adapting a NPS Number Plan
    Administration module to the specific requirements of the Purchaser. These facilities for
    management of the national numbering plan are available via the Web.

    The technical details of the NPS Number Plan Administration module are covered in the
    bidders response to section 3.4 (d) later in this document.

    1.3   Selection criteria

    Section   Description                                                    Answer
    (a)       The retained solution shall provide the best cost …            Acknowledged
    (b)       The successful bidder shall provide an experienced …           Acknowledged
    (c)       The retained technical solution shall be designed …            Acknowledged

    Detailed description/explanation:
    The bidder is assured that he through the proposed MNP solution based on standard modules
    together with the transaction based pricing schedule (section 4 later in this document)
    provides the best cost/functionality relationship for the viable commercial model adapted to
    the Luxembourg context.

    The bidder would like to emphasis that the proposed MNP in Luxembourg is based on his
    already developed, tested and production ready NPS system, and that the NPS system is
    proven successful in production quality environments in other countries (Norway and
    Portugal).

    Further references on the bidder’s effective provisioning of facilities for Number Portability
    are contained in the Annex-2 [3] section B.




2.01 MNP Luxembourg - RFP Response.doc                                                        Page 6
Proposal – Bid document




    2 General terms and conditions

    2.1       Definitions

    Section       Description                                                 Answer
    2.1.1         Mobile number portability (MNP)                             Acknowledged
    2.1.2         Request for Proposal (RFP)                                  Acknowledged
    2.1.3         Project                                                     Acknowledged

    Section       Description                                                 Answer
    2.1.4         Bid                                                         Acknowledged

    Detailed description/explanation:
    The bidder makes, in compliance with the purchaser’s RFP, a proposal for the “full service
    offer”, as further detailed in the bidders response to section 2.2.2 (b) later in this document.

    Section       Description                                                 Answer
    2.1.5         Bidder                                                      Acknowledged
    2.1.6         Successful bidder/contractor                                Acknowledged

    Detailed description/explanation:
    The legal entity submitting the bid is Systor Trondheim as. The bidder is incorporated under
    Norwegian legislation and registered in the Norwegian Register of Business Enterprises with
    the company organization number of NO 979 155 034.

    Section       Description                                                 Answer
    2.1.7         Purchaser                                                   Acknowledged
    2.1.8         Contract                                                    Acknowledged

    Section       Description                                                 Answer
    2.1.9         Sub-contractor                                              Acknowledged

    Detailed description/explanation:
    The bidder will act as the solitary contractor, and will thus not rely on any third party or
    external company to fulfill his obligations according to the bid.

    2.2       Instructions to bidders

    2.2.1 Intent of bidding process

    Section       Description                                                 Answer
    (a)           The intent of this Request for Proposal document …          Acknowledged
    (b)           The provided system is to be a complete and fully …         Acknowledged
    (c)           A Bidder, by making the bid, guarantees that his …          Acknowledged

    Detailed description/explanation:

    With respect to the MNP system requirements, the following key advantages are encountered
    when choosing the proposed NPS system:

          •    The NPS system is proven, with successful installations in Norway (NRDB) and
               Portugal (ER)
          •    The NPS system provides the basic functionality ”out of the box”, as required by the
               MNP solution



2.01 MNP Luxembourg - RFP Response.doc                                                        Page 7
Proposal – Bid document


        •   The NPS platform is modular and easy to expand
        •   The NPS platform is built using the major vendor open product stack (Sun One,
            Sybase Adaptive Server Enterprise and Sybase Enterprise Application Server), which
            supports a wide range of third party client interfaces and heterogeneous
            interconnection products, including Windows, UNIX and LINUX platforms
        •   The utilized third party de facto standard products and protocols offer great
            integration and data exchange possibilities with other existing database systems, like
            Oracle, Microsoft SQL Server and a range of other products

    Section    Description                                                  Answer
    (d)        RESPONSES TO THIS RFP WILL CONSTITUTE AN …                   Acknowledged

    2.2.2 Invitation to bid

    Section    Description                                                  Answer
    (a)        Bidders are invited to submit a bid response based on …      Acknowledged
    (b)        There are two options for the commercial offer …             Acknowledged
    (c)        Bidders are welcome to make a proposal for both …            Acknowledged
    (d)        Paragraphs in this document that only apply to a …           Acknowledged

    Detailed description/explanation:
    The Bidder submits a proposal that is fully compliant in all aspects of the MNP “full service”
    offer of the RFP.

    The Bidder will offer a full MNP service towards the operators and the Institut
    Luxembourgeois de Régulation (ILR).

    The full MNP service will include hosting and operation of the service on the Bidder’s own
    hardware and software infrastructure. The Bidder will through the offering of available
    specified interfaces, compliant to the RFP and according this bid, give operators the choice
    whether they would like to connect their back office system to the MNP production Site
    writing their own Mediation Device, or if they rather would like to purchase a Mediation
    Device from the Bidder and have it adapted to the specific requirements of their back office
    system.

    More on the use of Mediation Devices and available protocols / methods is described in
    sections 3.2 and 3.3 later in this document.




2.01 MNP Luxembourg - RFP Response.doc                                                       Page 8
Proposal – Bid document


                                                            Test Site

                                                                  Ethernet




                    Production site &                      Database   Application    Web
                                     Firewall
                 Production Management                      Server      Server      Server


                               Ethernet                                                      Support service




      Firewall           Database   Application    Web
                          Server      Server      Server




                                Internet




                            Network
                            Operator

                                    Network
                                    Operator

                                            Network
                                            Operator




    The delivery comprises of three installation sites, the Production Site, the Test Site and the
    Disaster Recovery Site.

    The Bidder proposes that the Production Site and the Test Site are located in the production
    environment of the Bidder Systor Trondheim as, Trondheim, Norway, and that the Disaster
    Recovery Site is located in the disaster recovery environment of the Bidder Systor Trondheim
    as, Trondheim, Norway.




2.01 MNP Luxembourg - RFP Response.doc                                                                     Page 9
Proposal – Bid document


    As an option the Purchaser is offered the possibility to locate the Production Site in the
    production environment of the Bidder’s server co-location partner Web Technologies S.A in
    Luxembourg.




    The internet, utilizing security mechanisms like VPN and firewalls, is used as the carrier for
    communication between the parties taking part in the NPS infrastructure.




2.01 MNP Luxembourg - RFP Response.doc                                                      Page 10
Proposal – Bid document


    The Bidder offers (out of scope for the MNP main delivery) its standardized Mediation Devices
    as a standalone manageable server unit, in a configuration suitable to be placed inside of the
    LAN of the operator. To adapt the Mediation Device to each operator’s back office system,
    one only adapts the back office specific parts of the Mediation Device, resulting in a short
    time of delivery and high quality of the transaction processing.

    An SLA agreement to be entered between the successful Bidder and the Purchaser will
    govern the day-to-day operation of the MNP services.

    Systor will provide helpdesk support from their application support center based in
    Trondheim, Norway, where their multi-lingual staff with NP expertise will be available via the
    internet as well as by email and regular phone / fax.

    Systor will provide a local phone number in Luxembourg for access to helpdesk support
    services.

    Systor will provide technical system support, surveillance and maintenance from their
    technical support center based in Trondheim, Norway, where qualified personnel will be on
    duty on a 7:24:365 schedule.

    The MNP system operation will be targeted for a 99,7 % minimum availability schedule.

    Note: Even if the Purchaser chooses to locate the Production Site in Luxembourg, Systor will
    be responsible for the technical system support by a dedicated remote surveillance setup,
    supplementing the domestic partner’s pure hosting oriented services.

    Pros of the “full service” offer in comparison to the “solution” offer

    By offering a “full service” offer, the Bidder would like to emphasis:

        •   All responsibility for the operation of the system, both hardware and software – as
            well as connected communication infrastructure, is placed on the same entity that is
            responsible for the day-to-day operation of the MNP system. This will prevent dubious
            liability situations is a system malfunction should occur in one of the units comprising
            the total MNP system, giving the Purchaser a single point of responsibility to
            approach.

        •   The Bidder is given the solitary responsibility to incorporate into the product on a
            regular maintenance basis improvements and tuning aspects, utilizing his inside
            knowledge of the MNP solution. Bu assessing system behaviour on a proactive basis
            the Bidder is well situated to approach issues before they develop into potential
            system harms.

        •   From a cost/functionality approach the “full service” offer utilizes the Bidder’s
            organizational resources in an cooperative and optimal way, giving way for the
            overhead-minimized pricing schedule of this offer.


    2.2.3 Specific instructions to bidders

    Section    Description                                                   Answer
    (a)        Prior to submitting bids, each Bidder is requested to …       Acknowledged
    (b)        All Bids must be precise and numbered corresponding …         Acknowledged
    (c)        The Purchaser reserves the right to accept any bid or …       Acknowledged
    (d)        The reception of a bid response does not oblige …             Acknowledged
    (e)        The Purchaser reserves the right to modify the …              Acknowledged




2.01 MNP Luxembourg - RFP Response.doc                                                      Page 11
Proposal – Bid document


    Section   Description                                                  Answer
    (f)       Bidders are required to send a registered mail to the …      Acknowledged

    Detailed description/explanation:
    The bidder confirms that a letter stating his intent to submit this proposal was sent by
    registered mail May 13 2003. The copy of the receipt for the registered mail is shown below.




    Section   Description                                                  Answer
    (g)       Two (2) hard copies and two electronic copies of the …       Acknowledged

    Detailed description/explanation:
    This proposal is submitted in two hard copies (duplicate original) and two electronic copies.
    The electronic copies (on CD media) contain all proposal documents stored in the Adobe
    Portable Document Format (PDF) format.

    In order to view PDF documents on all major hardware and operating system platforms, you
    need a copy of the Adobe Acrobat Reader Software, available free of charge from the Adobe
    web site at http://www.adobe.com/products/acrobat/readstep2.html For convenience a
    recent copy of the Adobe Acrobat Reader suitable for Windows 2000 / XP platforms is stored
    on the proposal CD media.

    Section   Description                                                  Answer
    (h)       All technical questions regarding this RFP may be …          Acknowledged
    (i)       A pre-bid conference may be held at the premises of …        Acknowledged
    (j)       All proposals submitted will be considered property …        Acknowledged
    (k)       The Purchaser reserves the right to use any design …         Acknowledged
    (l)       Proposals submitted may be reviewed and evaluated …          Acknowledged
    (m)       The selected bidder will be considered the primary …         Acknowledged




2.01 MNP Luxembourg - RFP Response.doc                                                    Page 12
Proposal – Bid document



    Section   Description                                                    Answer
    (n)       The Purchaser requires the successful Bidder to sign …         Acknowledged
    (o)       Bidders may submit a draft contract as part of their …         Acknowledged

    Detailed description/explanation:
    The bidder confirms the willingness to sign a contract drafted by the Purchaser including all
    the requirements, deliverables and remedies negotiated by and agreed on by both parties,
    according to the RFP.

    The bidder does not at this stage submit a draft contract as part of his proposal, but is willing
    to take on this responsibility (the creation of a draft contract) if such services are requested
    from the Purchaser in relation to his party eventually being considered for the successful
    bidder.

    2.3   Contract issues

    2.3.1 Risk of loss

    Section   Description                                                    Answer
    2.3.1     All risks of loss or damage to the hardware equipment …        Acknowledged

    Detailed description/explanation:
    The risks of loss or damage to hardware or software used in the project, both during the
    implementation and during delivery of the service, is borne in full by the bidder.

    The bidder is carrying an extensive corporate consultancy / product responsibilities insurance
    that covers the risks of loss or damage in relation to events that may affect both hardware
    and software production environment and delivery progress.

    A copy of the bidder’s corporate insurance certificate number 0081867 is contained in the
    Annex-2 [3] section E.

    With regards to eventual force majeure situations, the contract between the Purchaser and
    the successful bidder will contain a section for risk assessment if such events should occur,
    based on the applicable force majeure framework given by the laws governing the contract.

    2.3.2 Laws, ordinances, codes, etc.

    Section   Description                                                    Answer
    2.3.2     The successful Bidder will comply with all applicable …        Acknowledged

    2.3.3 Patent infringements

    Section   Description                                                    Answer
    2.3.3     The successful Bidder shall agree to indemnify the …           Acknowledged

    2.3.4 Implementation schedule

    Section   Description                                                    Answer
    (a)       Each Bidder is required to submit with the bid a …             Acknowledged

    Detailed description/explanation:
    The Bidder proposes a implementation schedule according to the milestones set forth in the
    RFP. The schedule, based on previous NP implementation experiences, is detailed in the
    following GANTT figure, and may be further explained if requested.



2.01 MNP Luxembourg - RFP Response.doc                                                      Page 13
Proposal – Bid document




2.01 MNP Luxembourg - RFP Response.doc   Page 14
Proposal – Bid document



    Section    Description                                                 Answer
    (b)        The successful Bidder shall assign a Project Manager …      Acknowledged

    Detailed description/explanation:
    The Bidder proposes Mr Gunnar Barstad as the Project manager. A short resymè of Mr
    Barstad’s Curriculum Vitae shows:

        •   2001 – Project manager for the development of the Portuguese ER system for number
            portability in Portugal
        •   2000 – Project manger for the development and maintenance of the Norwegian NRDB
            system for number portability in Norway
        •   1999 – Project manager for the development of the Norwegian national livestock
            database system

    Mr Barstad’s complete CV, as well as the CV of applicable project team resources on hand at
    the Bidder, is located in the Annex-3 [4].

    Section    Description                                                 Answer
    (c)        All appropriate details shall be specified in the …         Acknowledged
    (d)        The dates for commencement and completion of the …          Acknowledged

    Detailed description/explanation:
    It is explicitly understood by and agreed upon by the Bidder that the stipulated contract time
    for completion of the work as stated in the Annex 1 of the RFP (and further confirmed in this
    proposed bid) related to Project Timing is reasonable and will be adhered to.

    2.3.5 Project responsibilities

    Section    Description                                                 Answer
    (a)        The selected bidder will be considerer the primary …        Acknowledged

    Detailed description/explanation:
    The Bidder proposes the following project team in completion of the Project Manager (as
    defined in section 2.3.4 (b) of this document):

    Project manager:
           Mr Gunnar Barstad

    Project engineers (implementation):
           Mr Karl Oddvar Balvold (implementation manager)
           Mr Rune Okstad
           Mr Roar Foshaug
           Mr Christian Anders Eggen
           Mr Jarle Hildrum

    Project engineers (infrastructure, test and documentation):
           Mr Anders Alstad (infrastructure manager)
           Mr Øyvind Hov (test manager)
           Mr Thor Ole Vold

    Supportive project administrative services:
          Jo Arne Lervik

    These resources will be utilized for their special competence areas during the delivery
    schedule. A full set of CVs for the proposed project team members is located in the Annex-3
    [4].


2.01 MNP Luxembourg - RFP Response.doc                                                    Page 15
Proposal – Bid document



    Section    Description                                                   Answer
    (b)        If the primary contractor decides to use the services …       Acknowledged

    Detailed description/explanation:
    The bidder will act as the solitary contractor, and will thus not formally rely on any third
    party or external company to fulfill his obligations according to the bid.

    Partner for eventual domestic housing of Production Site:

    The Purchaser is implicit in this bid given the option of having the infrastructure comprising
    the Production Site hosted domestic (within Luxembourg).

    If the Purchaser chooses such domestic housing, the preferred server co-location partner of
    the Bidder is:

        Web Technologies s.a.
        Management office
        28-30 Val St. André
        L-1128 Luxembourg
        Luxembourg

        Web Technologies s.a.
        Technical Center
        8, rue Henry Schnadt
        L-1617 Luxembourg
        Luxembourg

        Web: http://www.web.lu
        Email: info@web.lu
        Phone: (+352) 26 25 77 1
        Fax: (+352) 26 25 77 78

    Web Technologies maintains a state-of-the-art co-location facility in Luxembourg featuring
    high-speed, redundant access to the Internet backbone. Their years of experience in server
    administration assure a superior level of availability and performance.

    Regardless of the physical location of a Production Site, the bidder proposes to locate the
    Disaster Recovery Site at the following premises:

        •   Located in the disaster recovery environment of the Bidder Systor Trondheim as,
            Trondheim, Norway

    Regardless of the physical location of a Production Site, the bidder proposes to locate the
    Test Site at the following premises:

        •   Located in the disaster recovery environment of the Bidder Systor Trondheim as,
            Trondheim, Norway

    If the Purchaser has its own preferred server co-location partner in Luxembourg, the Bidder
    is willing to utilize the services of the Purchaser’s preferred server co-location partner
    instead, at otherwise unchanged terms, as long as the fee structure of the Purchaser’s
    preferred server co-location partner does not significantly differ from the fee structure of the
    Bidder’s preferred server co-location partner.




2.01 MNP Luxembourg - RFP Response.doc                                                       Page 16
Proposal – Bid document



    Partner for supply of software escrow services:

    Furthermore the Bidder proposes to use the escrow services of a third-party, Escrow Europe
    B.V. of Herengracht 414, Amsterdam, the Netherlands. This service is detailed in section 2.6
    (e) of this document.

    If the Purchaser has its own preferred escrow agent, the Bidder is willing to utilize the
    services of the Purchaser’s preferred escrow agent instead, at otherwise unchanged terms,
    as long as the fee structure of the Purchaser’s preferred escrow agent does not significantly
    differ from the fee structure of the Bidder’s preferred escrow agent.

    General terms:

    The Bidder assures that the selection and approval of the any sub-contracor / partner, will be
    made in cooperation with the Purchaser and according to the project responsibility rules
    contained in the RFP.

    2.3.6 Contract duration

    Section   Description                                                  Answer
    (a)       [Full service only] The proposed contract duration is …      Acknowledged

    Detailed description/explanation:
    The bidder agrees on the proposed contract duration of 5 years. The bidder further proposes
    contracted optional extensions of the contract on 2 x 3 years.

    Section   Description                                                  Answer
    (b)       [Solution offer only] The Bidder shall include a …           Acknowledged

    2.3.7 Payment schedule

    Section   Description                                                  Answer
    2.3.7     All Bidders shall submit a detailed payment schedule …       Acknowledged

    Detailed description/explanation:
    The bidder claims no “by percentage completion” upfront payment requirements, thus there
    are no upfront payments to be considered by the Purchaser.

    Charging of the MNP service to the operators and ILR will start with the final acceptance of
    the system, according to the definition in section 2.8 (b) of the RFP.

    The payment schedule is further detailed in section 4 later in this document.

    2.4   Installation process

    2.4.1 Documentation

    Section   Description                                                  Answer
    2.4.1     Prior to the final system acceptance, the successful …       Acknowledged

    Detailed description/explanation:
    The bidder will prior to final system acceptance, and in relation to later system updates,
    submit system documentation in the quality and quantity according to the requirements in
    the RFP.




2.01 MNP Luxembourg - RFP Response.doc                                                    Page 17
Proposal – Bid document


    The MNP system for Luxembourg will be documented on a similar level as the Bidder’s
    previous NPS deliveries. Specific user manuals will be provided for the use of the applicable
    interfaces.

    The system documentation will be provided in English and will be made available as
    equivalent electronic document / online document / printed document versions.

    The documentation delivered with the MNP system for NP in Luxembourg includes:

    MNP Processes and Interfaces Specification

            •   Describes NP processes and applicable interfaces

    MNP Acceptance Tests Plan

            •   Test environment
            •   Test strategy
            •   Test activities
            •   Approval/non-approval criteria
            •   Test design
            •   Test cases
            •   Test procedures
            •   Tests scheduling

    MNP Acceptance Tests Report

            •   Test results
            •   Deviations
            •   Action points

    MNP System Administration Manual

            •   Installation and Configuration
            •   Systems Management and Maintenance
            •   Operations Error Handling
            •   Backup
            •   Security Policies
            •   Network operator / User management (System access)

    MNP User Manual

            •   Authorisation and security
            •   Applicable functionality
            •   Applicable NP scenarios and message exchange

    MNP Systems Detailed Specification

            •   System architecture
            •   Database model
            •   MNP interfaces
            •   MNP internals (message handling, validation and timers)

    As a sample of the system documentation style of the bidder, the following documents are
    attached to this bid:

        •   NPS (UK) NRDB Interface Specification [5]
        •   NPS (UK) NRDB Test Specification [6]



2.01 MNP Luxembourg - RFP Response.doc                                                    Page 18
Proposal – Bid document


        •   NPS (UK) NRDB Number Reselling Specification [7]
        •   NPS (NO) NRDB Web User Manual [8]
        •   NPS (NO) NRDB Web Interface Specification [9]

    Please refer to references [5-9].

    2.4.2 Progress report

    Section    Description                                                     Answer
    2.4.2      During the installation process, the successful Bidder …        Acknowledged

    2.4.3 Changes to the contract

    Section    Description                                                     Answer
    (a)        During the course of the installation process, the …            Acknowledged
    (b)        During the course of the installation process, either …         Acknowledged

    2.4.4 Responsibility of the purchaser during the installation process

    Section    Description                                                     Answer
    2.4.4      The Bidder shall clearly define the expected …                  Acknowledged

    Detailed description/explanation:
    In relation to the installation process the Purchaser will receive from the Bidder clearly
    defined the expected responsibilities and arrangements of the Purchaser.

    These expected responsibilities may include defined roles as an active controller /
    coordination function in the relations between each of the operators and the Bidder, since
    the Purchaser may act on these parties behalf during part of the negotiations / installation
    process.

    Furthermore the Purchaser will be expected to provide sufficient resources at the milestones
    requiring Purchaser evaluation / approval, according to the project timing in section 2.3.4 (a-
    d) in this document.

    For meetings in Luxembourg, according to the RFP section 2.4.2 and otherwise, the
    Purchaser is expected to provide at his premises meeting room facilities with AV equipment
    and internet access (for connection of Bidder’s laptop / other demonstration or testing
    equipment).

    The further details of expected responsibilities and arrangements of the Purchaser will be
    drawn up in the draft contract between the Purchaser and the Bidder, see section 2.2.3 (n-o)
    in this document.

    2.4.5 Testing

    Section    Description                                                     Answer
    (a)        The Bidder shall clearly define all post-installation tests …   Acknowledged

    Detailed description/explanation:
    The test plan is part of the documentation submitted prior to the system acceptance, and
    consists of two parts:

        1. FAT (Factory Acceptance Test), which is the pre-installation tests performed by the
           Contractor. When FAT tests are completed, the system will be delivered to the
           Purchaser for acceptance testing



2.01 MNP Luxembourg - RFP Response.doc                                                      Page 19
Proposal – Bid document



           2. SAT (Site Acceptance Test), which is the post-installation tests performed by the
              Purchaser or parties engaged by the Purchaser (system users)

    The SAT test plan and SAT test schedule is described in the following. After completing the
    SAT tests, a detailed test report will be given to the Purchaser.

    SAT Test plan

    The capabilities to be tested and the involved parties are shown in the following table.

                                                                                        Network Operator Network Operator
    Test activity                                            Contractor                                                                                             ILR
                                                                                        (System access)                      (Manual Port Access)
    1 SOAP Interface
    2 VPN Connections                                                   √                             √
    3 Web Service Access                                                √                             √
    4 Web Service Invocation                                            √                             √
    5 Web Interface
    6 Access levels / Authorization                                     √                                                                   √
    7 Reports and statistics                                            √                                                                   √
    8 MNP Protocol
    9 Message flows                                                     √                             √                                     √
    10 Validation                                                       √                             √                                     √
    11 Porting table updates                                            √                             √                                     √
    12 Interface interoperability                                       √                             √                                     √
    13 Numbering plan                                                   √                                                                                              √
    14 Performance                                                      √                             √                                     √

    SAT Test schedule

    The SAT Test Schedule is shown as a Gantt-diagram in Figure 1.

                                                                                                03 Nov '03                  10 Nov '03              17 Nov '03
      ID    Task Name                        Duration   Start       Finish     F          S   S M T W T           F   S   S M T W T         F   S S M T W T            F    S
       1    T est SOAP Interface              6 days Mon 03.11.03 Mon 10.11.03
      2         VPN Connections                3 days   Mon 03.11.03 Wed 05.11.03         03.11               05.11
      3         Web Service Acces s            3 days   Thu 06.11.03    Mon 10.11.03                 06.11                        10.11
      4         Web Service Invocation         3 days   Thu 06.11.03    Mon 10.11.03                 06.11                        10.11
      5     T est Web Interface               4 days Mon 03.11.03       T hu 06.11.03
      6         Access levels / Authoriza      2 days   Mon 03.11.03    Tue 04.11.03      03.11           04.11
      7         Reports and s tatistics        2 days   Wed 05.11.03    Thu 06.11.03              05.11           06.11
      8     T est MNP Protocol                5 days    T ue 11.11.03 Mon 17.11.03
      9         Message flows                  5 days   Tue 11.11.03    Mon 17.11.03                                      11.11                             17.11
      10        Validation                     2 days    Fri 14.11.03   Mon 17.11.03                                                14.11                   17.11
      11        Porting table updates          2 days    Fri 14.11.03   Mon 17.11.03                                                14.11                   17.11
      12        Interface interoperability     2 days    Fri 14.11.03   Mon 17.11.03                                                14.11                   17.11
      13    Numbering plan                     5 days    Fri 07.11.03   Thu 13.11.03                      07.11                             13.11
      14    Performance                        2 days   Tue 18.11.03 Wed 19.11.03                                                                   18.11           19.11


                                                            Figure 1 - SAT Test Schedule


    Section           Description                                                                                                         Answer
    (b)               During the testing phase, the successful Bidder shall …                                                             Acknowledged




2.01 MNP Luxembourg - RFP Response.doc                                                                                                                               Page 20
Proposal – Bid document


    2.5       Warranty

    Section      Description                                                  Answer
    (a)          The successful Bidder shall warrant that all software …      Acknowledged

    Detailed description/explanation:
    The Bidder makes the required warrants and guarantees as stated in section 2.5 (a) of the
    RFP.

    Since the proposed bid is made for the “full service” offer, the Bidder also makes explicit that
    the bid includes an extension of the warranty, covering not only the first year of production
    (after system acceptance date) but also the complete contract duration after the initial year.

    This extended warranty covers the eventual necessary repair, adjustment / replacement of
    any defective equipment, materials or other parts of the system at bidders cost. Also
    covered by the extended warranty is the eventual necessary correction / enhancement of the
    NPS software at bidders cost, where such correction / enhancement during the initial year of
    production would be covered under the regular warranty.

    Purchaser will thus incur no costs for service or replacement of software or hardware during
    the complete contract duration.


    Section      Description                                                  Answer
    (b)          The successful Bidder shall warrant that the system will …   Acknowledged

    Detailed description/explanation:
    The Bidder makes the required warrants and guarantees that the system will accommodate
    traffic at the levels specified in all appropriate sections of the RFP.

    The Bidder would further like to refer to the NPS system’s proven ability to accommodate
    traffic at similar NPS installations, as shown in section 3.6.1 (a) of this document.

    The Bidder’s proposal includes the scaling of the necessary infrastructure, at the risk and
    cost of the Bidder, to handle eventual traffic pattern fluctuations over the duration of the
    contract.

    2.6       Maintenance

    Section      Description                                                  Answer
    (a)          Each Bidder is required to provide a complete …              Acknowledged

    Detailed description/explanation:

    The Bidder is dedicated to provide the necessary services to the telecommunications
    providers and the Institut Luxembourgeois de Régulation in order to effectively run the MNP.

    The services and deliverables provided by the Bidder include:

          •    System documentation and user guides
          •    End-user Training
          •    Support services
          •    Helpdesk service
          •    Integration test support
          •    Service level Agreement – SLA




2.01 MNP Luxembourg - RFP Response.doc                                                      Page 21
Proposal – Bid document



    Processing plan and targeted MNP system availability

    The proposed MNP system is designed for 7 x 24 x 365 operations, and operation will be
    targeted for a 99,7 % minimum availability schedule.

    Demand for high availability has been put into the selection of both the hardware and
    software setup. Only hardware with appropriate MTBF-rates and also software that have
    proven its stability ("tried, tested and true") in similar installations has been choosen. Also
    with regards to other NPS installations, we can prove that the NPS system meets the
    proposed measures for a high availability system.

    Message and transaction processing is continously running in the NPS system. The message
    and transaction processing is also running during all backup operations utilizing special
    transaction log mechanisms. The message and transaction processing during backups is
    done without significant processing degradation.

    Regarding the restricted need for planned downtime, the NRDP system is designed for
    24:7:365 operations both with respect to hardware and software setup. This includes the
    ability to regulary change hardware components like disks, IO-cards, power supplies etc. in
    running, so called hot-swapping units. For more extensive repairs / upgrades there may be
    requested planned downtime.

    Planned downtime will always be announced in writing and approved in writing by the
    customer, according to these guidelines:

        •   Simple, max 8 hours/month, 3 days notice

    Planned downtime, of max 8 hours per month, will always be announced in writing and
    approved in writing by the customer and will be issued by at least 3 days notice. Such down
    time will be feasible to excerise all system maintenance, like software upgrades,
    reconfigurations, system tuning etc.

        •   Extensive, max 18 hours /month, 25 days notice

    Planned downtime, of max 18 hours per month, will always be announced in writing and
    approved in writing by the customer, and will be issued by at least 25 days notice. Such
    down time will be only be used when it is necessary for the more extensive exchange of
    components in the NPS system.

    Auditing operations and error surveillance

    The NPS core database system has inherent logging (auditing) that for various parts of the
    system can be configured through the administrative interface to audit actions down to
    field/value level in the database. The auditing can store user and content-information for all
    remote calls that has been issued against the dataabase server, as well as the text of the call
    itself.

    The database server system utilized by the NPS, the Sybase Adaptive Server Enterprise,
    contains several self-recovering mechanisms, like a log rollback / rollforward that will get the
    database system back into a transaction-proof state after an event of abruption of service.
    All NPS operations are logged to internal databases, as well as external log files and through
    status agents. The NPS Surveillance system reads and combines all these sources into its
    own surveillance database for presentation, water-mark breakout detection and alarm
    setting/clearing.




2.01 MNP Luxembourg - RFP Response.doc                                                       Page 22
Proposal – Bid document



    Helpdesk and related integration test support services

    The Helpdesk Services (1st line support) provided by the Bidder will be the common access
    point for inquiries, providing the official office and mailing address for written inquiries. The
    office will be equipped to receive inquiries by e-mail, phone and fax.

    The Bidder will provide a local phone number in Luxembourg for access to helpdesk support
    services.

    The manned helpdesk service will be available within this time coverage:

        •   Monday to Friday
        •   Normal business hours from 08:00 to 17:00.

    The Bidder may according to this optional time coverage offer an extension of the helpdesk
    service hours, for a shorter or longer period of time:

        •   Monday to Saturday
        •   Normal business hours from 07:00 to 19:00.

    The extension of the helpdesk service hours is priced in the section 4.1 of this document as a
    hourly surcharge for the duration of the requested extension.

    The Helpdesk staff will have thorough understanding of the NP administrative procedures,
    the NP application and the communications network set up for communications between the
    operators and the MNP system.

    The staff will be equipped with a set of procedures which will guide them to solve as many
    problems as possible at the 1st line level and tools giving them access to the system
    databases and a snap-shot of the system status – including communications lines.

    Response time and restoration times

    By response time is meant the time interval from receipt of a problem notification or change
    request to the beginning of the analysis of the problem or change request. Coverage hours
    are defined being defined by agreed coverage time (08:00 – 17:00 or 07:00 – 19:00) all
    regular working days.

    The SLA agreement to be written between the parties will determine required response and
    restoration times in case of system malfunction, categorized according to the severity levels
    agreed upon. The SLA will also determine economical sanctions in relation to non-
    performance.

    Typically the following time limits apply:

            Severity Level     Description                                     Response time
            Critical           System is not working and workaround is         [2 hours]
                               not possible. The entire business is
                               affected.
            Major              System is running. Workaround is not            [4 hours]
                               possible. The business is partly affected.
            Minor              System is running and business can              [Next business
                               continue. Workaround is possible.               day]
            New feature        Features that have not been specified by        [Within one week]
                               the requirement specification.




2.01 MNP Luxembourg - RFP Response.doc                                                        Page 23
Proposal – Bid document



    Languages supported by the helpdesk

    English and German speaking consultants who also speak well Norwegian for good
    communications with the 2nd and 3rd line support team will staff the Helpdesk.

    Inquiries in the French language will be accepted, but currently by e-mail and fax only.

    Helpdesk procedure

    The typical help desk procedure will be as follows:

        •   The problem report is received by the call centre and logged
        •   The problem is analysed using diagnostic diagrams and system status tools
        •   If a problem seems to result from a technical error or when a "non-technical error"
            cannot be resolved using the diagnostics diagrams:

               o   Trouble ticket is issued and forwarded to 2nd line support.
               o   2nd line support acknowledges the trouble ticket and estimates a plan for
                   feedback/solution.
               o   2nd line support investigates and solves the problem, using the help of 3rd line
                   support if necessary.
               o   2nd line support reports back to 1st line support, closing the trouble ticket.

        •   1st line support reports back to the user.

    Integration test support

    The Bidder will provide integration test support to the operators in order to assist them with
    error resolution and the "Ready for Connection Approval" preparations.

    The operators will order time for integration testing on the MNP test system and run the test
    cases set up for the integration testing.

    During the testing, a designated person at the MNP helpdesk will be available for support.
    This person will look at the interaction with the testing operator as seen from the MNP
    system and will assist to find the reason whenever the response from the MNP system or
    interaction between the two systems is not as expected.

    Remote access

    The Bidder will establish remote access, secured by VPN / firewalls via the internet, from his
    support center to all components of the MNP system eventually residing outside the
    infrastructure environments hosted by the Bidder. For communication backup purposes ISDN
    dial-up lines ara available.

    On-site interventions

    The Bidder has from the 7:24:365 manned support center instant access to all premises
    within infrastructure environments hosted by the Bidder. In case some of the Production
    environment units are to be hosted outside the premises of the Bidder, agreements are
    already in place that the domestic hosting partner upkeeps the equivalent instant access and
    on-site intervention possibility as the Bidder on his hand upkeeps on non-domestically
    hosted equipment.




2.01 MNP Luxembourg - RFP Response.doc                                                      Page 24
Proposal – Bid document



    Section    Description                                                    Answer
    (b)(1)     Each Bidder shall clearly state and explain his …              Acknowledged

    Detailed description/explanation:
    Selecting a NP solution that is utilized by several installations secures the continued product
    development and adaptation of new features.

    The NPS solution is a dynamic and modular NP solution that will evolve according to
    continuous refinement through the incorporation of new legislations, updated infrastructure
    and general functional incremental improvement.

    The Bidder’s modular approach to the NP server architecture also ensures our customers that
    future options related to the adaptability our products stay open in the face of accelerating
    technological change.

    Section    Description                                                    Answer
    (b)(2)     He shall furthermore provide the financial and technical …     Acknowledged

    Detailed description/explanation:
    Related to the possibility for the Bidder to incorporate additional services to the operators
    connecting their system to the MNP system in Luxembourg, we welcome enquiries specifying
    details on the functionality requested, after which we will offer the implementation of the
    new functionality either as a incorporated functionality of the common NPS product line
    (commun function requested / needed / necessary for many purposes or more than one
    customer / installation) or suggest to implement the functionality as a standalone dedicated
    module for the customer in question.

    Such adaptations are, depending on type and evaluation, either:

        •   Delivered according to a one-time fee model (based on the framework rates given in
            the section 4.1 of this document)
        •   Delivered in exchange for a surcharge on the transaction based per ported number
            fee
        •   Delivered free of charge since as part of the general warranty / software support
            agreement incorporated in this bid

    The latter is relevant if the change / adaptation is made necessary by underlying changes in
    e.g. operating system, third party software, minor change in legislation or malfunction in
    bigger or lesser degree.

    Section    Description                                                    Answer
    (c)        [Solution offer only] All associated costs shall be …          Acknowledged
     (d)       The successful Bidder shall certify the ability to provide …   Acknowledged
     (e)       The successful Bidder shall offer a software escrow …          Acknowledged

    Detailed description/explanation:
    To secure the Purchaser’s rights in relation to the solution offered by the Bidder, the Bidder
    proposes a software escrow agreement with a professional escrow agent as the neutral third
    party software deposit.

    The software escrow is an agreement whereby the Bidder (supplier) and the Purchaser (end-
    user) agree that the supplier will deposit the source code and related materials (included
    documentation) of a licensed software product on behalf of the end-user. This in order to
    warrant the end-user access to that information in case the supplier for one reason or
    another is no longer able or willing to provide maintenance of the software product.



2.01 MNP Luxembourg - RFP Response.doc                                                     Page 25
Proposal – Bid document


    Upon the deposit the escrow agent will:

        •   Verify whether the material is readable and virus free
        •   Verify whether the deposit contains the components that were agreed upon in the
            escrow contract.
        •   Deposit the material in highly secured storage
        •   Request the deposit of updates or new releases at least once a year or at intervals
            agreed upon in the escrow contract
        •   Keep the parties informed about the status of the deposit and the results of the
            verifications
        •   Release the Material in situations as provided for in the contract

    The preferred escrow agent of the Bidder is:

            Escrow Europe B.V.
            Herengracht 414
            Amsterdam, the Netherlands

            http://www.escroweurope.com

    Escrow Europe is an independent organization, founded in 1989, which solely concentrates
    on escrow and the services that are essential for a good escrow arrangement.

    Objectives of escrow:

        •   Continuity of use of the software by end-user in circumstances where that would be
            impossible without escrow.
        •   Safeguard the underlying business process.
        •   Protection of end-users investment in the software (and related hardware).
        •   Limitation of end-users total dependency of supplier for maintenance of the software

    Software escrow in essence has to warrant two vital elements: a quality deposit and the
    legal right to use it.

        •   A quality deposit implies a deposit that at least has been checked for presence and
            restorability of the materials as agreed between parties: the technical department of
            Escrow Europe verifies each and every initial and update deposit on these aspects.
            Furthermore, a quality deposit implies a deposit that keeps track of the ever occurring
            changes made to the product during its lifecycle: the technical department of Escrow
            Europe at least once a year initiates active follow-up for the latest version of the
            product.

        •   Having the deposit released, does not guarantee the right of use of the deposit.
            Certainly when in the course of events the property rights of the product change
            hands, it may happen that the new owner simply forbids the use of the Material and
            legally is justified to do so: a quality contract to prevent such pitfalls requires
            specialised legal skills and the legal department of Escrow Europe has a decade of
            experience in just those pitfalls.

    To give access to the relevant material (source code and documentation) on such occasions,
    end-user and supplier agree upon an escrow deposit of those materials, verified and
    administered by a professional Escrow Agent.

    Under the arrangement, Escrow Agent is entitled to release the materials to end-user in the
    circumstances specified in the agreement. Upon release of the materials, end-user is able
    either to continue the maintenance of the software himself, or to outsource the maintenance
    to a third party.



2.01 MNP Luxembourg - RFP Response.doc                                                    Page 26
Proposal – Bid document



    A proposed framework for a software escrow agreement, based on the use of Escrow Europe
    as the escrow agent, is contained in the Annex-4 [10].

    If the Purchaser has its own preferred escrow agent, the Bidder is willing to utilize the
    services of the Purchaser’s preferred escrow agent instead, at otherwise unchanged terms,
    as long as the fee structure of the Purchaser’s preferred escrow agent does not significantly
    differ from the fee structure of the Bidder’s preferred escrow agent.

    Section   Description                                                    Answer
    (f)       The successful Bidder must provide contact names and …         Acknowledged

    2.7   Training

    Section   Description                                                    Answer
    (a)       [Solution offer only] The successful Bidder shall provide …    Acknowledged

    Detailed description/explanation:
    Even though the Bidder is proposing the “full service” offer, he feels adequate training of the
    operators and controllers is important and required, and will thus provide introductory
    training included in the proposed delivery.

    The Bidder has previously developed and carried out training programs for operators
    connected to existing installations in Norway and Portugal. Thus, existing NPS training
    programs have already been developed and can be adapted to the requirements of the
    Luxembourg installation and Administrative Routines.

    The Bidder proposes to carry out the training courses from a location in Luxembourg, over
    the internet working against the Test Site. Training is normally done in one or several
    sessions, depending on the number of operators (number of personnel for each operator)
    that are to be introduced to the system at any time.

    The class sizes are flexible and designed for 2-16 persons, simulating the typical NP
    messaging from 2-8 operators. The training of operator personnel follows a designated path
    of test cases utilizing the NPS system to fulfill different successful and non-successful NP
    scenarios. The class size and location can be adapted to demand.

    The Training Specification will be based on the documentation of the administrative routines
    and the interface- and messages specifications. The Bidder assumes that an analysis defining
    the participating operators’ qualifications and internal goals for utilization of the number
    portability system will be used as basis for development of a final training specification.

    This training specification will be prepared by the Bidder in cooperation with the Purchaser
    and will be produced in parallell with the physical finalization of the installation. Training
    courses and relevant training material is offered in English.

    Section   Description                                                    Answer
    (b)       [Solution offer only] The Purchaser may under certain          Acknowledged




2.01 MNP Luxembourg - RFP Response.doc                                                      Page 27
Proposal – Bid document




    2.8   Final system acceptance policy

    Section   Description                                                  Answer
    (a)       The successful Bidder conducts a final acceptance test …     Acknowledged
    (b)       [Full service offer only] Final acceptance of the system …   Acknowledged
    (c)       [Solution offer only] A standard 20% holdback of the         Acknowledged

    2.9   Penalties

    2.9.1 Delays and non-performance

    Section   Description                                                  Answer
    (a)       The successful Bidder agrees to the defined overall …        Acknowledged
    (b)       [Full service only] In case of a full service offer, the …   Acknowledged
    (c)       If the delay exceeds 12 weeks, the project will be …         Acknowledged
    (d)       In the event of non-performance on the part of the …         Acknowledged




2.01 MNP Luxembourg - RFP Response.doc                                               Page 28
Proposal – Bid document




    3 System requirements

    Section   Description                                                   Answer
    (a)       For each of the System Requirements listed in this …          Acknowledged
    (b)       In addition to the formal answers, detailed descriptions …    Acknowledged

    3.1   Functional description

    Section   Description                                        Answer             Statement
    (a)       The proposed system has to provide number…         Acknowledged       Supported

    Detailed description/explanation:
    The proposed system for number portability in Luxembourg is based on the NPS (Number
    Portability Server), installed in Norway (NRDB) and Portugal (ER). The NPS product provides
    number portability to both mobile and fixed network operators.

    The flexible protocol (messages and parameters) described later (see also Annex-1 [2]),
    makes the solution fully extendible with respect to network scope.

    Section   Description                                        Answer             Statement
    (b)       All required central facilities, functions …       Acknowledged       Supported

    Detailed description/explanation:
    The functionality of the central MNP is described in the following, with references to
    subsequent sections.

    Central facilities / functions / mechanisms
    The core functionality of the MNP is described in following sections, among others:
           Automated porting process, section 3.2.1
           Manual porting process, section 3.2.1
           Transaction handling, section 3.2.5
           Generation and presentation of reports and statistics, section 3.4
           Application for managing the numbering plan, section 3.4

    Protocols
    Refer to section 3.2.4.

    Procedures
    The suggested Administrative Procedures for Number Portability in Luxembourg are
    described in Annex-1 [2].

    Software
    Refer to section 3.3.1.

    Hardware
    Refer to section 3.3.1.


    Section   Description                                                   Answer
    (c)       Aspects to call routing and signaling between…                Acknowledged




2.01 MNP Luxembourg - RFP Response.doc                                                       Page 29
Proposal – Bid document


    3.2         Architecture

    3.2.1 Fully automated process

    Section               Description                                                                              Answer                          Statement
    (a)                   The number portability process shall be a …                                              Acknowledged                    Supported

    Detailed description/explanation:
    The MNP solution provides a Web Services interface for automatic processing. The Web
    Services interface is based on the de facto standards WSDL, UDDI and SOAP. By
    implementing these technologies, the central MNP system offers integration possibilities to
    any network operators’ back office system. The MNP system becomes part of an internet-
    based distributed computing environment.

    Figure 2 illustrates the automated porting process. The porting is initiated when the
    Customer Service registers a new subscription. No manual intervention is needed in the rest
    of the porting process.

                                                                                         3. The NP Request is           4. The MNP central
                                                                                            sent to the MNP               forwards the NP
                                                                                        central, which registers         Request to donor
     1. Customer service registers a new        2. The back office system creates       the porting information               provider                 5. The NP Request
     subscription. Number is to be ported       an MNP porting request message                                                                             is validated

                                            1                                       3                              4
                                                                                                                                                   5
                                                                                                                                                           Database

                                                                                    8                              7
            Customer Service                             Operator A                                                        Operator B
                                                      Back office System                                                Back office system
                                                                                             MNP Central
                                                                                                                       6. The back office system
                                                   8. The MNP central forwards                                          creates an MNP porting
                                                    the NP Accept to recipient            7. The NP Accept is
                                                                                                                           accepted message
                                                     provider. The back office              sent to the MNP
                                                     system proceed with the            central, which registers
                                                         porting process                the porting information


                                                         Figure 2 - Automated porting process


    Section               Description                                                                              Answer                          Statement
    (b)                   However, in order to also provide support …                                              Acknowledged                    Supported

    Detailed description/explanation:
    The MNP Web interface provides full number portability functionality, including message
    exchange and access to reports. By using the MNP Web, a user can manually create and
    respond to number portability messages.

    The Web interface is also convenient for testing purposes.

    A web user is always associated with a registered operator. Only information related to the
    actual operator can be viewed/changed. In addition, there are several user levels, - from
    administrator to user with read-only rights.

    Each user to the system are assigned a preferred language. Being language sensitive the
    NPS can be presented in several languages, according to the preferences of each user.
    Included in this offer is a bi-lingual system in English and French.

    Figure 3 shows a screen dump from the Norwegian NRDB web interface just to show the
    structure of the WEB-page. The actual screen shows the details of a specific porting case.
    The field in the middle shows the order specific information (reference of authorisation
    (PilotTest001), subscription type (single number) and phone number (30001099)). The
    bottom field lists the messages sent for the actual order (request for portation has been sent




2.01 MNP Luxembourg - RFP Response.doc                                                                                                                         Page 30
Proposal – Bid document


    and acceptance has been received). Several levels of menu tabs are used to navigate
    through the web application.

    Commonly used browsers like Internet Explorer and Netscape are supported.




                      Figure 3 - NRDB screen dump: porting order details



    Section   Description                                      Answer            Statement
    (c)       The compatibility between manual and …           Acknowledged      Supported

    Detailed description/explanation:
    The Web services interface and the Web interface read and write number portability
    information from/to the same database structures. The same Message handler processes
    messages to and from both interfaces. The one and same message can even be retrieved by
    both interfaces (as long as the message read is not committed).

    Compatibility between manual and automated procedures is therefore guaranteed.

    3.2.2 Architectural options

    Section   Description                                      Answer            Statement
    (a)       For the current RFP two (2) architectural …      Acknowledged      Supported
    (b)       The Bidder may chose the option that will …      Acknowledged      Supported

    Detailed description/explanation:
    The proposed solution is based on an architecture with centralized reference database and
    centralized communication management (option A).

    Centralized communication management is used with success in both Norway (NRDB) and
    Portugal (ER).



2.01 MNP Luxembourg - RFP Response.doc                                                    Page 31
Proposal – Bid document



    The central MNP system has a one-to-one relationship to all connected operators (the MNP
    central system being the hub in a star topology). To update the central reference database,
    any operator can send information to the central MNP system. This scenario is used for both
    options (centralized and distributed communication).

    With distributed communication, message exchange will typically be performed directly
    between the operators. This means that each operator must interact individually with all
    other operators.

    As long as each operator is connected to the MNP central, it is suggested to use this
    infrastructure also for the message exchange. Benefits are gained, compared to the
    distributed communication solution:

        1. An additional protocol will not be needed, saving work with specification,
           implementation and maintenance
        2. Centralized communication minimizes the number of connections
        3. Centralized communication is more flexible with respect to scalability. The connection
           of a new operator affects only the central MNP system.

    Local database access feature of the standalone Mediation Devices

    An operator has the choice whether to connect his back office system to the MNP production
    Site writing his own Mediation Device (using the provided and specified NPS Interfaces), or
    to purchase a Mediation Device from the Bidder.

    If a operator have chosen the Bidder’s standard Mediation Device unit, this will act as a
    replicated local copy of the central database system. The operator will thus have access to all
    his relevant (his own) data from a database within his own LAN.

    Synchronization with the standalone Mediation Devices

    A process called a Replication Server handles the synchronization between the Mediation
    Device and the central database system transparently. This process also holds stable devices
    creating storage queues for the transaction safe synchronization over the internet eliminating
    effects from throughput fluctuations.

    Synchronization with the Disaster Recovery Site

    To keep a Disaster Recovery Site synchronized with the Production Site the Replication
    Server is configured to continuously keep a second copy of the relevant databases updated
    as a so-called “warm-standby” data store.

    3.2.3 Central reference database

    Section   Description                                        Answer            Statement
    3.2.3     The central reference database will at least …     Acknowledged      Supported

    Detailed description/explanation:
    The data contained in the central reference database are, among others:
          Ported Number Reference
          Transactions
          Porting Order History
          Porting Order Status




2.01 MNP Luxembourg - RFP Response.doc                                                      Page 32
Proposal – Bid document



    Ported numbers
    A ported (or returned) number is inserted into the porting table whenever an update event
    occurs. The porting table contains routing information on all ported numbers, both past and
    present. In addition to the mapping between MSISDN and operator, donor operator, porting
    time, porting order ID, eventual expiration time and specific porting status are also stored in
    the porting table.

    Transactions
    All MNP messages are stored in the central reference database, and are identified by the
    unique NP message ID. The status for a message changes as it propagates through the MNP
    system.

    Porting order history
    All MNP messages are related to a specific MNP order (message flow), identified by the
    unique order ID. By referring to the specific order ID, the history of all porting orders can be
    extracted from the central reference database, both past and active orders.
    As a matter of maintenance, old data can be moved to a backup database (or external
    media), which means that the full porting order history of all numbers might not be directly
    available. The porting table can then be used as a history summary and reference.

    Porting order status
    The porting order status is managed by the NPS Message Handler. An NP order is
    represented by a database object which is updated for each occurring event related to the
    specific order. The order status will typically change when a new message is sent in a specific
    message flow (related to a specific order).

    Data integrity
    A user (operator) is granted access to the MNP system according to the specific access level.
    Furthermore, by only providing well-defined (and limited) functionality, unauthorized (and
    malicious) access is prohibited. In any case, direct database operations are abstracted away
    from the application level, as all database interactions are handled only by MNP internal
    structures.

    All Application Server processes use database logins with only public (limited) access.
    Information requests are always verified against the actual operator ID (certificate), so that
    the operators cannot see information related to other operators. All established user
    sessions, as well as connection attempts will be logged.

    3.2.4 Core protocols

    Section   Description                                         Answer             Statement
    3.2.4     The protocols 1a, respectively 1b and 3b …          Acknowledged       Supported

    Detailed description/explanation:
    This proposal is based on option A: centralized reference database and centralized
    communication. Protocol 1a is described in Annex 1 – Administrative procedures for Number
    Portability in Luxembourg [2]. The actual figure from the RFP document is repeated below.




2.01 MNP Luxembourg - RFP Response.doc                                                      Page 33
Proposal – Bid document


            Operator 1                                                        Operator 2




        Protocol 2a
                      Transaction                                     Transaction
                        module                                          module


                                Protocol 1a    Porting
                                              Reference
                                              Database




                                              Transaction
                                                module




                                              Operator 3

            Figure 4 - Option A with fully centralized architecture [Figure 1 in RFP]


    The automated process is based on the SOAP technology. NP Messages are sent as XML
    documents, encapsulated in SOAP “envelopes”. To send an NP message via the central MNP
    system, the operator issues a SOAP request against the central MNP Application Server. See
    Figure 5. When the request is processed, a SOAP response is returned, typically containing
    the assigned identifiers.

    SOAP over HTTP is a request-response protocol with no inherent callback capabilities. The
    MNP central Application Server is not able to send a SOAP request (NP response message)
    back to the operator’s SOAP client.

    The proposed solution provides two alternative ways to forward NP messages by using the
    central MNP system:

        1. The operator provides a SOAP server, implementing the standard service interface
           (WSDL). This is shown in Figure 5. The URL of the (client) Web Service is registered
           as part of the call to the server (MNP central). When an NP message is destined to
           the actual operator, the MNP central sends a request to the operator’s SOAP server,
           eventually getting a response in return.




2.01 MNP Luxembourg - RFP Response.doc                                                     Page 34
Proposal – Bid document




                              SOAP request
                  SOAP                          SOAP
                  client                        server
                             SOAP response
                                                                     JDBC

                              SOAP request      SOAP
                  SOAP
                                                proxy                           MNP central
                  server
                             SOAP response       client
                                                                            reference database

           Operator A                           MNP central
                                              Application Server
                            Figure 5 - Operator providing SOAP server


        2. If the operator does not provide a SOAP server, he can poll for new incoming
           messages by periodically sending SOAP requests to the MNP central.




                             SOAP request
                  SOAP                          SOAP
                  client                        server
                             SOAP response
                                                                     JDBC


          Operator A
                                                                                MNP central
                                                                            reference database

                                                MNP central
                                              Application Server
                                     Figure 6 - Polling operator
    A third alternative is to use the optional transaction module, as described in the next section.

    3.2.5 Transaction modules and related protocols

    Section   Description                                        Answer             Statement
    (a)       As an alternative to the transaction modules …     Acknowledged       Supported
    (b)       The protocols 2a respectively 2b (depending …      Acknowledged       Supported

    Detailed description/explanation:
    The proposed solution is based on a defined interface (1a) instead of using transaction
    modules. Transaction modules are offered on an optional basis.

    The automatic processing interface provided by the central MNP system is a Web Services
    interface using SOAP over HTTP. Operators that are able to interact with this interface do not
    need a transaction module. As HTTP is used for transport, firewalls are no challenge.

    Optional local transaction module
    Typically, a network operator has to maintain several back office systems that are involved
    in the porting process, for example:
            CRM (Customer Relationship Management)


2.01 MNP Luxembourg - RFP Response.doc                                                     Page 35
Proposal – Bid document


                 Billing systems
                 IN systems (network routing)

    In general, different communication protocols are used. The network operator typically needs
    to implement some kind of mediation device between the MNP Central and the back office
    systems.

    The basic infrastructure is shown in Figure 7, where MNP connectivity and mediation has to
    be resolved by the network operator.




                   CRM
                                           MNP Connectivity and mediation

       Routing
      Database
                                                                                       Internet

                 IN system
                               Firewall                                     Firewall




                  Billing


                   Figure 7 - Back office - MNP integration without transaction module


    The purpose of a locally installed transaction module is to smoothly integrate back office
    systems to the MNP system, by abstracting away the MNP specific protocol. A transaction
    module is offered as an option, and will fill the “missing link” in Figure 7. This is shown in
    Figure 8.




                   CRM
                                           MNP Connectivity and mediation

       Routing
      Database                                                    Local
                                           Adaption Layer         MNP                  Internet
                                                                Reference
                                          Mediation Device      Database
                 IN system
                               Firewall                                     Firewall




                  Billing


                       Figure 8 - Back office - MNP integration with transaction module


    The transaction module is installed together with a local replicate of the Central Reference
    Database. By




2.01 MNP Luxembourg - RFP Response.doc                                                            Page 36
Proposal – Bid document


    The “inside” interface of the transaction module will be tailored to the specific protocol(s)
    used by the operator. Typical protocols are File and CORBA. Figure 9 illustrates the use of a
    transaction module.

                Back office
                 systems                           Transaction
                                                     module                      MNP local
                                                                            reference database
               CRM system
                                 CORBA        CORBA module
              IN system
                              File transfer    File module
                                                             Mediation
          Billing system                                                 JDBC
                               CORBA          CORBA module
                                                              Device

                                                   ...

                                                Operator
                                                 specific
                                                adaptions

                            Figure 9 - Operator using Transaction Module
    The Mediation Device connects to the local copy of the reference database via JDBC (Java
    DataBase Connectivity). Incoming and outgoing messages are mediated according to the
    specific adaption module. Typically, a different set of NP messages are handled by the
    different back office systems. For example IN systems need only to process NP Update
    messages.

    NPS Messagehandler
    The NPS (Number Portability Server) product, on which the MNP proposal is based, provides
    a central message handler (transaction handler). All NP messages are placed in the same
    message queue, regardless of origin (SOAP automatic interface or Web manual interface).
    The centrally located message handler processes all kinds of NP messages in a FIFO order
    (First In First Out), as soon as the message arrives. In that way, arriving messages will
    immediately be forwarded to the recipient. Message delivery might however be delayed,
    depending on which interface the responding operator uses. If he uses the SOAP interface,
    providing a SOAP server, - or if he uses a local transaction module, the message will be
    delivered immediately.

    3.3   Technical aspects

    3.3.1 Application server

    Section    Description                                          Answer         Statement
    (a)        The centralized part shall be based on a …           Acknowledged   Supported

    Detailed description/explanation:
    The proposed solution is based on the following platforms:
           Web application server: Sun One Application Server 7. Development, deployment,
           and management of application services for a broad range of servers, clients, and
           devices; based on Java 2 Platform.
           RDBMS: Sybase Adaptive Enterprise Server 11.5, a well-known and widespread
           relation database technology accessible by state of the art interfaces, internally
           including SQL and Java, externally several object oriented client libraries.

    Section    Description                                          Answer         Statement
    (b)        The used standards and development …                 Acknowledged   Supported



2.01 MNP Luxembourg - RFP Response.doc                                                    Page 37
Proposal – Bid document



    Detailed description/explanation:
    The development language is Java, and applications are deployed on the Sun One platform.

    3.3.2 Communication network

    Section   Description                                       Answer             Statement
    (a)       As communication network, the usage of …          Acknowledged       Supported
    (b)       It can be assumed that connectivity to the …      Acknowledged       Supported

    Detailed description/explanation:
    The communication between the central MNP and the operators will be relying on VPN-
    connections over the internet, based on IPsec encrypted. The Firewall-solution dedicated for
    the protection of the system will be based on running CheckPoint FW-1 NG on a Linux/HP
    server.

    The central MNP utilizes dual Cisco routers to support both the main and backup connections
    simultaneously. The routers have similar configurations that will ease its exchange should a
    problem occur.

    Cisco routers (Cisco 2610 Router + ISDN + V35) and HP switches (HP ProCurve Switch
    2524M 24 x 10/100) will be utilized in a infrastructure setup where core leased line IP
    internet main communication is backed with a fallback to ISDN communication.

    Section   Description                                       Answer             Statement
    (c)       SOAP 1.1 or 1.2 is the preferred technology …     Acknowledged       Supported

    Detailed description/explanation:
    MNP protocols will be implemented using the SOAP 1.1 technology. The Java[TM] API for
    XML-Based RPC (JAX-RPC) 1.0 delivers Web Services interoperability based on the SOAP 1.1
    specification and Web Services Description Language (WSDL) documents.

    3.4   Management and reports

    Section   Description                                       Answer             Statement
    (a)       Management and supervision of the system …        Acknowledged       Supported

    Detailed description/explanation:
    Management of central reference database engine and structures is mainly performed via
    specific Sybase tools and SQL tools. Web-based tools are provided for several aspects of the
    MNP system, as described in the following.

    Supervision of network, servers and databases
    A system Surveillance module has been integrated with the Number Portability Server (NPS)
    environment and communicates with other tools and agents like the Compaq Insight
    Manager agents using standard SNMP. These agents report on disk use, CPU-load,
    temperatures, UPS etc. Also the Win2K SNMP-agent is used for information regarding
    memory use etc.

    The web based user interface (an example view is shown below), shows the historical
    development of any parameter. Watermarks, limit definitions, pattern recognition etc. can
    trigger alarm situations of different severities. The system reports status and alarms through
    SMTP/mail, SMS or other available interfaces.




2.01 MNP Luxembourg - RFP Response.doc                                                    Page 38
Proposal – Bid document




    NRDB central: Network traffic                      NRDB central: CPU utilization




    NRDB central D: Disk usage                         NRDB central: tempdb database usage




                                        Figure 10 - NPS Surveillance
    Management of Application Server
    The Sun ONE Application Server provides its own web-based management tool. The
    administrative console's main function is to provide an easy-to-use means of managing
    server configuration information.




                                 Figure 11 - Sun ONE Administrative console




2.01 MNP Luxembourg - RFP Response.doc                                                       Page 39
Proposal – Bid document


    Management of MNP providers and users
    The MNP system administrator is authorized to add, remove and modify all provider and user
    properties. In addition, the super user at each operator is authorized to modify provider
    specific information and administer provider specific user accounts.

    Provider and user management is provided by the standard MNP Web interface. Figure 12
    depicts a screen from the Norwegian (NRDB) Number Portability Web, showing Provider/User
    management (Administrator rights).




                                Figure 12 - NPS User Management


    Section   Description                                        Answer          Statement
    (b)       Statistical reports on the porting activity …      Acknowledged    Supported

    Detailed description/explanation:
    Statistical reports on the porting activity will be generated on a weekly basis, both
    accumulated data and per-provider data (numbers ported in and out). These reports are
    available to users with access to the MNP Web interface. ILR will be granted access to all
    reports, while network operators will have access to only accumulated data and per-provider
    data specific to the actual provider.

    Section   Description                                        Answer          Statement
    (c)       An export possibility into a commonly …            Acknowledged    Supported

    Detailed description/explanation:
    Web reports can also be exported to Microsoft Excel (.xls) files.

    Section   Description                                        Answer          Statement
    (d)       Facilities for the management of the national …    Acknowledged    Supported

    Detailed description/explanation:




2.01 MNP Luxembourg - RFP Response.doc                                                 Page 40
Proposal – Bid document


    Facilities for management of the national numbering plan will be provided as a supplement to
    the proposed MNP solution. These facilities will be available via the Web interface.

    The bidder has successfully adapted Number Plan administration to NPS installations and our
    experience is that the regulatory body will want to adapt the exact specification and
    functionality for this application, after the eventual project award. Our suggested solution
    (basic functionality) is presented here.

    Application for managing the national numbering plan

    The central reference database will contain the national numbering plan. The following
    information is stored for each number series:

           Range holder (operator ID)
           Number type (fixed, mobile, non-geo etc.)
           Status (free, reserved, allocated etc.)
           Time of allocation
           Time of expiration (primarily for historical records)
           Description

    The current national numbering plan (allocations) can be viewed or downloaded at the MNP
    public Web site.

    The MNP system can provide an application to order number series via the MNP Web.
    Typically, this functionality will only be accessible to authenticated users (registered
    members of the MNP).

    To order a new number series, the following procedure can be followed:

        1. The user (network operator) logs in to the MNP Web and orders a new number series
           by filling out a form. The user selects a specific number series from a “drop-down”
           box with currently available (free) number series. If only a part of the number series
           is wanted, this must be specified in a specific text box.
        2. When the user submits the order, two actions applies:
               a. A new record is written to the database (national numbering plan), and the
                    status is set to “not acknowledged” or “reserved”.
               b. An e-mail is generated and sent to the ILR, containing the formal order. The
                    mail recipient can reply to this mail (specific format) to accept or reject the
                    order. Optionally, ILR can accept/reject the order by logging in to the MNP
                    Web.
        3. When the order is responded to, a mail is sent to the requesting operator.
        4. If the order was accepted, the numbering plan is updated (status of record is
           changed). If the order was rejected, the reservation is invalidated.
        5. Optionally, the new, updated numbering plan can be exported to file and sent by e-
           mail to all network operators.

    To hand back a number series, a similar procedure can be used.

    The ILR can also use the MNP Web to explicitly change the information for a number series
    (for example description or status).

    Message recipient resolution

    An important feature arises as the MNP holds the numbering plan. This table decides what
    numbers are valid and portable numbers, letting the system pass any porting order issued
    on any of the numbers or number series listed here. This table, together with the ported
    number table, also facilitates the entering of data in the porting order. The recipient



2.01 MNP Luxembourg - RFP Response.doc                                                         Page 41
Proposal – Bid document


    (requesting) provider need only enter the number or number range to be ported and the
    system finds the correct donor operator to which it will send the order.

    3.5       MNP look-up

    Section       Description                                      Answer          Statement
    (a)           A MNP Look-Up accessible through the …           Acknowledged    Supported
    (b)           As this application is directly connected to …   Acknowledged    Supported

    Detailed description/explanation:
    As part of the public MNP Web site, an MNP Look-Up service will be available. After
    submitting a request for a specific telephone number, the user get hosting provider in return.

    The publicly available Web site resides on a separate security domain of the MNP network
    (dedicated server).

    3.6       Quality of service

    3.6.1 Capacity

    Section       Description                                      Answer          Statement
    (a)           The offered system or service shall be …         Acknowledged    Supported

    Detailed description/explanation:
    The number of transactions handled per hour is fully scalable by infrastructure (hardware
    and bandwidth). The physical database size is also fully scalable, which means that there is
    no practical upper limit for database size.

    Since it is an accepted fact that the future of number portability, such as the number of
    Participants, the amount of portable numbers, the amount of portings per year, the amount
    of transactions on the database (average and peak) and the amount of administration are
    not known at this time, we have by initial design composed a NPS platform that is capable of
    accommodating future expansion to adapt to additional needs in a cost-effective way.

    The inherent modular and scalable design of the NPS component based product ensures that
    the future options of the NPS stays open, both in the obvious face of an accelerating
    technology, but also in relation to the continuously evolution of customer requirements and
    demands.

    Due to the modular structure of our NPS product typical scalable modules are:

          •    Processing power
                  o additional or more powerful CPUs can be upgraded
                  o hardware platform can be upgraded in-server or by adding new servers /
                      server components
                  o task processing can be shared over several servers by using load sharing
                      algorithms
                  o and more…

          •    Data I/O performance
                  o disk subsystems / array performance
                  o IO cards / cache technology
                  o disk performance (spin speed / caching / transfer rates)
                  o and more…

          •    Software performance


2.01 MNP Luxembourg - RFP Response.doc                                                    Page 42
Proposal – Bid document


              o   tuning of message handler and NPS interfaces
              o   single vs multi treading
              o   and more…

    Given already a highly effective data I/O disk subsystem, a typical “tuning” of the system to
    accommodate a more intense message flow, typically will include splitting processes (like
    database processes vs. several application server processes) over separate servers,
    providing parallelism and increased processing power for the installed software processes.

    Data transmission rates are dependant on available bandwidth; the NPS system today is
    transparently able to support TCP/IP communication links from 32 kBit/s (Frame/Relay) to
    100 mBit/s (LAN). It is generally good economics to scale the bandwidth dynamically once or
    twice each year according to proven achieved demands + a 50% peak ceiling, rather than
    paying for unused capacity in order to cope with eventualities in the future.

    There is no inherent maximum limit of any given number of concurrent interface sessions
    against the NPS system. Accordingly, there is no system inherent upper limit on size of
    stored data. Performance will not decrease significantly as the database grows, as long as
    proper database maintenance is performed. and the proper indexes used.

    NPS installation in Norway (NRDB)

    Number of telecommunications providers participating in NP using the NPS:

    Network operators:                  7
    Service providers:                  36

    Number of unique messages processed through the NP Message Central per NP case:

    Per porting of a number:            17 messages (average, normal process)
    Per termination of a porting:       14 messages (average, normal process)

    Total number of unique messages processed through the NP Message Central:

    Unique ported numbers:              504.584 (active numbers per September 30, 2002)
    Unique ported numbers / month:      27.532 (ported numbers during September 2002)
    Unique cases / month:               25.520 (cases completed during September 2002)

    Throughput:

    363.280 messages processed ~ average of 17.300 messages processed per working day
    (messages processed measured during September 2002)

    Current volumes are handled at moderate server utilization loads (multi-server HP LC2000
    infrastructure), and the theoretical maximums at unchanged server platform will be an
    estimated 5-10 fold of current volumes, subject to server scalabilities the maximum
    definition is by these means infinite.

    NPS installation in Portugal (NRDP)

    Number of telecom companies participating in NP using the NPS:

    With physical networks:             14
    With virtual networks:              N/A (not allowed)

    Number of unique messages processed through the NP Message Central per NP case:




2.01 MNP Luxembourg - RFP Response.doc                                                    Page 43
Proposal – Bid document


    Per porting of a number:            14 messages (average, normal process)
    Per termination of a porting:       9 messages (average, normal process)

    Total number of unique messages processed through the NP Message Central:

    Unique ported numbers:              53.600 (active numbers per October 31, 2002)
    Unique ported numbers / month:      11.300 (ported numbers during October 2002)
    Unique cases / month:               2.700 (cases completed during October 2002)

    Section    Description                                       Answer            Statement
    (b)        Even at peak capacity levels, normal system …     Acknowledged      Supported

    Detailed description/explanation:
    The bidder has in his proposal included the necessary infrastructure assuring the purchaser
    the levels of performance at or exceeding those of his reference installations referred to in
    the previous section 3.6.1 (a) of this document.

    Section    Description                                       Answer            Statement
    (c)        Application server, web server and database …     Acknowledged      Supported

    Detailed description/explanation:
    The Bidder has planned to be operating the application server, web server and database
    server on separate physical servers, located in a shared infrastructure rack with firewall
    servers, routers, switches and adequate UPS capacities.

    If capacity requirements are still met the Bidder reserves the opportunity to combine several
    of this services onto shared physical servers, but not to an extent that the strict
    requirements for process uptime and system availability are jeopardized.

    3.6.2 Availability

    Section    Description                                       Answer            Statement
    (a)        The porting process shall be designed in …        Acknowledged      Supported

    Detailed description/explanation:
    The MNP system implements the porting processes and the common Administrative Routines
    in such way that no service interruption occur to the user of a ported number. At all times
    calls made to the user will be successfully routed.

    Section    Description                                       Answer            Statement
    (b)        All involved hardware shall at least be …         Acknowledged      Supported

    Detailed description/explanation:
    By design the Bidder has taken into account the most frequent possible events that may
    affect production uptime. The Bidder’s proposed MNP production site thus includes redundant
    hardware and software to the extent necessary to meet the strict requirements for process
    uptime and system availability.

    Hardware methods used to improve fault tolerance:

        •   RAID 0+1 for performance striping and security mirroring 1:1 of data
        •   Duplicated networking adapters
        •   Duplicated power supplies
        •   Duplicated disk controllers and disk sets
        •   Hot-swap disks and power supplies
        •   Hot-swap PCI card positions



2.01 MNP Luxembourg - RFP Response.doc                                                     Page 44
Proposal – Bid document



    Software / configuration methods used to improve fault tolerance:

        •   Server system fallback to non-failed components
        •   Communication link fallback to non-failed router and network interfaces

    Furthermore the MNP system will be enhanced, at the cost of the Bidder, with one or more of
    the following options, if such reconfiguration is proven necessary, at any time by day-to-day
    operations, to meet the requirements of process uptime and system availability:

        •   The possibility of configuring database-controlled redundancy with warm-standby fail-
            over, each node with a separate data store, the standby server can take over for the
            primary server in case of server break down
        •   The possibility of configuring load balancing, where the application server can be load
            balanced over several application servers, in case the volume of transactions through
            the message / transaction handler can be larger than the processing power of a single
            server can handle without experiencing processing delays
        •   The possibility of configuring routers / firewalls to distribute network traffic away from
            eventual failed or heavy loaded components / servers

    Section    Description                                         Answer             Statement
    (c)        Spare parts availability of all hardware used …     Acknowledged       Supported

    Detailed description/explanation:
    The Bidder guarantees to keep available spare hardware units, equivalent of the hardware
    units as used in the production system, at all time during the contract duration, in such way
    that these can be installed on-site within the requirements of the RFP.

    Section    Description                                         Answer             Statement
    (d)        A mechanism for daily backups of all data …         Acknowledged       Supported

    Detailed description/explanation:
    Data is periodically saved to external backup media. For all production servers, backup is run
    daily.

    The following backup strategy is used:
       • One backup media is allocated to each weekday (Monday to Friday), and one backup
            media is used for the weekend, 2 week sets of media are used, making a total of 12
            media
       • Full backup of different servers are scheduled through the week
       • Incremental backup is performed on all servers every day
       • An additional full backup of all servers is run every Saturday. This media is stored at
            a different site. There are 6 medias of this type, changed every Monday
       • On a regular basis, restore from backup is tested

    In addition to the regular backup activity, all database contents is replicated to a warm
    standby server using a transaction based event log mechanism, eliminating the risk of data
    corruption caused by malicious disk controllers or failed disk i/o at the production servers.

    3.6.3 Security

    Section    Description                                         Answer             Statement
    (a)        As the access to the system is already …            Acknowledged       Supported

    Detailed description/explanation:
    The public Web server does not use any authentication mechanisms.



2.01 MNP Luxembourg - RFP Response.doc                                                       Page 45
Proposal – Bid document


    The application server (SOAP/XML and Web) is accessed via VPN, with inherent
    authentication mechanisms and encryption.

    A username/password scheme is used to log in via the MNP Web and to use the SOAP/XML
    automatic interface.

    Section   Description                                          Answer             Statement
    (b)       Hierarchical levels of access to the porting …       Acknowledged       Supported

    Detailed description/explanation:
    The proposed solution provides several levels of access to the porting application:
           System administrator has access to all parts of the system, and do also manage the
           access rights to all other users.
           Regulators (ILR) has read-only access to all reports and statistics, via the MNP Web
           Operator with read-only access can only view reports and statistics generated for the
           specific operator, via the MNP Web
           Operator with manual port access has full, operator-specific access to the MNP Web
           application
           Operator with system access has access to the SOAP/XML automatic interface

    3.6.4 Test equipment

    Section   Description                                          Answer             Statement
    3.6.4     A test environment shall be offered as an …          Acknowledged       Supported

    Detailed description/explanation:
    The bidder has in his proposal included the necessary infrastructure comprising a test
    environment.

    The test environment is provided with full functionality: both MNP Web and SOAP/XML
    interface. No VPN is used, but the access is restricted with general firewall filtering rules
    (source address and destination port).




2.01 MNP Luxembourg - RFP Response.doc                                                        Page 46
Proposal – Bid document




    4 Pricing

    Section     Description                                                  Answer
    4.1         Pricing for the full service offer                           Acknowledged

    Detailed description/explanation:

    Full service offer:

    The Bidder offers the implementation of the MNP based on the “full service offer”. The bidder
    provides the MNP services as a pay-per-portation model, following a transaction oriented
    payment schedule.

    Terms and definitions:

    The charged fee per ported number is flat regardless of volume.

    The fee per ported number will be charged monthly and contain all portations for the last
    month.

    The fee for the initial connection of a operator will be charged on the date for start of
    number portability production for that operator.

    The fee for the yearly subscription will be charged annually on the first day of the year.

    If an operator enters the MNP system during the year he is charged for 1/12 of the annual
    subscription fee x number of months remaining of the year, current month inclusive. If an
    operator leaves the MNP system during the year he is reimbursed for 1/12 of the annual
    subscription fee x number of months remaining of the year, current month exclusive.

    Choise of hosting configuration:

    The Purchaser has the choice between two main delivery models of the “full service” offer.

    1) Domestic hosting of the Production Site

        •    The Production Site is hosted by the Bidder’s local partner in Luxembourg
        •    The Test Site is hosted at the Bidder’s premises in Norway
        •    The Disaster Recovery Site is hosted at the Bidder’s premises in Norway

    ..or..

    2) Non-domestic hosting of the Production Site

        •    The Production Site is hosted at the Bidder’s premises in Norway
        •    The test and development site is hosted at the Bidder’s premises in Norway
        •    The Disaster Recovery Site is hosted at the Bidder’s premises in Norway

    Both options will provide the Purchaser with optimal data processing security, system
    availability and supreme support and maintenance organizations.

    Due to the Domestic hosting demanding duplication of some infrastructure elements in our
    provided system configuration, the fee per transported number will be slightly higher if such
    domestic hosting of the Production Site is chosen. All other fee elements will stay the same.




2.01 MNP Luxembourg - RFP Response.doc                                                          Page 47
Proposal – Bid document


    Overview of fee elements:




    Inclusive services:

    The MNP operational is offered inclusive of all necessary hardware, network infrastructure,
    internet subscription (for MNP server side), as well as hardware and software support,
    maintenance and related service, according to the RFP and this document. The Bidder also
    provides a manned helpdesk / NP support service related to this proposed delivery.

    Payment schedule:

    To visualize the impact on pricing from changed assumptions related to fluctations in the
    churn and the average portability expectancy rate, we provide the sample payment schedule
    in 3 scenarios in the following:

    We assumes the following constants:

        •   Assuming   non-domestic hosting of the Production Site
        •   Assuming   2 connected full system access operators from 2004
        •   Assuming   3 connected full system access operators from 2005
        •   Assuming   11 connected web only operators from 2005

    Scenario 1

    Number of subscribers                            382.000
    Expected annual growth                           3%
    Expected churn rate                              10 %
    Expected average portability rate of churned     25 %




2.01 MNP Luxembourg - RFP Response.doc                                                   Page 48
Proposal – Bid document


    Scenario 2

    Number of subscribers                          382.000
    Expected annual growth                         3%
    Expected churn rate                            15 %
    Expected average portability rate of churned   35 %




    Scenario 3

    Number of subscribers                          382.000
    Expected annual growth                         3%
    Expected churn rate                            20 %
    Expected average portability rate of churned   50 %




2.01 MNP Luxembourg - RFP Response.doc                       Page 49
Proposal – Bid document



    VAT and local taxes:

    All items are listed exclusive of VAT and eventual local taxes imposed on the delivery. All
    items will be VAT / tax treated according to VAT / tax legislation of the place of rendering the
    service.

    Other terms:

    The Bidder will cover all costs related to his own travel and other expenses in relation with
    the MNP delivery.

    The delivery of proposed system will be according to CTP DDP INCOTERMS 2000.

    Mediation devices (optional):

    Mediation devices are offered inclusive of local data node functionality and remote
    maintenance / support / surveillance managed from the Bidder’s support center, and will
    provide a local access point for all operator usages. The mediation device is offered as a
    complete managed black-box installment.

    Initial establishment fee per operator for a mediation device                   € 30.000
    Basic yearly subscription fee per operator for a mediation device               € 10.000

    Adaptions of mediation device (optional):

    Our mediation devices require adaptation only of the operator specific layer to the operator’s
    protocols and back-end systems. Such adaptation costs may typically range from € 10.000
    to € 15.000 per designed and configured interface, depending on context. Implementation
    will be agreed on directly with each operator, outside the scope of this proposal.

    Extension of the helpdesk service hours:

    An extension of the helpdesk service hours as described in section 2.6 (a) is offered at a
    hourly surcharge of € 85 for the duration of the requested extension.

    General terms for the delivery of additional services outside the scope of this proposal:

    Related to the possibility for the Bidder to provide additional services to the operators
    connecting their system to the MNP system in Luxembourg, we would like to invite all
    inquiries related to our ability to implement such interfacing back office services.

    Hourly rate, certified senior personell                                         € 120

    The stated hourly rate is offered as a frame agreement to all entities requesting the
    specification / design / implementation of additional services in relation to the MDN in
    Luxembourg.

    In addition necessary costs of travel and stay should be agreed according to agreements
    between the parties in question.


    Section   Description                                                    Answer
    4.2       Pricing for the solution offer                                 Acknowledged

    Detailed description/explanation:
    The Bidder does not offer the implementation of the MNP based on the “solution offer”.



2.01 MNP Luxembourg - RFP Response.doc                                                      Page 50

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:2
posted:11/24/2011
language:English
pages:50