Chapter 7 - Numbering Management Database
This Chapter addresses Concrete deliverable No. 6 - Recommendations on the development of a numbers management database.
Development of a numbers management database
A register of each allocation of a number block to any operator is a key requirement for sound numbering management. At present, the MPT relies on allocating large blocks of numbers so that records allocations are simple and paper based. This is a simple and workable method but does not accommodate close management of the number space and results in inefficient use of numbers, poor understanding of operator use of numbers, identification of developing shortages and means that it is possible for some allocations to be duplicated (e.g. short codes). Update and maintenance of the data is also subject to significant human error.
A modern database for use in developed countries is necessarily different from the system in a developing country. In a developed country the database might be expected to:
• be operable from several regulator locations (probably web based access to readily attach to the corporate intranet);
• incorporate separate and strong authentication for users, maintainers and developers
• incorporate automatic backup of system and data to an offsite facility
• be structured to reflect the National Number Plan with easy remote access and navigation for users;
• support many operators seeking many different types of numbers (possibly enabling automatic allocation of number blocks in straightforward cases) and be able to support multiple simultaneous transactions;
• record, track, and efficiently manage online applications for numbering resources;
• provide for a number of standard searches of the contents of the database;
• monitor and assign number blocks from a centralized database (to save time and minimize potential human errors)
• provide for online surrender or withdrawal of number blocks
• deal with aspects of number portability (for some implementations)
• generate reports such as detailed usage metrics, forecasts of future number space availability, fees collected or outstanding etc.;
• manage varied application fees, and annual charges, generate invoices and accept online payments; and
• generate standard letters for the most common functions.
Such a system might be supported by adequate numbers of well trained staff to operate and maintain the database. The entity manager of the system would have ready access to skills for any development of the database that may be necessary (due to legislation change, industry requirement etc.) or prudent (for internal procedures improvements or efficiency of operation).
In such circumstances the database system may comprise a relational database linked to a spreadsheet for necessary calculations associated with numbers management, invoice calculations or calculation of aggregate charges per operator for numbers (where such is applied).
However the reality varies. Regulators use different systems with quite varied capabilities for managing numbers. For example:
• UK and Portugal use or have used) an in house constructed Microsoft Excel spreadsheet;
• Netherlands uses a simple in house constructed Microsoft Access database; and
• Australia used an in-house constructed Excel spreadsheet but now uses a purpose built Oracle based database for the Number Management system.
Commercially there are products that will assist regulators in their roles. Two such products are:
• ‘Ericsson Customer Number Manager’ from Ericsson of Canada; and
• ‘N-Base’ from “PortingXS” of the Netherlands.
Information brochures for each of these are attached to this Report (Appendices 7a, 7b).
In a developing country environment the needs are that it:
• be operable from a single regulator location with several staff authorised to operate the database and usually on a LAN or a single computer;
• incorporate separate authentication for users and maintainers/ developers;
• rely on manual procedures based backup of the system and data unless the Corporate LAN provides the back-up service;
• be structured to reflect the National Number Plan with easy navigation for users;
• support a single operator managing many different types of numbers supporting a single transaction at any time;
• record, track, and efficiently manage applications for numbering resources;
• provide for unique searches or manipulations of the contents of the database;
• monitor and assign number blocks in a way to minimize potential human errors
• provide for surrender or withdrawal of number blocks
• generate reports such as holdings by each operator of each type of allocated number, be able to support usage metrics to create forecasts of future number space availability;
• be managed, operated and supported a single person or a small staff and that they be able to understand the system, its operation and maintenance with minimum instruction
• be based on a familiar platform that is readily understood and for which local support is available.
• be able to be maintained and developed “in house”. (as the numbering management regime develops, local skills and understandings develop ensuring independence from foreign support);
• low cost to establish, maintain and develop
As indicated for the cases of UK, Portugal, early Australian systems and the Netherlands, an efficient register need not be complicated. For developing countries it is pragmatic for such systems to be within the readily available competencies of staff. Spreadsheet systems based on widely available products such as Microsoft Excel or Open Office are:
• widely available and well understood,
• would not ordinarily require specialist support staff to devise or incorporate any later required modifications and
• can easily meet the requirements of adjunct functions such as production of reports and audit of holdings (Microsoft Excel has a “pivot table” function for this). Such capabilities are immediately useful for calculating annual charges relevant to each operator (in the event that a charging for numbers regime is established).