- 01MSC / VLRMSC/VLR
- 02Gateway Mobile Switching CenterGMSC
- 03Gateway Mobile Location CentreGMLC
- 04Home Location RegisterHLR
- 05Messaging CenterSMSC
- 06Signaling Transfer PointSTP
- 07GGSN / SGSNGGSN
- 08S4-SGSNSGSN
- 09Equipment Identity RegisterEIR
- 10Service Control PointSCP
- 11USSD GatewayUSSD
- 12Cell Broadcast CentreCBC
A virtualised Mobile Switching Center and Visitor Location Register for 2G and 3G — the smartMSC combines MSC, VLR, SGSN and STP in one node, to replace legacy switching infrastructure and connect it to your 4G and IMS core.
The MSC is the switching heart of a 2G and 3G network. It routes every mobile-originated and mobile-terminated call. It handles every SMS. It manages handovers between base stations. And for most operators, it runs on proprietary hardware from a vendor who sold it fifteen years ago. The hardware is expensive to maintain, difficult to source replacement parts for, and fundamentally cannot be virtualised — it requires the same vendor's chassis, the same port cards, the same proprietary operating system.
When that hardware reaches end-of-life, the replacement conversation starts with the same vendor. There is no competitive tender for the switching layer. An operator who needs to expand capacity, reduce sites, connect its circuit-switched network to VoLTE, or migrate to a cloud-native architecture faces the same lock-in they had on day one — but now with ageing hardware and a vendor who knows they have no alternative.
Four logical entities in one node
The Ouroboros smartMSC combines four colocated functions. The MSC is the border with the radio network (BSC/BTS and RNC), handling signalling and validating subscribers against the HLR/AuC and the EIR. The VLR keeps the subscribers and roamers of the regional zone with their profiles and rights. The SGSN handles 2.5G and 3G data. The STP handles SS7 routing and interconnection with other operators.
2G and 3G access, every procedure
The MSC authenticates subscribers and inbound roamers, checks the handset against the EIR, and handles paging, network-initiated detach, SMS MO/MT, and USSD over A and Iu-CS: requests relayed to the HLR, application menus, and network notifications with paging of idle handsets. In 3G, Iu-CS and Iu-PS run RANAP over SIGTRAN, with SRNS relocation between RNCs and 3G / 2G inter-system handover.
Data on the EPC, voice toward the IMS
The SGSN is an S4-SGSN: data sessions are set up toward the SGW of the Ouroboros EPC, so 2G, 3G, and 4G share one packet core with no GGSN. In 3G, the GTP-U tunnel goes directly from the RNC to the SGW (S12 direct tunnel). On the voice side, the smartMSC connects to the IMS over SIP / RTP, and acts as the target MSC server for SRVCC: VoLTE calls leaving LTE coverage are handed over to UTRAN or GERAN on the Sv interface, with session transfer to the IMS.
CUPS and Kubernetes pools
The smartMSC is separated into a control path, a data path, and a voice path. For heavy load, a pool of smartMSC / SGSN user nodes runs in a Kubernetes deployment, and capacity scales horizontally with the addition of nodes or SBC nodes.
smartMSC — MSC, VLR, SGSN and STP between the 2G/3G radio, the subscriber core, and the 4G / IMS core
Legacy MSC replacement, 3G access, CAMEL prepaid, VoLTE continuity, roaming — virtualised.
Legacy MSC replacement
An operator running end-of-life MSC hardware from a major vendor migrates to the Ouroboros smartMSC without changing the BSC, RNC, HLR, or SMSC. The A-interface, Iu interfaces, and MAP are standard — the radio network does not see a change.
MVNO 2G/3G switching
An MVNO requiring its own switching layer deploys the smartMSC on hosted infrastructure. It connects to the host operator's radio network and handles subscriber switching independently from the host network.
CAMEL prepaid integration
Operators running prepaid services require real-time call control. The smartMSC supports CAMEL Phase 2/3 through its SSF — charging triggers fire at call setup, mid-call, and call release, with postpaid and prepaid billing on time and event quotas, through the SCP or a Diameter Ro OCS.
VoLTE with 2G/3G fallback
An operator launching VoLTE keeps calls alive when subscribers leave LTE coverage: the smartMSC is the target MSC server for SRVCC, and handles CS fallback with the MME over SGs.
Roaming and inter-operator interconnect
The VLR handles inbound roamers with their profiles and rights. The integrated STP routes SS7 signalling and interconnects with other operators.
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
2G and 3G radio access
A-interface toward the BSC and Iu-CS / Iu-PS toward the RNC, with RANAP over SIGTRAN. BTS/BSC handovers, SRNS relocation, 3G / 2G inter-system handover, and radio capacity changes.
CAMEL Phase 2/3 for prepaid
Real-time call control via CAMEL Apply Charging and the CAP protocol. Charging triggers fire at call setup, mid-call, and call release. Full integration with the Ouroboros SCP or third-party IN platforms, or Diameter Ro toward an OCS.
MAP toward the HLR, EIR, and SMSC
MAP dialogs with TCAP application context negotiation for authentication, location update, subscriber data, IMEI checks, SMS, and USSD.
Integrated VLR, SGSN, and STP
Subscriber profiles are fetched from the HLR on registration and kept in the VLR. The S4-SGSN carries 2.5G and 3G data on the EPC. The STP routes SS7 signalling. One node replaces four.
4G and IMS interworking
SGs for CS fallback, Sv for SRVCC of VoLTE calls, S3 for idle mobility and PS handover with the MME, and a SIP / RTP voice path for direct connection to the IMS.
Carrier-grade, cloud-ready
Cluster setups for carrier-grade reliability, CUPS separation of control, data, and voice paths, and Kubernetes pools for heavy load. Monitoring through SNMP and HTTP alarms and counters and Prometheus metrics.
IPv4, IPv6 and dual-stack
Every interface runs over IPv4, IPv6 or both. The element fits an IPv6 core or a mixed network without a separate configuration.
Traditional MSC vendors supply a hardware platform, not a software product. The switching software runs only on their hardware, which means upgrades, capacity additions, and site changes all go through the same vendor at vendor pricing.
The Ouroboros smartMSC is software. It runs on COTS hardware, VMware, KVM, Docker, Kubernetes, or AWS / Azure — the same infrastructure that operators already run for HLR, SMSC, and other virtualised elements. One node combines MSC, VLR, SGSN, and STP. Capacity scales by adding nodes. Redundancy is a configuration choice, not a hardware purchase.
For operators running the full Ouroboros core, the smartMSC connects directly to the HLR, SMSC, EIR, the EPC, and the IMS with standard interfaces.
Tell us your current MSC vendor, subscriber count, radio access (2G, 3G, or both), and whether you need CAMEL prepaid or VoLTE continuity. We'll come back with a migration proposal and a timeline.
Product datasheet2G / 3G · 2G / 3G
MSC / VLR (MSC/VLR)
A virtualised Mobile Switching Center and Visitor Location Register for 2G and 3G — the smartMSC combines MSC, VLR, SGSN and STP in one node, to replace legacy switching infrastructure and connect it to your 4G and IMS core.
Part of the Ouroboros 2G/3G core · CAMEL Phase 2/3 · 99.999% availability
Legacy MSC hardware that cannot be virtualised
The MSC is the switching heart of a 2G and 3G network. It routes every mobile-originated and mobile-terminated call. It handles every SMS. It manages handovers between base stations. And for most operators, it runs on proprietary hardware from a vendor who sold it fifteen years ago. The hardware is expensive to maintain, difficult to source replacement parts for, and fundamentally cannot be virtualised — it requires the same vendor's chassis, the same port cards, the same proprietary operating system.
When that hardware reaches end-of-life, the replacement conversation starts with the same vendor. There is no competitive tender for the switching layer. An operator who needs to expand capacity, reduce sites, connect its circuit-switched network to VoLTE, or migrate to a cloud-native architecture faces the same lock-in they had on day one — but now with ageing hardware and a vendor who knows they have no alternative.
Every call. Every SMS. On your terms.
Four logical entities in one node
The Ouroboros smartMSC combines four colocated functions. The MSC is the border with the radio network (BSC/BTS and RNC), handling signalling and validating subscribers against the HLR/AuC and the EIR. The VLR keeps the subscribers and roamers of the regional zone with their profiles and rights. The SGSN handles 2.5G and 3G data. The STP handles SS7 routing and interconnection with other operators.
2G and 3G access, every procedure
The MSC authenticates subscribers and inbound roamers, checks the handset against the EIR, and handles paging, network-initiated detach, SMS MO/MT, and USSD over A and Iu-CS: requests relayed to the HLR, application menus, and network notifications with paging of idle handsets. In 3G, Iu-CS and Iu-PS run RANAP over SIGTRAN, with SRNS relocation between RNCs and 3G / 2G inter-system handover.
Data on the EPC, voice toward the IMS
The SGSN is an S4-SGSN: data sessions are set up toward the SGW of the Ouroboros EPC, so 2G, 3G, and 4G share one packet core with no GGSN. In 3G, the GTP-U tunnel goes directly from the RNC to the SGW (S12 direct tunnel). On the voice side, the smartMSC connects to the IMS over SIP / RTP, and acts as the target MSC server for SRVCC: VoLTE calls leaving LTE coverage are handed over to UTRAN or GERAN on the Sv interface, with session transfer to the IMS.
CUPS and Kubernetes pools
The smartMSC is separated into a control path, a data path, and a voice path. For heavy load, a pool of smartMSC / SGSN user nodes runs in a Kubernetes deployment, and capacity scales horizontally with the addition of nodes or SBC nodes.
smartMSC — MSC, VLR, SGSN and STP between the 2G/3G radio, the subscriber core, and the 4G / IMS core
How operators use it.
Legacy MSC replacement, 3G access, CAMEL prepaid, VoLTE continuity, roaming — virtualised.
Legacy MSC replacement
An operator running end-of-life MSC hardware from a major vendor migrates to the Ouroboros smartMSC without changing the BSC, RNC, HLR, or SMSC. The A-interface, Iu interfaces, and MAP are standard — the radio network does not see a change.
MVNO 2G/3G switching
An MVNO requiring its own switching layer deploys the smartMSC on hosted infrastructure. It connects to the host operator's radio network and handles subscriber switching independently from the host network.
CAMEL prepaid integration
Operators running prepaid services require real-time call control. The smartMSC supports CAMEL Phase 2/3 through its SSF — charging triggers fire at call setup, mid-call, and call release, with postpaid and prepaid billing on time and event quotas, through the SCP or a Diameter Ro OCS.
VoLTE with 2G/3G fallback
An operator launching VoLTE keeps calls alive when subscribers leave LTE coverage: the smartMSC is the target MSC server for SRVCC, and handles CS fallback with the MME over SGs.
Roaming and inter-operator interconnect
The VLR handles inbound roamers with their profiles and rights. The integrated STP routes SS7 signalling and interconnects with other operators.
Specifications.
Inside the platform.
2G and 3G radio access
A-interface toward the BSC and Iu-CS / Iu-PS toward the RNC, with RANAP over SIGTRAN. BTS/BSC handovers, SRNS relocation, 3G / 2G inter-system handover, and radio capacity changes.
CAMEL Phase 2/3 for prepaid
Real-time call control via CAMEL Apply Charging and the CAP protocol. Charging triggers fire at call setup, mid-call, and call release. Full integration with the Ouroboros SCP or third-party IN platforms, or Diameter Ro toward an OCS.
MAP toward the HLR, EIR, and SMSC
MAP dialogs with TCAP application context negotiation for authentication, location update, subscriber data, IMEI checks, SMS, and USSD.
Integrated VLR, SGSN, and STP
Subscriber profiles are fetched from the HLR on registration and kept in the VLR. The S4-SGSN carries 2.5G and 3G data on the EPC. The STP routes SS7 signalling. One node replaces four.
4G and IMS interworking
SGs for CS fallback, Sv for SRVCC of VoLTE calls, S3 for idle mobility and PS handover with the MME, and a SIP / RTP voice path for direct connection to the IMS.
Carrier-grade, cloud-ready
Cluster setups for carrier-grade reliability, CUPS separation of control, data, and voice paths, and Kubernetes pools for heavy load. Monitoring through SNMP and HTTP alarms and counters and Prometheus metrics.
IPv4, IPv6 and dual-stack
Every interface runs over IPv4, IPv6 or both. The element fits an IPv6 core or a mixed network without a separate configuration.
Traditional MSC vendors supply a hardware platform, not a software product. The switching software runs only on their hardware, which means upgrades, capacity additions, and site changes all go through the same vendor at vendor pricing.
The Ouroboros smartMSC is software. It runs on COTS hardware, VMware, KVM, Docker, Kubernetes, or AWS / Azure — the same infrastructure that operators already run for HLR, SMSC, and other virtualised elements. One node combines MSC, VLR, SGSN, and STP. Capacity scales by adding nodes. Redundancy is a configuration choice, not a hardware purchase.
For operators running the full Ouroboros core, the smartMSC connects directly to the HLR, SMSC, EIR, the EPC, and the IMS with standard interfaces.
Home Location Register (HLR)
The smartMSC queries the HLR for subscriber data on every location update and call. The VLR keeps the result — but the HLR is the source of truth for subscriber profiles.
Gateway MSC (GMSC)
The GMSC routes inbound calls to the MSC serving the called subscriber. The GMSC handles the public network boundary, the MSC handles subscriber switching.
Serving GPRS Support Node (S4-SGSN)
The SGSN function of the smartMSC, also available as a standalone product.
Virtualised Evolved Packet Core (vEPC)
The MME and SGW of the vEPC connect to the smartMSC over SGs, Sv, S3, and S4.
Service Control Point (SCP)
The MSC uses CAMEL to trigger real-time charging events at the SCP. For prepaid subscribers, every call event — setup, mid-call, release — is validated against subscriber balance via the SCP.
Next step
Replacing your legacy MSC?
Tell us your current MSC vendor, subscriber count, radio access (2G, 3G, or both), and whether you need CAMEL prepaid or VoLTE continuity. We'll come back with a migration proposal and a timeline.