Ouroboros Telecom
MNO · MVNO · Regulator-ready

One portability database, every way of asking it

A ported number has to be found by every part of the network: the circuit core asks over MAP or CAMEL, the IMS asks over ENUM or SIP, the Diameter core routes on the MSISDN, the IT platforms call a web API. When each of them keeps its own copy of the portability data, the copies drift and calls fail. Ouroboros answers all of them from one database.

Mobile Number Portability · One database
ENUMNAPTR answers for VoLTE and IMS interconnect
SIP302 redirect, or 404 for query on release
MAPATI and SRI-for-SM, with status and routing number
CAMELCalls connected to the routing number by the SCP
STP routingSignalling relay of the MAP queries to the right HLR
DRA routingDiameter requests routed on the MSISDN to the right HSS
Web APIPortability of a number for IT and SMS platforms
Central databaseRIO by SMS, USSD or voiceSeveral PLMNPorted-in and ported-out
Legos

We've selected Ouroboros because it was the best company capable of fulfilling our need for a scalable and virtualised full MVNO platform. Moreover, the Ouroboros team is pragmatic, flexible and responsive.

Pascal Prot

CEO-CTO · Legos

01

Number portability is not one query. A voice call from the circuit core asks the HLR over MAP, a VoLTE call asks ENUM, an SMS goes through a send-routing-information on the STP, an application server reaches the HSS over Diameter with the MSISDN. Each interface was added at a different time, often with a different vendor, and each one ended up with its own table of ported numbers.

The result is a portability database that exists in four or five copies, updated by different scripts on different schedules. A number ported in this morning reaches the right subscriber for SMS but not for VoLTE calls. A number ported out keeps being routed to the home HSS by the Diameter core.

The regulator does not care which interface failed. The subscriber who changed operator expects every call and every message to follow.

02

Ouroboros can supply the whole number portability chain, not only the answers of the network. For a country, the central database records every porting between operators, with its provisioning and the porting workflow. For the subscriber, the RIO is delivered automatically by SMS, USSD or voice, without a call to customer care. For each operator, the portability database is synchronised with the central one and answers every query of the network.

The ported numbers are also published as a standardised porting list file, so that interconnect partners and third-party platforms keep their own routing tables in line. Operators and national bodies take the parts they need: the central database for a country, the operator database and its interfaces, or both on the same platform.

Ouroboros keeps the portability data in a single table of the subscriber database. Each row says which network serves an identity — a single number, or a prefix for a whole number range — for a given service, with its network address and the PLMN (MCC / MNC) of the serving operator.

Find the number, not the copy. A lookup checks the exact number first, then its prefixes from the longest, through one index. A ported number always wins over the range it came from, and the answer comes back in a few hundredths of a millisecond on a table of millions of numbers.

Answer every protocol from the same row. The ENUM server, the SIP redirect, the MAP interrogations, the CAMEL service, the STP routing, the DRA routing and the web API all read the same table. A number ported in or out is updated once and is right everywhere at the same moment.

Follow the routing model of the country. All call query, where the originating network asks before every call; query on release, where it asks only when the number range holder answers that the number is ported; onward routing, where the range holder forwards the call itself — the same database serves each of them. Each row carries the PLMN that serves the number, so several countries or MVNO brands, and the recipient networks of ported numbers, stay in the same table.

Table for every protocol
03

A DNS server for the e164.arpa tree (RFC 6116, GSMA IR.67). Ported numbers get the IMS domain of the recipient network, then an E2U+pstn:tel answer with the routing number. Unknown numbers return NXDOMAIN.

06

Portability web API

A web service on the operator’s own server returns serving network, routing number and status in JSON, for IT platforms, SMS aggregators and customer care. The same service answers the SCP.

07

Central database

The national reference records every porting. The recipient submits, the donor validates, and at the effective date the new routing is distributed. Ranges, operators and porting windows are provisioned by web and API.

08

Automated RIO

The subscriber gets their RIO, the porting code that proves the request comes from the line holder, by automated voice, USSD or SMS. It is checked before any port-out is accepted.

09

Operator synchronisation

Every confirmed porting is written into the operator database at its effective date. Incremental updates run through the day, and reconciliation reports flag any number that differs.

10

Porting list file

Full and incremental lists — number, recipient operator, routing number, effective date — in a standardised file for interconnect partners and platforms that keep their own routing tables.

04

01

National portability for VoLTE

The country has moved voice to VoLTE and IMS interconnect, but the portability database only answers MAP. Add ENUM on the same data: VoLTE calls to ported numbers are routed to the IMS of the recipient network, and the circuit core keeps working as it does today.

02

One operator, several PLMN

An operator runs networks in several countries, or several brands with their own PLMN, behind one core. Each number is attached to the PLMN that serves it, and every answer — ENUM, MAP, Diameter — points to the right network.

03

Several HSS or MVNO hosting

Subscribers are spread over several HSS, or hosted MVNOs bring their own number ranges. The DRA finds the right server from the MSISDN or the IMSI, the clients keep a single Diameter peer, and the numbers ported in are located like the operator’s own.

04

Replacing a legacy portability database

The existing database answers only one protocol and is fed by scripts that nobody wants to touch. Load its data into the single table, keep the old interface running through the STP, and add ENUM and Diameter routing on the same records.

05

Setting up national portability

A country introduces number portability, or replaces its national system. Ouroboros supplies the central database, the porting workflow between operators, the automated RIO and the standardised porting files, and each operator connects its own network with the same platform.

05Why Ouroboros

One supplier for the whole chain. Central database, porting workflow, automated RIO, porting files and the operator network that answers every query.

02

Portability data in one place. Every protocol reads the same row, so a number ported in or out is right everywhere at the same moment, with no synchronisation between copies.

03

Every generation from one vendor. MAP, CAMEL and STP for the circuit core, Diameter for 4G, ENUM and SIP for IMS, a web API for the IT — the same team, the same database, the same support contract.

04

Built for real portability systems. Centralised or distributed national databases, prefixes and single numbers, several PLMN and several countries in one table.

Ouroboros Telecom

Tell us how your network answers portability today — which protocols, which databases, which national system — and we will show how one table can answer all of them, and how the central database, the RIO and the porting files fit around it.

ENUM, SIP, MAP, CAMEL, STP, DRA and web API answered from one portability table
Central database, automated RIO and standardised porting files from the same vendor
Several PLMN, prefixes and ported numbers in the same database
In production since 2004 across 30+ countries at 99.999% availability