Request for Proposals to provide a Mobile Number Portability Administration Service for Rwanda
Issued by the Rwanda MNOs Consortium
Issue Date: 12 March 2025
Response Deadline: 4 April 2025
Issue Control
| Issue No. | Issue Date | Author | Notes |
| Final | 12 March 2025 | RURA | Final |
Table of Contents
2.3 The Rwanda Telecoms Markets. 11
3.1 The Requirements for the MNP Administration Service. 13
3.4 Selection of Possible Consortia. 14
3.5 Mobile Number Portability Working Group. 15
3.6 Establishing and operating a business in Rwanda. 15
4.2 Licensing and Service Levels. 18
4.3 Customisation – MNPAS Service. 20
5.2 Dimensions & Scalability. 22
5.3 Administration Services. 22
5.4 Availability of a MNPAS for test purposes. 23
6 Implementation Timeframe & Project Management. 24
7.1 Section 1 – Executive Summary and Respondent Information. 26
7.2 Section 2 – Service Description and Technical Details. 27
7.3 Section 3 – Implementation Schedule. 27
7.4 Section 4 – Training and Documentation. 28
7.5 Section 5 – Commercial Offer. 29
7.6 Section 6 – Experience and References. 31
7.7 Section 7 – Contractual Details. 31
7.8 Section 8 – Miscellaneous. 32
7.9 Section 9 – Submission Checklist. 32
7.9.1. Submission Checklist Template. 34
8.1 Submission Requirements. 38
8.2 The Licensed Operators Contact Details. 38
8.3 Register of Interested Persons. 39
8.4 Clarification, Questions and Additional Information. 39
8.7 Selection Procedure and Criteria. 40
8.8.2 Submission of Proposals. 42
8.8.3 Selection and Notification of Short-listed Consortia. 42
8.8.4 Presentations by Short-listed Consortia. 42
8.8.5 Selection of and Negotiation with Consortium.. 43
Annex A – MNP Service Design and Operation. 44
A.1 MNP Processes and Transactions. 44
A.2 Customer Validation/ Authorisation Facility. 47
A.4 Cooling Off/ Emergency Repatriation. 48
A.7 Return of Deactivated Number by Recipient Network. 50
A.8 Single Numbers and Number Series. 50
A.9 Range Update – Administrative Function. 51
A.11 Local Database Synchronisation. 51
A.14.1 Investigatory Powers. 52
A.15.2 Reporting/Output Format 54
A.16.3 Number Look-up Facility. 55
Annex B. Technical MNPAS requirements. 56
B.2 Logging of activities and archiving of data. 57
B.3 MNPAS – System Management. 57
B.3.1 Fault Management Functions. 57
B.3.2 Hardware & Software Configuration Management 57
B.3.3 Hardware/Software/Database Platforms. 57
B.3.4 Access to IT, Downloads & Uploads. 58
B.3.5 Connectivity Requirements 58
B.4 Backup, Restore & Disaster Recovery. 59
B.4.1 Real-time Backups Online. 59
C.1 Porting Approval Request. 61
C.2 Porting Approval Response. 61
C.3 Porting Deactivation Request. 62
C.4 Porting Deactivation Response. 63
The Rwanda Utilities and Regulatory Authority (RURA) is the regulatory body responsible for providing recommendations and advice on Telecommunications matters to the Government of Rwanda.
You are hereby invited to participate in the Rwanda Mobile Number Portability Clearinghouse (termed MNP Administration Service) procurement programme by submitting a detailed technical and commercial proposal in compliance to the requirements detailed in this Request for Proposal document.
A licence requirement has been placed on the mobile operators by RURA to implement Mobile Number Portability (MNP) services to consumers in Rwanda.
When considering number portability implementation there are two distinct aspects, administration and call routing. Administration is the set of processes associated with accepting and implementing customer orders to port their number(s). Call routing is the process of correctly connecting a call to the intended recipient. The Licensed operators are looking for a viable, efficient and cost-effective solution for an order handling system which could be fully automated, but should include a centralised reference database. The database should be used to (at least) record some details against all ported mobile numbers. That data will be used by individual operators for call routing purposes.
The MNP Regulatory framework requires operators to implement fully automated order handling systems for the porting of Mobile numbers.
The initial requirement for MNP is to facilitate the Porting of Mobile (mobile to mobile) telecommunications services only. In addition, there are other developments going on in the telecommunications arena, including the alignment to the switching of mobile financial services during the porting process, so any solution should be future proofed in this respect. These aspects should be borne in mind when developing the response.
The Licensed mobile operators consortium invites responses from suitably qualified/ experienced Mobile Number Portability Administration Service (termed MNPAS) suppliers (Consortia) to provide detailed technical and commercial proposals in compliance with the specified RFP requirements to participate in the competitive tender procurement process which will lead (ultimately) to the selection of the preferred bidder. Such a bidder will then provide a solution to the Rwanda licensed mobile operators which will enable them to provide efficient MNP services to mobile subscribers in Rwanda.
This RFP tender document provides detailed technical, operational and commercial procurement requirement information to enable Consortia to prepare and submit detailed technical and commercial proposals with the prescribed format and content for the provision of such a MNP Administration Service, to support and facilitate number portability for mobile and associated services, which will be used by operators of electronic communications services, in Rwanda to effect:
The service will be provided to all mobile operators in Rwanda. The service will NOT be provided to fixed operators in Rwanda nor will be permitted to port fixed voice and associated services.
The MNPAS service will be located and managed within Rwanda, due to national data sovereignty rules.
The contracting arrangement will be through a multi-party contract involving the selected Consortium (referred to as the “Consortium”), comprising of an International Solution Provider responsible for delivering the MNPAS solution and a local Partner.
The international provider will provide and oversee the MNPAS solution deployment, support, hosting arrangements in Rwanda, and the definition of the SLA governing the local partner’s responsibilities. Licensed operators/stakeholders will be party to this contract, ensuring comprehensive coverage of the solution’s design, development, deployment, and operational management to maintain service continuity, performance, and compliance with industry best practices.
In accordance with the recently published Rwanda MNP Regulations, RURA intends to fund the set-up of the MNPAS service using funding from the Rwanda National Universal Access Fund, with the post-launch MNPAS service operational costs being funded jointly by the licensed operators/ stakeholders. The Universal Access Funding arrangements for the set-up of the MNPAS service will be agreed by RURA with the contracting parties but RURA will NOT be party to the multi-party contract between the Consortium and the Licensed operators/ stakeholders.
It is envisaged that there may be a need to enter into a common statutory licensing arrangement issued by RURA.
It is intended that by End-November 2025, mobile telephone service users in Rwanda will be able to keep their mobile numbers, when they change Service Provider.
Respondents are advised that the Licensed operators will consider the future capabilities of the proposed MNP Administration Service solutions to provide Porting in future market sectors, such as alignment to switching of other services such as mobile financial services, fixed voice, broadband and associated service etc, as an assessment criterion and should ensure that their proposals are structured around these requirements.
The Rwanda MNP service will be based on global and regional best practices, including:
The detailed Business Rules framework governing the design and operation of the Rwanda MNP service has been developed and will be provided to the successful Consortium once the selection process is completed; further information is included in Annexes A and C of this RFP document and Consortia are advised to consider the information provided when developing their responses to this RFP.
Rwanda, officially the Republic of Rwanda, is a landlocked country in the Great Rift Valley of Central Africa, where the African Great Lakes region and Southeast Africa converge. Located a few degrees south of the Equator, Rwanda is bordered by Uganda, Tanzania, Burundi, and the Democratic Republic of the Congo.
At 26,338 square kilometres (10,169 sq mi), Rwanda is the world’s 149th-largest country, with an estimated population of 14,414,910 (2024 est.), speaking four official languages, namely, Kinyarwanda, English, French and Swahili.
The leading sectors in the Rwandan economy are driven by energy, mining, agriculture, trade and hospitality and financial services,
GDP for Rwanda was $988.74 per capita in 2024[1].
RURA is the regulatory body responsible for providing recommendations and advice on Telecommunications matters to Rwanda.
All network operators have an individual fixed or mobile service licence issued by RURA. Internet Service Providers (ISPs) are also licensed and may apply for numbers. All licensed operators have a licence requirement to provide number portability, although the ISPs do not. Service Resellers do not require a licence. RURA is of the opinion that the number portability requirements on the licensed operators are ‘passed through’ to resellers.
RURA has decided that the Rwanda telecommunications sector is sufficiently developed to support the introduction of Number Portability services. RURA believes that introducing Number Portability services will directly benefit consumers and will drive competition. RURA confirms that the operators under its direction will be required to develop and deliver the optimum Number Portability solution for consumers in Rwanda.
Rwanda had 13,645,656 mobile subscriptions (pre- and post-paid) in August 2024[2], of which 98.5% were pre-paid and 1.5% were post-paid.
Mobile services are delivered by Airtel, KT Rwanda Networks (KTRN) and MTN using 2G, 3G and 4G technologies.
The respective retail market shares2 for Airtel and MTN were 38.2% and 61.8% respectively. KTRN currently offers 4G data services on a wholesale basis only and also launched retail 4G services, including voice, through a range of ISP retail partners in 2025.
Airtel and MTN offer mobile money solutions through separate corporate bodies regulated by the Rwanda financial services regulator, the Central Bank of Rwanda.
The following Licensees are providing or planning to provide electronic communications services in Rwanda, but only mobile services will be subject to a number portability requirement at the inception of number portability in Rwanda. Fixed services will not be subject to a number portability requirement at the inception of number portability in Rwanda.
Airtel
Airtel Rwanda is a majority owned subsidiary of Bharti Airtel Limited. Airtel Rwanda was formed by the merger of the Rwandan operations of Airtel and Tigo (formerly owned by the Millicom organisation).
Bharti Airtel Limited is a leading global telecommunications company with operations in 16 countries across Asia and Africa. Headquartered in New Delhi, India, the company ranks amongst the top 3 mobile service providers globally in terms of subscribers.
Airtel Africa operates across 14 markets and serves more that 150 million African subscribers.
Airtel Rwanda is licensed to provide 2G/ GSM, 3G/ UMTS & 4G LTE services in Rwanda.
Airtel Rwanda is separately licenced by the Central Bank of Rwanda to offer the mobile commerce service, Airtel Money/ Tigo Cash product (money transfer via the mobile phone).
KT Rwanda Networks (KTRN)
KTRN is a 4G LTE infrastructure company, which offers the wholesale provision of a universal mobile broadband network built on 4G LTE technology.
In June 2013, the Government of Rwanda and KT from South Korea entered into a Public Private Partnership (PPP) to install a wide-ranging high-speed broadband network and expand the nation’s online services capacity, essential for Rwanda`s goals in the ICT sector. KTRN was established to deliver universal broadband access based on world-class 4G LTE technology upon Rwanda’s national fibre optic infrastructure and to manage the fixed-mobile converged infrastructure as the wholesale provider of high-speed mobile broadband, covering 95% of the population.
KTRN was given a monopoly on the provision of 4G LTE services in Rwanda; it operated a wholesale business model selling bulk network capacity to MTN and Airtel. KTRN’s monopoly was terminated by the Government in 2023. KTRN launched retail 4G voice and data services using VoLTE technologies via a range of established Rwanda ISP providers.
MTN
MTN Rwandacell Plc began its operations in 1998, starting out as an exclusive GSM network providing voice and SMS services. The portfolio has exponentially grown to include mobile and fixed data, Mobile Money services, Enterprise solutions and other Value Added Services.
MTN Rwandacell Plc serves its subscriber through a footprint that is covered by 4G, 3G and 2G networks as well as an extensive fiber network.
MTN Rwandacell Plc is publicly listed on the Rwanda Stock Exchange; the company is a subsidiary of the MTN Group Limited which is a South African multinational corporation and mobile telecommunications provider. Its head office is in Johannesburg. As of December 2022, MTN recorded 289.1 million subscribers across its African operations spanning 22 markets.
MTN Mobile Money (MoMo), a subsidiary of MTN Rwandacell Plc is separately licenced by the Central Bank of Rwanda to offer fintech services.
The Consortium will provide the MNP Administration Service which will be a managed service to administer MNP in Rwanda. This functionality will encompass the need to maintain relevant details regarding mobile subscriber number ranges together with the full history of any Porting activity for any particular mobile number and for providing specific statistical information as required by RURA.
This managed solution must be located within Rwanda due to data sovereignty rules and be provided and managed from resilient main and back-up datacentres.
The hardware and software that provides the MNP Administration Service will remain in the domain of the Consortium.
The Consortium should either a) place the Software source code and supporting material into Escrow or b) make arrangements for full copies of the MNPAS porting data and supporting material to be safeguarded and provided to RURA, either in the event of the Consortium or component parties ceasing to trade in the normal course, being the subject of an insolvency event or the Consortium by its fault causing or allowing the software to become obsolete.
In the event that a Licensed operator/ stakeholder requires additional hardware or software in order to provide number portability functionality, such requirement shall be contracted for separately between the Consortium or its other supplier and the Licensed operator/ stakeholder and will not form part of the MNP Administration Service.
The MNP Administration Service and the Consortium will have no proprietary rights to the porting related data collected, managed and stored by the MNP Administration Service. The rights to the porting related data collected, managed and stored by the MNP Administration Service will be defined in the contract between the Consortium and the nominated contracting parties.
The contract between the Consortium and the nominated contracting parties should stipulate that the Consortium may only provide access to porting related data to third parties with the express prior permission of the Licensed operators on the basis of recommendations made by the nominated contracting parties/ MNP Working Group (MNPWG). Third party access to porting related data held by the MNP Administration Service will be subject to commercial arrangements defined in the contracting framework established with the Licensed operators.
This RFP addresses the provision of MNP Administration Service for mobile number portability (MNP) to be implemented at inception. Porting of other service types may be implemented in future.
Respondents are required to indicate in their proposals whether and, if so, how the proposed solution could be expanded to include Porting of numbers between fixed and fixed; fixed (including non-geographic and similar numbers) and mobile; and other services such as VoIP and Electronic Number Mapping (ENUM).
RURA, having regard to the recommendations of the Licensed operators /MNPWG, will be responsible for the regulatory but NOT the contractual arrangements for the provision of the MNP Administration Service. It is expected that the arrangements will take the form of:
The Consortium will charge and invoice the Licensed operators directly for the Porting services provided based on a charging/ cost recovery arrangement and contracting framework to be determined by the Licensed operators and approved by RURA. The licensed operators request, however, that a monthly charging arrangement be provided in the Consortium’s proposal, to enable easier comparison and assessment of proposals received.
The licensed operators would also welcome innovative commercial/ contracting proposals from Consortia in this respect.
The Licensed operators are specifically interested in considering and progressing proposals from Consortia who have been involved with the successful development, implementation and operation of MNP solutions in similar jurisdictions. The selection of the Consortium will be made by the Licensed operators having regard to recommendations made by the MNPWG.
The Consortium will be led by an international provider of the NPC system, who will be the contracting party, which will be hosted in Rwanda.
The local Rwandan partner must meet the following criteria:
An MNPWG has been convened by RURA and is composed of representatives from RURA and each Licensed operator. The MNPWG is chaired by a senior employee of RURA supported by specialist Number Portability consultants.
Further specialist work streams may be established advising and reporting to the MNPWG to support the implementation of MNP in Rwanda. The establishment of further specialist work streams will be ratified by RURA following recommendations received from the MNPWG.
It is not necessary to set up a local company to provide services in Rwanda, but there are a few things to consider.
Although there are no local participation requirements, foreign companies are encouraged to form joint ventures with Rwandan companies or entrepreneurs.
Foreign companies can register a branch in Rwanda for free. Requirements include a power of attorney, notarized copies of the memorandum and articles of association, and passport copies of the shareholders and directors.
The Licensed operators require the service to be provided from or located in Rwanda.
The MNPAS shall be capable of providing, at a minimum, the following functionality:
Each Licensed operator/ stakeholder will use data from the MNPAS to populate its own call-by-call routing databases for All Call Query (ACQ) routing.
The MNPAS will be operated from within Rwanda, but particular importance will be placed upon evidence of the security and reliability of the proposed service, and the Consortium should include information on performance of similar services in, or to, other countries. The Consortium will be required to demonstrate where the MNPAS is hosted/ provided remotely, that the protection of number portability data must be compatible with Rwandan data protection/ privacy legislation. The protection of number portability data will be a parameter within the assessment framework used by the Licensed operators and the MNPWG stakeholders.
The MNPAS should be provided in a manner which will enable secure read access to Porting data by Rwandan Law Enforcement Agencies (“LEA”), subject to compliance with applicable legal requirements, and where appropriate, other stakeholders such as value-added service operators etc, as notified and authorised by RURA.
The Consortium must at all times ensure full compliance with applicable Rwandan data protection laws and other legal requirements for the duration of the contract.
Where the Consortium uses any sub-contractor(s) to provide this MNPAS then the Consortium must demonstrate that the sub-contractor(s) comply with all applicable laws of Rwanda in force from time to time. Notwithstanding and without prejudice to the foregoing, the Consortium shall be liable for any breach of any laws of Rwanda and shall be required under the contractual or licensing arrangement to indemnify the Licensed operators/ stakeholders in respect of any such breach.
The MNPAS must support the generic interfacing requirements specified in this RFP. The Porting specification document is drafted; it will be shared with the winning Consortium during the contract negotiation stage.
It is assumed for this RFP that each Licensed operator has at least one input connection to the MNPAS.
There may be a requirement to licence the MNPAS service in Rwanda.
The multi-party contract for the MNPAS will contain details of the terms under which Service Level Agreements (SLA) will be managed and which the Licensed operator representatives will take part in the Review Meetings. SLAs will be measured monthly. Penalties for failing to meet the terms of the SLA will apply.
The efficient and consistent operation of the MNPAS will be managed through an appropriate SLA framework based on effective financial penalties for breach of defined contractual performance standards.
Although other pricing and charging arrangements will be considered by the Licensed operators, the proposal shall, for the purpose of comparison of proposals submitted, specify prices separately for a 3 year and a 5-year initial period, with reviews at 3-month intervals for the first year and at mutually agreed times between the Licensed operators and the Consortium thereafter.
RURA reserves the right to use a third party to monitor the performance level of the Consortium.
Table 1 below is an indication of the minimum service level requirements that the Licensed operators are seeking from the Consortium. The Consortium’s response should include financial service credits or penalties for failing to meet an agreed service level.
Service Area Specification Minimum Requirement
| Service Area | Specification | Minimum Requirement |
| Availability | Twenty-four (24) hours daily | 99% per Month |
| Response time to requests | Interactive – real time | Refer to process documentation |
| Unplanned Outages | Outages in excess of 30 mins | Less than 2 per month |
| Planned Outages | Outages in excess of 120 mins | None per month |
| Reporting | Availability of Administration System | Weekly |
| Reporting | % of subscribers ported in/out against 2-day target | Daily |
| Operational Desk opening hours | 0800 to 2000 hours – CAT Time zone | 100% per Month |
| Response time after problem is reported | Within 30 minutes | 100% per Month |
| Progress update | Hourly | 100% |
| Resolution Time | To be agreed with MNP Consortium. | |
| Data back-up | Daily | 100% per Month |
| Maintenance window | To be agreed with MNP Consortium. | 100% per Month |
| Notification of planned work | 48 hours | 100% per Month |
| Notification of emergency work | To be agreed with MNP Consortium. |
Table 2: Proposed MNP Administration Service – SLA Framework
The Consortium should give details of ready developed ‘best practice’ Porting rules. The proposal should describe how the Consortium will support Licensed operators in the testing of their systems and processes and should outline the tests that the Consortium would expect to undertake with each of the Licensed operators individually and jointly.
If the proposal includes the need for each Licensed operator to run the Consortium’s proprietary MNP software within its own IT operations, then this section must also cover all the necessary specifications regarding software and hardware that would be required. In addition to the regular operation of the MNPAS, the Consortium must include a section on how they would implement and validate a Disaster Recovery process.
The software used to provide the service should be ‘parameter driven’ (i.e., the software should allow changes to be made in timings, response reasons and other parameters with minimal additional cost).
RURA is proposing that mobile numbers can only be ported within Rwanda. The MNP Service should be configured to separate out and manage the number plan, Licensed operators/ stakeholders and Porting transactions/ history for Rwanda as a separate entity within the central MNPAS. The MNPWG is proposing to develop and operate, where possible, common task driven MNP processes and MNP service functions in Rwanda.
The MNPWG may decide to operate separate Porting processes for the Porting of specific types of services and subscribers, which may require the software to support separate processes with differing time, response reasons and stage parameters. For instance, the MNPWG may decide to allow the Porting of business/ corporate services to be processed during different working hours to the Porting of retail services.
The MNPAS and associated software shall enable additional Licensed operators to be added to the Rwanda MNP Service with minimal disruption to existing Licensed operators, minimal additional costs and minimal implementation timeframe.
The requirements given in this RFP are minimum specifications. The Consortium may propose additional features that they consider will be of benefit to the MNPWG and the Licensed operators.
The Consortium may offer additional support services to the Licensed operators separately for assistance with interconnecting the service to their existing IT and network infrastructure. Such services shall be outside the scope of the services engaged pursuant to this RFP. However, in order to ensure transparency and non-discrimination, the scope and prices of such services must be offered on the same terms and conditions to all Licensed operators.
The Consortium must be able to operate in both the following modes:
The Consortium should describe any capacity limits for its service and any change in pricing that is dependent on the number of portings per year. The latter should be provided based on the following Porting rate bands:
The Consortium should also provide pricing based on an annual subscription which is independent of specific Porting volumes (and therefore not subject to change based on volume increases). Please note – the Porting rate bands are designed to ensure adequate scalability having regard to possible future Porting demand for the mobile Porting service and should not be construed as a prediction or guarantee of anticipated Porting volumes.
In addition to the main MNP functions, the following functions should be included in the proposal:
The Consortium should also state how it would undertake the following:
To enable each of the Licensed operators to prepare their own operations for MNP it will be necessary to provide them with independent access to a fully functional test environment.
This test environment should allow all the Licensed operators to, independently of each other, test their interfaces and IT systems with the solution being provided by the Consortium and to undertake all Porting operations with a “dummy” operator.
This test environment should also be available to allow the Licensed operators to test the inter-operator processes and the passing of messages between each combination of real operators.
It is expected that the Consortium will also make the test environment and facilities available to the Licensed operators to support the implementation and launch of other forms of number portability in future, for instance ENUM portability.
The MNPWG has determined the following key milestones which will be critical in preparing for the launch of the Rwanda MNP service, namely:
iii. Commissioning of the MNP Administration Service and provision of initial documentation by End-June 2025;
viii. Launch of MNP – Anticipated Date: End-November 2025.
The Consortium should specify clearly what it can deliver within the timescales outlined in this RFP.
The MNPWG will work with the relevant members of the Consortium’s project team on an as required basis. When necessary, members of the Consortium’s project team will be invited by the MNP project team meetings to discuss the MNP Administration Service and associated activities.
An overall MNP Programme plan, covering all aspects of delivering the MNP Administration Service, is being developed and will be made available to the successful Consortium during the inaugural project meeting.
The acquisition of the MNP Administration Service forms one critical element of the overall MNP Programme.
Consortia are advised of the following:
All proposals must comply with the format set out in this section in order to ensure that the information is presented in a manner which can be evaluated fairly and effectively. While failure to comply with this format will not disqualify a Consortium, it may prejudice the proposal in relation to others submitted in accordance with the required format.
Proposals should be clearly divided into sections, headed as follows and containing the relevant information in each part.
Section 1 – Executive Summary
Section 2 – Service Description and Technical Details
Section 3 – Implementation Schedule
Section 4 – Training and Documentation
Section 5 – Commercial Offer
Section 6 – Experience and References
Section 7 – Contractual Details
Section 8 – Miscellaneous Information
Section 9 – Submission Checklist
The remainder of this section sets out a brief summary of the information that should be included in each section of the Proposal.
The proposal should be prefaced with an Executive Summary which highlights the salient points of the Consortium and its proposal.
This section should also include detailed information about the Consortium firm(s), including:
Incorporation: Provide full company incorporation and business registration information.
Contact Details and Location: Provide contact details and information which outlines the control and guidance of the firm.
Ownership: Identify all shareholders of the Consortium if private, or for a public company, all shareholders owning more than 5% of the issued share capital, including names, addresses and shareholding. Such declarations should also identify the ultimate as well as immediate shareholder(s) as well as identifying any potential conflict of interest with any interested party involved in MNP Administration Service procurement programme.
Financial Statements: Provide complete audited Financial Statements for the preceding financial year, if available. For Consortia which are not required by law to produce and file audited statements in their country of incorporation, unaudited financial statements certified by the Chief Financial Officer of the company may be submitted.
Financial References: Provide two (2) original reference letters from recognized, regulated financial institutions. References must be addressed to the Rwanda MNOs Consortium and must be dated no more than thirty (30) days prior to the date of the application.
This section of the proposal should cover the specific details of the MNP Administration Service which would be supplied by the Consortium, including all technical specifications, in accordance with Sections 4 and 5, as well as Annexes A through to C attached to this RFP. Consortia can organise the information in any format within this section but should be sure to cover or respond to all of the issues set out in the relevant sections of the RFP.
The Consortium should demonstrate that it is compliant with the necessary conditions for proprietary elements that are included in their solution.
A detailed schedule for the implementation of the MNP Administration Service which meets the requirements for MNP launch must be included in the proposal. All relevant activities should be included, together with any relevant dependencies between tasks. Where possible the information should be presented both as a list of tasks as well as in Gantt chart format.
The activities must include, at a minimum, the following milestones:
A project plan will be prepared by the MNPWG and the Consortium with critical milestones identified and responsibilities assigned. For each week of delay relative to a critical milestone caused by the successful Consortium a global discount of 5% will be applied to the overall amounts to be invoiced, either before or after the service launch date. If the successful Consortium misses three critical milestones by a week each but still reach the final date on time, the successful Consortium loses 15%.
If the cumulative delay exceeds 12 weeks, the contract may be terminated with no further payments being made to the Consortium.
The proposal must contain proposals for conducting all necessary and appropriate training for relevant staff of the Licensed operators and MNPWG staff.
The training should be appropriate for:
Training should be quoted for, at a minimum, the following three cases:
TM 2 shall take place at the Licensed operators’ premises in Rwanda, while TM1 shall take place at the location where the Successful bidder has the appropriate infrastructure and the required environment in order to deliver the training TM1.
TM 1 will start immediately after the signature of the contract.
TM 2 will start immediately after the delivery and installation of the MNP Administration Service in Rwanda.
Note: In case TM 1 takes place outside of the country, the Licensed operators and the MNPWG shall be responsible for travel related costs and living expenses of the trainees.
All costs for training modules TM1, TM2 and TM3 shall be included in the basic “usage” or annual subscription-based pricing.
Detailed technical and operations manuals for the service should be delivered by the time the initial set-up has been completed with one hard copy and one soft copy being made available to each of the Licensed operators and the MNPWG. Please describe the documentation structure:
Proposals should include a detailed commercial offer setting out all prices for the MNP Administration Service, including charges for all necessary services included, as well as other likely incidental or additional charges, and any optional features. Prices should be shown both inclusive and exclusive of VAT and withholding tax.
Proposals should clearly identify the pricing for the elements of the MNP Administration Service which are provided locally within Rwanda and those provided outside of Rwanda.
The price must be based on the information and requirements listed throughout this RFP. Any assumptions made must be explicitly stated. All prices must be stated in Rwandan Franc (RWFs) and valid for 180 days from the submission deadline.
The commercial offer should be structured as follows:
Prior to submitting its proposal, the Consortium should carefully consider the nature and scope of the work to be done as well as any difficulties involved in its proper execution. Consortia must include all costs necessary to cover all contingencies essential to successfully implement and commission the MNP Administration Service. Any cost that is not specifically itemised shall not be considered part of the proposal unless specifically referenced in a separate document and agreed in writing by the Licensed operators. No claims for compensation will be considered or allowed for extra work resulting from non-observation of this stipulation.
This section of the proposal should describe all other similar MNP projects that you have undertaken within the past five (5) years and give contact details for the regulatory and operator customers involved. The Consortium must have undertaken at least two (2) similar MNP projects within the past five (5) years to be considered for this contract.
The details of each project should include a description of the service/system provided, the period when the project was handled, the contractual framework used, the current status (completed or on-going), and the entities (regulator and all operators) involved in the projects.
Contact details should include the name and address of the regulator or operator(s) involved; the name of relevant contact person(s); and their email addresses. The Licensed operators reserve the right to contact and request references and verification of information from the persons identified. Consortia should identify those customers that may be willing to provide a demonstration of the service/system to the Licensed operators and the MNPWG.
The Consortium should include a clear statement in their proposal that there is no conflict of interest with any operator or party licensed by RURA to provide telecommunications services in Rwanda, and/or that it shall not place itself in such a position. The Consortium shall disclose any matter which in its view may breach such a conflict of interest.
The proposals should include full details of any specific contractual arrangements required or proposed by the Consortium, having regard to the RURA potential consideration licensing of and the Licensed operators contracting for the MNP Administration Service.
The successful Consortium will comply with all Rwandan laws, codes, ordinances, rules and regulations applicable to the work being performed.
If the successful Consortium decides to use the services of one or more sub-contractors, the involvement of such sub-contractors shall be subject to approval. The Consortium retains full responsibility for all actions and quality of workmanship of sub-contractors, and the meeting of all deliverables.
The Consortium should include the services of a competent Project Manager who has the authority to act for the Consortium during the whole duration of the project, from specification collection through to public launch of the service. The Project Manager will manage the project until the final sign-off of the service.
In this section the Consortium may include any further or additional matters relevant to the proposal not covered in the sections above.
In this section, the Consortium is required to complete the submission checklist using the template and terminology outlined in this section to verify their proposal is complete and to indicate the level of compliancy of the proposal to the key requirements of the RFP. The completed table should be included in the proposal document.
Where the checklist specifies “Noted?”, the Consortium is required to enter the word “Noted and Understood” to confirm that they understand the requirement or obligation specified in the relevant section of the RFP.
Where the checklist specifies “Compliant?”, the Consortium should ONLY enter the following responses based on their level of compliancy to the requirements or obligations specified in the relevant section of the RFP: –
| RFP Clause Reference | Description | Noted/ Compliant | Respondent Response | Respondent Comments |
| 1 | Introduction | Noted | ||
| 2 | Rwanda & Telecommunications Operations | Noted | ||
| 3.1 | The Requirements for the MNP Administration Service | Noted | ||
| 3.2 | Future Developments | Noted | ||
| 3.3 | Contract Structure | Noted | ||
| 3.4 | Selection of Possible Consortia | Compliant | ||
| 3.5 | Number Portability Working Group | Noted | ||
| 3.6 | Establishing and operating a business in Rwanda | Noted | ||
| 4.1 | The Service Required | Compliant | ||
| 4.2 | Licensing and Service Levels | Compliant | ||
| 4.3 | Customisation – MNP Administration Service | Compliant | ||
| 5.1 | Automation | Compliant | ||
| 5.2 | Dimensions & Scalability | Compliant | ||
| 5.3 | Administration Services | Compliant | ||
| 5.4 | Availability of MNP Administrative Service for test purposes | Compliant | ||
| 6 | Implementation Timeframe & Project Management | Compliant | ||
| 7.1 | Section 1 – Executive Summary and Respondent information | Compliant | ||
| 7.2 | Section 2 – Service Description and Technical Details | Compliant | ||
| 7.3 | Section 3 – Implementation Schedule | Compliant | ||
| 7.4 | Section 4 – Training and Documentation | Compliant | ||
| 7.5 | Section 5 – Commercial Offer | Compliant | ||
| 7.6 | Section 6 – Experience and References | Compliant | ||
| 7.7 | Section 7 – Contractual Details | Compliant | ||
| 7.8 | Section 8 – Miscellaneous | Noted | ||
| 7.9 | Submission Checklist | Compliant | ||
| 8.1 | Submission Requirements – both documents password protected | Compliant | ||
| 8.1 | Submission Requirements – Email Submission of Response by Deadline Date – 4 April 2025, 15.00hrs Rwanda Time | Compliant | ||
| 8.1 | Submission Requirements – Email Submission of Technical Password at 16.00hrs Rwanda Time on 4 April 2025 | Compliant | ||
| 8.2 | The Licensed operators Contact Details | Noted | ||
| 8.3 | Register of Interested Persons | Compliant | ||
| 8.4 | Clarification, Questions and Additional Information | Noted | ||
| 8.5 | Expenses | Compliant | ||
| 8.6 | Confidentiality | Compliant | ||
| 8.7 | Selection Procedure and Criteria | Noted | ||
| 8.8.1 | Issue of RFP | Noted | ||
| 8.8.2 | Deadline of Submission of Proposals | Compliant | ||
| 8.8.3 | Selection and Notification of Short-listed Respondents | Noted | ||
| 8.8.4 | Presentations by Short-listed Respondents | Noted | ||
| 8.8.5 | Selection of and Negotiation with Consortium | Noted | ||
| A.1 | MNP Processes and Transactions | Noted | ||
| A.2 | Customer Validation/ Authorisation Facility | Compliant | ||
| A.3 | Cancellation | Compliant | ||
| A.4 | Cooling Off/ Emergency Repatriation | Compliant | ||
| A.5 | Onward Porting | Compliant | ||
| A.6 | Deferred Porting | Compliant | ||
| A.7 | Return of Deactivated Number by Recipient Network | Compliant | ||
| A.8 | Single Numbers and Number Series | Compliant | ||
| A.9 | Range Update | Compliant | ||
| A.10 | New Operators | Compliant | ||
| A.11 | Local Database Synchronisation | Compliant | ||
| A.12 | Quota Management | Compliant | ||
| A.13 | Response Reasons | Compliant | ||
| A.14.1 | Investigatory Powers | Compliant | ||
| A.14.2 | Interworking with the Rwanda Mobile Financial Services Platform (RSwitch) | Compliant | ||
| A.14.3 | Service Usage | Compliant | ||
| A.15.1 | Statistics | Compliant | ||
| A.15.2 | Reporting/ Output Format | Compliant | ||
| A.16.1 | Number Range | Compliant | ||
| A.16.2 | Number Lengths | Compliant | ||
| A.16.3 | Number Look-Up Facility | Compliant | ||
| B.1 | Data Record Structure | Compliant | ||
| B.2 | Logging of activities and archiving of data | Compliant | ||
| B.3.1 | Fault Management Functions | Compliant | ||
| B.3.2 | Hardware & Software Configuration Management | Compliant | ||
| B.3.3 | Hardware/ Software/ Database Platforms | Compliant | ||
| B.3.4 | Access to IT, Downloads & Uploads | Compliant | ||
| B.3.5 | Connectivity Requirements | Compliant | ||
| B.3.6 | Interface Protocols | Compliant | ||
| B.4.1 | Real-time Backups Online | Compliant | ||
| B.4.2 | Full Backup | Compliant | ||
| B.4.3 | Restore | Compliant | ||
| B.4.4 | Disaster Recovery | Compliant | ||
| B.5 | Availability | Compliant | ||
| B.6 | Additional Features | Noted | ||
| C.1 | Porting Approval Request | Compliant | ||
| C.2 | Porting Approval Response | Compliant | ||
| C.3 | Porting Deactivation Request | Compliant | ||
| C.4 | Porting Deactivation Response | Compliant | ||
| C.5 | E164/E214 Ported | Compliant | ||
| C.6 | E164/ E214 Terminated | Compliant |
Consortia must submit their response and all associated documents in accordance with the following guidelines ONLY:
Soft Copy Submission
An email titled “PROPOSAL FOR A MOBILE NUMBER PORTABILITY ADMINISTRATION SERVICE” containing both the technical proposal and commercial offer as separate attached files (MS Word or PDF) and addressed to the Rwanda MNOs Consortium.
BOTH ATTACHED FILES SHOULD BE PASSWORD PROTECTED WITH DIFFERENT PASSWORDS.
COMPLETE PROPOSALS MUST BE RECEIVED BY NO LATER THAN 15.00HRS RWANDA TIME, ON THE RESPONSE DEADLINE DATE OF 4TH APRIL 2025. LATE RESPONSES OR SUBMISSIONS SHALL NOT BE ACCEPTED.
The password for the technical proposal should be emailed one hour after the response deadline, i.e. 16.00 hours Rwanda time on 4th April 2025. Respondents will be asked to email the password for their commercial offer at a later date.
Both emails should be sent to MNPRFP@rura.rw
Email submissions will be accepted and only in accordance with the above. In no circumstances should a Respondent submit its response or any part of it to any person at the Licensed operators or RURA physically, via fax, or any other method of submission whether in addition to or instead of the above.
The contents of the Proposal will be incorporated into the contractual and licensing arrangements between the Consortium and the Licensed operators. The Licensed operators underline the importance of receiving honest, true and full answers to the questions asked in the RFP.
Failure to comply with all the above submission requirements (including passwords) may result in rejection or disqualification of the application.
All other correspondences with the Licensed operators will be in writing via email to MNPRFP@rura.rw.
Any suitably qualified/ experienced vendor is welcome to participate in the RFP. Invited parties interested in submitting proposals are advised to send an email to MNPRFP@rura.rw to register their interest with the Licensed operators as soon as possible, and in any event, prior to 19th March 2025.
The email should have as its subject “REGISTRATION – MNP REQUEST FOR PROPOSALS” and should contain all of the following information:
Name of Interested Party (Company Name)
Name of Contact Person
Email address
Mailing address
Telephone number
Fax number
The Licensed operators will create and maintain a confidential register of all persons who have registered their interest, which will be used to advise any relevant information relating to this RFP and the selection process, including responses to relevant questions and requests for clarification, and date and other changes to the process. The names of persons included in the register will not be disclosed by the Licensed operators to any person other than the members of the MNPWG, who are employees of the Licensed operators/ stakeholders themselves under a duty of confidentiality.
Failure to register will not disqualify an interested person from submitting a proposal in response to the RFP; however, the Licensed operators only commit to provide updates and supplemental information to persons that have registered by the date set out above and will not be responsible for any deficiency in any proposal which occurs as a result of failure to receive information which would have been provided to registered persons.
Persons requiring clarification or additional information regarding any matter involving this RFP or the process should forward them in writing to the Licensed operators using the contact details set out in 8.2 above, with the subject “MNP Administration Service RFP question“. Questions must include full contact details (mailing address, email address and phone number) of the enquirer. Please indicate if the question is of a general nature or if it relates to a specific point in the RFP and if so which one.
Receipt of questions will be acknowledged and questions answered, via email as soon as practicable.
Responses that the Licensed operators determine to be of general interest to all prospective RFP Consortia will be distributed via email to all registered Interested Parties (concealing the identity of the questioner). If a question cannot be answered within five (5) working days of receipt or at the latest seven (7) days before the Submission Deadline, the Licensed operators will inform the questioner.
Requests for further information or clarification will not be accepted after 24th March 2025.
Each Consortium shall remain liable for all costs it may incur in connection with this RFP process and the Licensed operators cannot assume any responsibility to compensate.
The Licensed operators are not obliged to accept any proposals.
Each Consortium shall regard all information provided by the Licensed operators to them pursuant to their involvement in this RFP process as strictly confidential.
Consortia may also be required to sign a formal Agreement of Confidentiality (also referred to as a “Non-Disclosure Agreement”) prior to being invited to give a presentation or qualifying for further dialogue. If you are short-listed, a copy of the Agreement of Confidentiality will be sent to you. This document should be reviewed by your organisation and be signed prior to discussion with any of the Licensed operators and where appropriate, the MNPWG.
Any material or information received from the Licensed operators is considered property of the Licensed operators and must not be shared with or distributed to any third party without prior written consent of the Licensed operators.
The Licensed operators reserve the right to have any proposal received, reviewed and evaluated by any person at the discretion of the Licensed operators including non-allied and independent consultants retained by the Licensed operators, now or in the future.
The submission provided by the Consortium will be shared with the MNPWG participants who will be bound by the same confidentiality obligations as the Licensed operators.
The Licensed operators will evaluate the proposals based upon the submission, and any specifically requested presentations only, and based on their compliance and satisfaction of the matters set out in this RFP. All aspects of the proposal will be taken into consideration, including the price and commercial terms and conditions, based on the following weightings:
| MNP Administration Service specifications, including technical and administrative features and capabilities – This criterion will focus, but is not limited to, consideration of information contained in Sections 1, 2 and 4 of the Proposal.
|
35% |
| Commercial proposal, including price and all terms and conditions – This criterion will focus, but is not limited to, consideration of information contained in Sections 5 and 7 of the Proposal.
|
30% |
| Respondent’s experience and expertise – This criterion will focus, but is not limited to, consideration of information contained in Section 6 of the Proposal.
|
20% |
| Implementation schedule and timeframes – This criterion will focus, but is not limited to, consideration of information contained in Section 3 of the Proposal.
|
15% |
The Licensed operators and MNPWG reserve the right to choose freely amongst Consortia, selecting any or none – or to use the quotation as a basis for a further dialogue with any or all Consortia. Commencement of negotiations with any Consortium shall not be construed as a commitment by the Licensed operators to enter into any form of contract with the Consortium.
This RFP has been issued by the Licensed operators on 12 March 2025.
Any suitably qualified/ experienced vendor is welcome to participate in the tender process. Eligible parties interested in submitting proposals are urged to register with the Licensed operators as soon as possible and in any event prior to 19 March 2025 in accordance with section 8.3 above.
COMPLETE PROPOSALS MUST BE ADDRESSED TO THE RWANDA MNO’S CONSORTIUM AND RECEIVED BY NO LATER THAN 3:00 PM, RWANDA TIME, ON THE RESPONSE DEADLINE DATE OF 4 APRIL 2025. LATE RESPONSES OR SUBMISSIONS SHALL NOT BE ACCEPTED.
All questions relating to this RFP should be submitted by email to MNPRFP@rura.rw.
Only soft copy email submissions are accepted and only in accordance with section 8.1 above.
The MNPWG, will conduct a preliminary evaluation of all proposals received by the deadline time and date and will select a shortlist of those Consortia with whom the MNPWG wishes to engage further. The MNPWG expects to short-list no more than three (3) Consortia but reserves the right to short-list more should the Licensed operators and the MPWG consider it appropriate to do so.
The Licensed operators via the MNPWG will advise all short-listed Consortia via email as soon as the short-list is selected, which email will also consider details regarding the further phases of the selection process. Short-listed Consortia will also be required at this stage to provide a copy of proposed draft terms and conditions for development, implementation and provision of the MNP Administration Service, in the form of a draft contract.
Consortia not included in the short-list will also be notified at this time, by the Licensed operators via the MNPWG may decide (based on the outcome of the remainder of the selection process) to reconsider Consortia that are not shortlisted in the event that it is unable to finalise a selection of one of the short-listed Consortia.
The short-listed Consortia shall be subject to further technical and commercial evaluation (and clarification if required) conducted by the Licensed operators and the MNPWG. This further evaluation may include the making of a presentation by each short-listed Consortium, as well as the Licensed operators making enquiries of references provided by the Consortium.
It is expected that presentations, if required will be held during April 2025, either remotely or in Rwanda.
The Licensed operators reserve the right to operate a second shortlist phase, in which the Licensed operators and the MNPWG may require to meet with the Consortia selected to attend to engage in more detailed technical, operational and commercial discussions. An agenda for the second short-list phase will be provided to the selected Consortia ahead of the proposed meetings.
Following the presentations and any meetings, the Licensed operators and the MNPWG will conduct its final evaluation and select its preferred Consortium. The selection shall at this stage remain subject to successful commercial negotiation of the terms and conditions of the development and implementation contract, and the MNP Administration Service licence (if needed). The MNP Administration Service should become available for acceptance testing by the Licensed operators as soon as possible and no later than End June 2025. From this date through to the public launch date of End November 2025, the Consortium should work closely with the Licensed operators (via the MNPWG) to ensure full compliance is achieved.
This document is intended to provide an outline of the likely processes that will be involved in number portability in Rwanda, to enable Consortia to present comparable proposals in response to this RFP. Except as specifically identified, the processes set out in this section are indicative only and are subject to change. The MNP Business Rules, Porting specification and Routing specification documents will be provided to the successful Consortium during the course of negotiations for the detailed terms and conditions of the contract.
The MNP process in Rwanda will be Recipient Led and task driven. Therefore, the Recipient Operator will initiate all MNP procedures and the Donor Operator will provide responses.
The proposed role of the MNPAS is to log and enable the management and delivery of the MNP transactions between the Recipient and Donor Operators, and to ‘Broadcast’ the results of each successful Porting. In addition, the MNPAS will receive and check the Call Line Identifier (CLI) and subscriber validation message (i.e., SMS messages) from the Porting subscriber and notify the subscriber of the status and progress of their Porting request by SMS.
The MNPWG intends to simplify the Porting process and minimise the amount of subscriber Porting data transferred in each Porting transaction. The MNPWG intends that transactions in the Porting process will be message driven and no files will be exchanged between Recipient and Donor operators via the MNPAS.
The following process diagram shows the various steps that would be taken during a full MNP process for the Porting of mobile numbers. It should be noted that the timeframes, and principles set out in the tables are indicative only and included to enable presentation by Consortia of comparable responses. Actual timeframes and processes to be implemented are subject to the MNPWG process and ratification by RURA so the successful Consortium must be prepared to adapt its system to the actual timeframes specified by the MNP Business Rules. Further, the Business Rules and Porting process details have been approved by RURA and provided to the Consortium:
Figure A1: Proposed Rwanda Mobile MNP Process Flow
A check is made between the MNPAS and the subscriber that will not be passed if the Recipient Operator has made an error in entering the number to be ported or the number being ported is either already subject to a Porting request or has been recently ported within a defined timescale.
The diagram shows only the main elements of the MNP process. The details need to be discussed and will be specified in relation to each of the different types of account:
This information will be given in the detailed inter-operator Business Rules. The process specifications will be developed and finalised as part of the MNPWG process.
Once the Recipient Operator has submitted the Porting request to the MNPAS and this has been matched against an incoming validation mechanism (i.e., SMS from the subscriber), the MNPAS performs checks to confirm the validity of the number to be ported and whether this has been ported recently within the onward Porting time period. If the Recipient Operator has made an error in entering the number/ service type to be ported or an error in entering the correct Donor Operator or the number being ported is either already subject to a Porting request or has been recently ported within a timescale defined by the Business Rules, then the MNPAS will reject the Porting request and notify the Recipient Operator via a reject code and the subscriber via SMS.
Where the MNPAS matches the Porting request with the corresponding subscriber validation message, verifies that the number is correct and has not been previously ported within the Onward Porting period, the MNPAS shall approve the Porting request and forward the request to the Donor Operator for processing and approval. The MNPAS shall also send an SMS to the subscriber to confirm the Porting request is being processed.
The Donor Operator shall then verify the Porting request against fixed parameters defined by Business Rules. Where the Porting request complies with the Business Rules parameters, the Donor Operator shall approve the Porting request and send approval to proceed to the Recipient Operator via the MNPAS. Where the Porting request fails to meet one or more of the Business Rules’ parameters, the Donor Operator may reject the Porting request and notify the Recipient Operator of the reason for rejection by sending a specified MNP rejection code.
Porting must be completed within a timescale which is to be determined by the Business Rules based on recommendations from the MNPWG. For the purpose of this RFP, the timescale should be assumed to be no more than one (1) working day for mobile service porting from the MNPAS validating thalso consider e Recipient Operator’s Porting Approval Request with the subscriber’s received validation message and forwarding to the Donor Operator for approval.
T1 is the time limit for the Donor Operator to respond to the Porting Approval Request from the Recipient Operator. The response may either be an “Accept” or a “Reject”. Where it is a “Reject” response, the code(s) relating to the reasons for issuing a Reject must be included in the Response message.
There will be a time period during which the Donor Operator must provide a Porting Approval Response to the Recipient Operator’s Porting Approval Request.
Assuming the Donor Operator approves the Porting Approval Request (by sending the Porting Approval Response), T2 is the period to allow the Recipient Operator to activate the number on their network and send the Porting Deactivation Request. During T2 the number is active on the Recipient Operator’s network and the Donor Operator’s network since there is an overlap before it is deactivated on the Donor Operator.
The MNPAS then initiates a Broadcast by sending an E.164 message to all Licensed operators/ stakeholders informing that the number is now activated on the Recipient Operator. The Porting is now complete.
Operators in Rwanda currently use ETSI routing and interconnection approaches which will influence the requirements and operation of the All-Call Query (ACQ) direct routing approach to be used in Rwanda to support the operation of the MNP service. RURA will seek the recommendations from the MNPWG of the most appropriate ACQ routing approach to be adopted and used in Rwanda, i.e., ETSI Network Level Routing approach.
T3 is the time limit for the Donor Operator to de-activate the number and apply onward routing.
The MNPAS will monitor the progress and collect statistics on the processing of Porting transactions across all parties.
In the event problems are experienced whilst a Porting request is being processed, the Licensed operators involved should be able to abandon the process through the use of timing out functions and to start the Porting process from the beginning once the problem(s) have been identified and resolved.
A number may be ported more than once and may be ported back to the original range holder. It will be necessary to specify minimum periods between each Porting, known as Onward Porting and Cooling Off periods.
The proposed MNPAS will be required to match the subscriber’s CLI and/ or a subscriber validation message with each Porting request to enable the Porting request to be processed.
Mobile number Porting requests may be validated by subscriber: –
The proposed MNPAS should store incoming Porting approval requests and subscriber validation messages for a period to be defined in the detailed process. As soon as there is a match between a Porting approval request and a subscriber validation message (i.e., the Porting request numbers match AND the CLI, then the system shall send the Porting approval request to the Donor Operator. If a match is not achieved by a time to be specified in the detailed process, then the MNPAS shall delete the Porting approval request and the validation message.
The proposed MNPAS is required to notify Porting subscribers via SMS message, of the progress of their Porting request. Such notification may include: (i) confirmation that the Porting request has been approved and is being processed; or (ii) Porting request has been rejected; or (iii) advising the subscriber that their service is about to be transferred to the recipient operator etc.
The MNPAS should be capable of recording and reporting the data related to all initiated Porting requests, irrespective of whether Porting requests are completed or aborted.
Final decisions as to cancellation remain to be determined.
For the purpose of this RFP, Consortia should assume that the subscriber may only cancel a Porting request by contacting the Recipient Operator before the point at which the MNPAS has matched the incoming Porting approval request and validation message and forwarded the Porting approval request to the Donor Operator. The subscriber may therefore cancel a Porting request by NOT sending the validation message. If the subscriber wishes to cancel the Porting after the validated Porting approval request has been forwarded to the Donor Operator, this can only be facilitated by allowing the Porting request to proceed to completion and for the Recipient Operator to arrange for the subscriber’s number to be ported back to the Donor Operator via the Cooling Off facility. Thus, there is no need for a specific cancellation process between the Donor Operator and Recipient Operator.
A determination as to whether or not to allow a cooling-off period, and the exact terms of any such period, remains to be made.
For the purpose of this RFP, the MNPAS assumes that a subscriber who wishes to cancel a port (i.e., to return to the Donor Operator after the Porting transaction has been completed), will have to request the Recipient Operator to arrange a second Porting in the reverse direction after the Porting has been completed. Similarly, if a Porting transaction is later found to be fraudulent or not authorised by the legitimate subscriber, then the number(s) will be returned to the Donor Operator.
The MNPAS shall verify and allow the second/ return Cooling Off Porting request to proceed, only if the return Porting approval request stipulates the previous Donor Operator is the new Recipient Operator and the reverse/ return Cooling Off Porting request is received within the specified timeframe defined in the MNP service Business Rules. For clarity the MNP process timeframes for onward porting restricted periods and Cooling Off may be different. All other Porting approval requests which stipulate a different operator from the original Donor Operator should be assessed against the Onward Porting rules/ checks and rejected by the MNPAS as appropriate.
The Emergency Repatriation function will work in a similar manner to the reverse/ return Cooling Off porting function but will only be used when the original/ previous Porting transaction is proved to be fraudulent or inappropriate. Unlike the reverse/ return Cooling Off porting function, the availability of the Emergency Repatriation function will not be time bound or time restricted.
The MNPAS should include the facility to prevent subscribers Porting onwards to another Operator (other than the Donor Operator in the case of Cooling Off requests) within a period of time to be specified in the detailed business rules. This facility may be required to prevent the unnecessary use, or the abuse of Porting resources.
The MNPAS should be capable of checking the previous Porting dates of numbers that are subject to new Porting requests, and where the previous Porting date is less than the specified Onward Porting time limit, the MNPAS should reject such Porting requests as part of the validation of Porting approval requests prior to or after matching with the corresponding validation message. In such cases, the MNPAS should be capable of generating a reject response code back to the Recipient Operator and notifying the subscriber of the rejection of the Porting request by SMS.
The MNPAS should be capable of allowing subscribers to port their number within a specified period of time in the future, to enable subscribers to be able to select Porting dates which are convenient.
The MNPAS should be capable of allowing Recipient Operators to input future Porting dates within the specified period. In such cases, the MNPAS will only commence the processing of the corresponding Porting approval requests at a time to enable the requested Porting date to be met. Validation checking and matching of the subscriber’s validation message by the MNPAS may be completed at the time the Porting approval request is submitted to the Donor Operator. The requirement to operationally include the Deferred Porting facility and the corresponding Deferred Porting period will be determined at a later date.
In normal circumstances at the end of the Quarantine period a number that is part of the number block allocated to that Licensed operator/ stakeholder can be re-allocated to a new subscriber.
When service on a ported number ceases, the recipient shall send an E.164 terminated message to the MNPAS and the Consortium shall: (i) quarantine the terminated number for a specified period of time; (ii) inform the number range holder that the number is available to be returned to their number stock; and (iii) delete the number from the list of ported numbers. The MNPAS shall allow the number range holder to process a Porting request to transfer the deactivated number from the Recipient Operator to its own number stock.
The following processes must be supported by the Consortium:
A.8.1 Porting of a single number as a single two-stage transaction; whereby the Recipient Operator submits a Porting approval request which is then verified by receipt of a validation message from the subscriber’s number to be ported (as outlined in section 6.2). Once both the Porting approval request and subscriber validation message are received and matched by the MNPAS, the Porting request is processed, the Consortium performs the specified validation checks and if successful, passes the validated Porting approval request to the Donor Operator for action.
In addition, the Consortium should specify how the MNPAS supports either expansion to support the porting of additional or evolving telecommunications services both currently and in the future, for instance, fixed voice services, broadband/ ancillary services, as well as interacting with the process for switching
A.8.2 Porting of multiple numbers (either random or a DDI block): Non- Contiguous or Contiguous blocks of numbers should be handled as a single transaction, with the first and last number of the block being entered. In either case, the MNPAS should be able to process the Porting of multiple numbers either in contiguous or non-contiguous blocks by offering both the number verification options detailed below: –
NOTE: in A.8.2a., the Donor Operator may either “Accept” or “Reject” the entire number block only, but if one or more numbers within the block have failed the Donor Operator’s validation, then the Donor Operator must reject the entire porting request and all the numbers contained therein are rejected en masse. The Donor Operator must be able to identify the number(s) which have failed the validation checks and identify the reason/ rejection code against each rejected number.
The MNPAS should support the addition of new number ranges and/or prefixes granted to an Operator.
The MNPAS should support the addition of new operators, and merger or removal of existing Operators and the corresponding number ranges and prefixes.
The MNPAS should provide database synchronisation files on a continuous basis to enable Operators to check the synchronisation of their local routing databases with the central reference database.
The MNPAS should update the database synchronisation files every 24 hours (both in full database and recent change/ exception Porting data content) and should provide the synchronisation files in .csv format.
The MNPAS should be capable of managing daily/weekly Porting quotas between the Licensed operators/ stakeholders to ensure consistent Porting performance and timescales between all Operators at all times.
The MNPAS should be capable of managing daily or weekly Porting quotas in line with the requirements set by setting the projected Porting dates based on current Porting demand versus the specified daily/ quota limits. For instance, where a Recipient Operator exceeds its daily/ weekly Porting quota against a specific Donor Operator, further Porting approval requests should be allocated to the next period (day or week) for which sufficient quota is available.
The MNPAS should permit the resetting of quotas, in circumstances to be determined based on the recommendations of the MNPWG.
The MNPAS should log each message including the response reasons to ensure that statistics will be available for any subsequent enquiry or report that may be needed.
Response and reject reasons will be specified later but the MNPAS should handle up to 100 numbers within a block Porting request and be capable of sending multiple rejection reasons in a single response message. The MNPWG has determined that a Donor Operator must provide all applicable reason for ‘Rejecting’ a request.
It should be possible to specify or add new response codes. NB: The codes are selected by the Donor Operator from an agreed and defined list defined and so the MNPAS need not know the exact meanings.
The list of codes and their meanings will be specified later as part of the MNPWG process.
The Consortium must provide for the requirements of Rwandan Law Enforcement Agencies (LEAs) the precise details of which will be addressed by RURA based on recommendations of the MNPWG and notified to the Consortium.
Without prejudice to the generality of the foregoing, the MNPAS should be capable of performing two additional steps, subject to further direction:
Consortia are requested to provide details relating to their previous experience in dealing with this particular aspect of Porting.
A.14.2 Interworking with the Rwanda Mobile Financial Services Platform (RSwitch)
Initially it is proposed that the MNP Administration Service will either send broadcast update messages a) each time a mobile number porting request is approved or b) when a mobile number is ported, to the Rwanda central mobile financial services switching service, RSwitch, or c) will provide look-up facilities or daily csv files to RSwitch to check the ported status of a number to facilitate the separate management of any associated mobile financial services or wallets.
The actual requirements, process and protocols for the MNP Administration Service to notify the Rwanda central mobile financial services switching service, RSwitch, are being developed between the MNPWG and the Rwanda Central Bank/ RSwitch and will be included in the final MNP Business Rules.
Consortia are requested to provide details relating to their previous experience in dealing with this particular aspect of interworking between the MNP Administration Service and central mobile financial services platforms.
The Consortium should be able to provide monthly lists of all failed and successful Porting transactions between each combination of Recipient and Donor Operators.
The MNPAS should produce statistical information related to MNP activities. The statistics should include:
Reports and statistics should be:
RURA is responsible for the administration of numbering resources in Rwanda.
The MNPAS being offered should support Mobile Number Porting in Rwanda mobile telephone number ranges.
Operators in Rwanda currently use number ranges allocated by RURA. The RURA numbering policies comply with RURA number range standards. Although the range of numbers available to the Licensed operators/ stakeholders is relatively large, there is a chance that the Numbering Plan could change over time and therefore the system should be able to handle the Porting of numbers that are not always of the same length.
Rwanda telephone numbers currently comprise twelve (12) digits in the following format:
CC + NC + SN
3 digits 2 digits 7 digits
CC – Country Code
NC – Network Code
SN – Subscriber Number
The first three (3) digits (CC) comprise the international Rwanda code as defined in ITU-T Recommendation E.164 which is +250
Of the remaining nine (9) digits, the first two (2) digits (NCC) comprise the Central Office Code mobile service identity, as appropriate, followed by seven (7) digits (XXXXXXX) for the specific subscriber telephone number.
In addition, the Consortium should describe how its proposed solution could deal with ENUM and any other future developments that might affect Numbering Plans.
With the introduction of MNP it will become increasingly difficult for an Operator to be clearly identified by its number prefix. Should Licensed operators/ stakeholders charge differently for calls that remain on their network (On-net) versus those that are no longer on their network (Off-net), it will become more difficult for subscribers to find out how much a particular call will cost.
Therefore, please indicate whether your MNPAS can provide a facility accessible over the internet or by SMS or using a voice response system whereby a potential caller can determine which network serves a given number.
Please state whether there would be any additional charge for this facility, providing details on whether this option can be provided from the centrally held database or would it be implemented independently by Operators allowing access to their own database?
Please advise whether your proposed MNP System Administration solution could be linked or interfaced to operator’s existing Freephone/toll-free or SMS/ text back information services.
Please find below a template of how the number record could be laid out. The intention is that it would be possible to extract statistical information about the number of times a number has been ported, etc. The record would hold the current Operator Code, date and time of port, the number of previous Portings and the port reference number of these Portings.
Please indicate how you would set up the records in your solution and your method of protecting that data (encryption).
| Field Description | Field | Size | Example |
| Subscriber Number | 1 | 10
|
NPA NXX XXXX |
| Status Code | 2 | 1 | 1-Free to be Ported, 2-Request to Port in process, 3-blocked from subsequent Porting until retention period has ended |
| Current Network Designation | 3 | 2 | XXX Operators with unique identifiers |
| Requested Date/Time that the Instruction Request was sent | 4 | 14 | 20250231142011
8 (yyyymmdd) + 6 hhmmss) |
| Actual Date/Time that an Instruction Response confirming completion of the port was sent | 4 | 14 | 20250231142011
8 (yyyymmdd) + 6 hhmmss) |
| Port Reference Number | 5 | 13
|
01nnnnnnnnnn
Unique to each operator |
| Counter to indicate the number of times the number has been ported | 6 | 5 | 0-99999 |
| Port Reference Number from previous port | 7 | 13
|
01nnnnnnnnnn |
Each message sent via the MNPAS shall be recorded and logged. Messages more than two years old may be stored off-line or archived.
NB: Assuming 300,000 ports per annum and 5 messages of 60 bytes per message, this is approximately 90MB per annum.
The MNPAS shall be capable of extracting and displaying all the messages relating to a given number for a minimum period of ten (10) years, with Porting data stored and available for online access for a minimum period of two (2) years, and the Porting data being archived offline for the remainder of the minimum storage period.
The Consortium should produce daily detailed error logs and monthly summaries. This
data would be used to determine problem frequency and would form part of the SLA review process.
Please indicate what error logs and reports your solution provides.
The Consortium must follow a structured methodology for installing software patches and/or new functionality in any of the software components, which supply the MNPAS.
The Consortium should include in its proposal details of the process it would implement for advising the licensed operators and the MNPWG of the need to temporarily suspend operations in order to upgrade the existing system, and how it would plan a reversal should the upgrade not be successful?
The Consortium must describe its hardware architecture and requirements if the Rwanda MNPAS service is to be hosted on existing data centre facilities available in Rwanda and provide the reasons why it has selected that particular environment over other architectural solutions.
If the Consortium’s solution requires non-standard hardware or a specialised operating system it should highlight this in its proposal. This will not necessarily exclude the Consortium from consideration. However, as the infrastructure used by the Consortium will need to be in place on a continual basis, any such non-standard items must be supportable over the same contract period.
Please outline your database choice and provide the reasons why you have selected that particular solution over other solutions.
In addition, Consortia should provide the following;
The Consortium’s solution must be secure and have appropriate independently verifiable access controls for users and systems (e.g., Encrypted databases, Firewalls and other controls, dedicated VPN environment, multi-layered Protocols etc.). The Consortium should outline why it is proposing this particular solution, including features, benefits and any potential challenges.
Please specify the input and output connectivity requirements that are necessary to connect/ communicate with the proposed MNPAS, including but not limited to: –
Please identify all interface protocols that you propose to make available to the Operators for the automatic control mode or API, and indicate why you have selected it/them. A number of common interface protocols below are listed for consideration:
Real time incremental back-ups must be supported as per the SLA.
The MNPAS must support full on-site and off-site (i.e., a support location other than the Consortium’s primary operational site/ facility) backups. Please indicate how long you estimate it would take to perform a complete backup, where the backup data would be stored and how often off-site backups will be provided.
The Respondent should provide details of security plans for the MNPAS to ensure Rwanda Porting data integrity is maintained and protected.
It must be possible to restore in no more than six (6) hours but with the restoration being carried out as soon as possible irrespective of the time of day or night.
Bearing in mind the critical nature of this solution, please describe in detail your experience in designing Disaster Recovery solutions and any experiences you have had when such a recovery was put into action. Please state your disaster recovery/ contingency planning including off site/ back-up plans, redundancy/resilience plans and testing schedules and procedures.
The MNPAS should be designed for operation for the following times:
24 x 7 (please refer to table in section 4.2 for SLA definition of availability).
Helpdesk and operational support should be available by phone, email and electronic access to align with Rwanda normal working times (Days and Hours), including national public holidays, and taking into account any time difference between the Consortium’s support location and Rwanda.
Please confirm what redundancy you have for the solution (e.g., dual servers – two or more servers to ensure resilience and redundancy for the MNPAS), RAID etc.
Please be advised that penalties will be applied if availability does not comply with the levels in the SLA. Availability of the MNPAS will be measured under the SLA process and reviewed on a regular basis.
Regular maintenance should be handled outside normal Porting hours (local time).
Please provide a comprehensive maintenance plan outlining the nature of maintenance required including how and when this will be completed.
Please describe your standard user interface together with any additional features and functionality that you wish to offer together with the relevant prices. Please note ease of use will be a key consideration in the evaluation of proposals.
The following is included assuming that messages are sent in xml format with markers for the start and end of each field. A fixed field length format is also acceptable, in which case section 2.1 contains some information on the field lengths required.
| transactionId | Long | An incrementing sequence number, which uniquely identifies a complete transaction and is prefixed by the Recipient Operator Code. The Recipient Operator is responsible for generating a correct sequence number. |
| recipientOperator | Integer | Recipient Operator code – This field represents the sender of the request. |
| donorOperator | Integer | Donor Operator code – This field represents the receiver of the request. . |
| dateTime | String | Date and time of operation in the format YYYYMMDDHH24MMSS
NB: The hours are expressed using the 24-hour clock but the “24” is not included in the encoding, e.g., 24 June 2025 at 19:30:26 will be shown as 20250624193026. |
| E.164 number | String | The 11-digit subscriber number to be ported |
| SpareField1 | Integer | To be defined |
| SpareField2 | Integer | To be defined |
| SpareField3 | Integer | To be defined |
| SpareField4 | Integer | To be defined |
| checksPassed | String | To be defined |
| extraInformation | String | A free form field that is not used for processing the request but should be returned as is in the Porting approval response message. |
| transactionId | Long | The sequence number, which uniquely identifies a complete transaction and is prefixed by the Recipient Operator Code. This should be the same transaction id as the one sent in the Porting approval request. |
| recipientOperator | Integer | Recipient Operator code – This field represents the receiver of the response. |
| donorOperator | Integer | Donor Operator code – This field represents the sender of the response. |
| dateTime | String | Date and time of the message in the format YYYYMMDDHH24MMSS |
| E.164 number | String | The 11-digit subscriber number to be ported |
| ResponseCode | Integer | To be defined |
| SpareField1 | Integer | To be defined |
| SpareField2 | Integer | To be defined |
| SpareField3 | Integer | To be defined |
| SpareField4 | String | To be defined |
| ExtraInformation | String | A free form field that is not used for processing the request but should be returned as is in the Porting approval response message. |
| transactionId | Long | The sequence number, which uniquely identifies a complete transaction and is prefixed by the Recipient Operator Code. This should be the same transaction id as the one sent in the Porting approval response. |
| recipientOperator | Integer | Recipient Operator code – This field represents the sender of the request. |
| donorOperator | Integer | Donor Operator code – This field represents the receiver of the request. |
| dateTime | String | Date and time of the message in the format YYYYMMDDHH24MMSS |
| E.164 Number | String | The 11-digit subscriber number to be ported |
| SpareField1 | Integer | To be defined |
| SpareField2 | Integer | To be defined |
| SpareField3 | Integer | To be defined |
| SpareField4 | String | To be defined |
| extraInformation | String | A free form field that is not used for processing the request but should be returned as is in the Porting approval response message. |
| transactionId | Long | The sequence number, which uniquely identifies a complete transaction and is prefixed by the Recipient Operator Code. This should be the same transaction id as the one sent in the Porting approval request. |
| recipientOperator | Integer | Recipient Operator code – This field represents the receiver of the response. |
| donorOperator | Integer | Donor Operator code – This field represents the sender of the response. |
| dateTime | String | Date and time of the message in the format YYYYMMDDHH24MMSS |
| E.164 number | String | The 11-digit subscriber number to be ported |
| ResponseCode | Integer | To be defined |
| SpareField1 | Integer | To be defined |
| SpareField2 | Integer | To be defined |
| SpareField3 | Integer | To be defined |
| SpareField4 | String | To be defined |
| ExtraInformation | String | A free form field that is not used for processing the request but should be returned as is in the Porting approval response message. |
| transactionId | Long | The sequence number, which uniquely identifies this transaction. |
| recipientOperator | Integer | Recipient Operator code.
|
| dateTime | String | Date and time of the message in the format YYYYMMDDHH24MMSS |
| E.164 Number | String | The 11-digit subscriber number ported |
| transactionId | Long | The sequence number, which uniquely identifies this transaction. |
| recipientOperator | Integer | Recipient Operator code. |
| blockOperator | Integer | Block Operator code. (=range holder) |
| dateTime | String | Date and time of the message in the format YYYYMMDDHH24MMSS |
| E.164 Number | String | The 11-digit subscriber number ported |
“Accept Message” is a message from the Donor Operator in response to the Request to Port indicating that the Porting may proceed;
“Activation” means that the accepted Request to Port status has been acted upon by the Donor Operator and the Recipient Operator and the number is now recognised by all Operators as being active on the Recipient Operator Network;
“All Call Query” means the system for the setting up of calls on a network in which for every call the Operator’s ‘Routing’ database is interrogated during the call set-up process to determine the correct network designation for the particular number dialled;
“Application” means a software package which performs a set of routines required by the user;
“Application Programming Interface (API)” is an interface which a computer system provides to enable other computer programs to request services and/or to allow data to be exchanged between them;
“Broadcast” means the automatic transmission of routing information from the MNP Administration Service to an Operator managed database;
“Browser” means an application which is designed to enable users to access systems across the Internet. Windows Internet Explorer is one such Browser application;
“Client” means an application provided by a Consortium, which can be installed on hardware located in the user’s domain and under the control of the user, which will provide specific functionality;
“Communications” means data transfer/exchange between one computer system and another;
“Consortium” means the entity, selected pursuant to this RFP, which provides the MNP Administration Service;
“Cooling Off” means the function or process as determined by the Business Rules, which enables a ported Subscriber to return to the Donor Operator within a specified period after the port has been completed;
“Customisation” means work that is done to the standard application to ensure that it can fulfil the requirements of the MNPWG and those of the Licensed operators;
“Deferred Porting” means the capability of enabling a subscriber to define or set a Porting date at a point in the future;
“Dipping” means the retrieval of number routing details from a special database;
“Disaster Recovery” means the measures the Consortium will take in circumstances where normal MNP Administration Service infrastructure is damaged to the extent it is not possible to re-start operations to provide the required service within a time period that is acceptable to the MNPWG;
“Donor Operator” means the Operator that is providing service for the Subscriber before Porting;
“Electronic Requests” means MNP Processes using computer applications to inquire, request, acknowledge and activate the Porting processes;
“Electronic Numbering (ENUM)” refers to a system designed to enter RURA Recommendation E.164 telephone numbers which are used by public switched telephone networks into the Internet Domain Name System;
“Escrow” means the arrangement between the licensed operators/ stakeholders and the Consortium whereby the software, source code and supporting material relating to the MNP Administration Service and MNP Central Database as agreed, is to be held by a trusted third party until the occurrence of a specified condition(s);
“Final Acceptance” means the point at which the Licensed operators/ stakeholders have agreed with the Consortium that the service has been supplied, delivered, and fully functional as agreed and free from faults;
“Firewall” means specialised communications equipment which is used to validate any attempt to access systems by users using communication links;
“First Stage” means the initial set of MNP project activities carried out by the MNP Administration Service project team;
“Fixed Operator” means a licensed operator which provides fixed services (including but not limited to voice services) in Rwanda;
“Fully Integrated” means all components of the MNP Administration Service (software, hardware and communications) are working and subscribers using the system can access the system through designated entry points and enter/receive information in the specified manner;
“Hardware” means equipment selected, configured and used by the Consortium, covering processing requirements and data storage;
“Inquiry” means the activity which is undertaken by a prospective Recipient Operator to ascertain if a number meets a given set of conditions which will either enable a Request to Port to be initiated or blocked;
“Law Enforcement Agency” means any department or organisation within the Ministry of National Security authorised under the laws of Rwanda to undertake law enforcement;
“Licensee” means the grantee or holder of a licence issued by RURA the regulatory authority responsible for telecommunications market regulation in Rwanda under the powers granted under the relevant telecommunications legislation;
“Licensed Operator” means a licensee who has been allocated numbering resources by RURA in which the licensee is licensed to provide an electronic communications service;
“Managed Services” means the provision of services to manage and operate the MNP Administration Service (irrespective of location selected);
“MNP Administration Service” means the provision of a service in Rwanda to enable the process of Porting of numbers between Operators, and the provision of routing information from a reference database of all Ported numbers, and shall include the application, the database and the necessary hardware and communications equipment required to deliver the functionality deemed necessary for administrating the act of Number Portability;
“Mobile Number Portability (MNP)” means the ability for a subscriber to retain an existing telephone number when transferring mobile services from one Licensed operator to another;
“Mobile Operator” means a licensed operator/ Consortium which provides mobile services (including but not limited to voice services) in Rwanda;
“MNP Processes” means the actions to be undertaken by each Operator to ensure that the Subscriber receives an effective, efficient and seamless service when their subscriber number is ported from a Donor Operator to a Recipient Operator;
“MNP Programme” means a defined set of time-lined activities from initial design through to final launch, which will deliver MNP functionality for Rwanda;
“MNP Service” means the service offered by each Operator to prospective subscribers to enable the subscriber to port their number across to a new network;
“Mobile Number Portability Working Group (MNPWG)” means the joint RURA/Industry group appointed by RURA to coordinate the development, implementation and launch of MNP in Rwanda. The team comprises representatives of RURA, Licensed operators, and other persons as determined by RURA;
“Network” means the transmission system, including any apparatus, equipment or facility, used for the conveyance by use of electrical magnetic or electromagnetic energy of signals of any description by an Operator which provides electronic communications services;
“Non-Disclosure Agreement” (“NDA”) means an agreement to be entered into between the Licensed operators and the Consortium in order to facilitate the sharing of confidential information between the parties to that agreement;
“Numbering Plan” means the National Numbering Plan for Rwanda as published from time to time by RURA;
“Number repatriation” means the return of a number to the Original Number Range Holder when service is terminated on any other network to which the number has been ported;
“Off-net” means a call made on one Operator’s Network that needs to be terminated on the
Network of another Operator;
“On-net” means a call made on an Operator’s Network that is terminated on the same Network;
“Onward Porting” means a Porting request where the subscriber requests to port to another Operator who is neither the current Recipient Operator nor previous Donor Operator within a time period from the completion of the previous Porting request;
“Operator” means a licensed party/ entity which provides fixed or mobile services in Rwanda;
“Operator Code” means the internationally recognised code given to each authorised telecommunications Operator;
“Original Number Range Holder” means the Operator who was originally granted a specific number range by RURA;
“Personal Identification Number (PIN)” means a secret numeric password shared between a user and a system that can be used to authenticate the user to the system;
“Porting” means the process comprising a request to a Donor Operator’s Network for approval to transfer a number from its Network to the Recipient Operator’s Network, the subsequent receipt of an answer from the Donor Operator’s Network, and informing all Operators that a number has been successfully transferred and is now active on the Recipient Operator’s Network;
“Quarantine” means the withholding of a number from further use for a specified period of time after its use has been terminated;
“Recipient Network” means the Network providing service for the subscriber’s number after Porting;
“Reference Database” means an electronic storage medium that contains information used in the execution of the MNP Administration Service;
“Reject Message” is a message from the Donor Operator to the Recipient Operator in response to a Request to Port indicating that the Porting may not proceed;
“Request to Port” means the function initiated by the Recipient Operator to officially request that a Donor Operator transfer a number that is currently in service on the Donor Operator’s Network;
“Respondent” means a person or organisation responding to this RFP;
“Review Meeting” means meetings held periodically between the representatives of the Consortium and the MNPWG/ Licensed operators to discuss matters related to the MNP Administration Service;
“Routing” is the process of selecting paths in a network along which to send network traffic;
“Routing Change Information” means that information on the Routing for a particular number has been changed to reflect a different Operator Code due to the number having been Ported;
“Routing Databases” means the databases used by Operators to route calls to their current service Network. The “Master” database is maintained within the MNP Administration Service and “Local” databases are located within each Operator’s Network;
“Routing Information” means the specific data used for routing calls which describes which Network is providing service to a particular number;
“Secure Service” means a service which is fully protected from unauthorised person’ access, configured so that the information stored is fully backed-up to a secure location separate from the main system;
“Service Level Agreement (SLA)” means an agreement between the Consortium and licensed operators/ stakeholders, entered into in accordance with requirements determined by RURA, which covers the business and technical requirements placed upon the MNP Administration Service;
“Simple Object Access Protocol (SOAP)” is a standardised protocol to enable compatibility between different programs which allows data to be passed from one computer program to another allowing both programs to extract data in a predefined manner;
“Software” means computer applications supplied by the Consortium to the licensed operators/ stakeholders which enables the MNP Administration Service to be used;
“Subscriber” means a legal or natural person who acquires electronic communications services from an Operator; and
“Subscriber Identity Module (SIM)” is a small electronic card inserted into mobile phones which provides a unique ID to a phone such as the number and Operator Network.
[1] Source: International Monetary Fund – 2024 Figures
[2] Source: RURA Market Statistics August 2024
MTN Rwanda last week ushered in a pivotal moment in its jour...
Read More
100
customercare.rw@mtn.com
customerservice.rw@mtn.com
info@mtn.com
reception.rw@mtn.com
+250788310044
+250 788 310 044 (Sign language)
MTN Centre, KG 9 Ave, Kigali
Monday – Friday
8AM – 9PM
Weekend
9AM – 5PM
MTN (PTY) LTD is an authorised Financial Service Provider, underwritten by Guardrisk Insurance Company. FSP license number: 44774
We use cookies to improve your experience on our website. By browsing this website, you agree to our use of cookies and Data Privacy notice.
