SOR

Support of Optimal Routing

Core Network →
Introduced in Rel-4

SOR is a CAMEL feature that enables optimal routing of mobile-terminated calls by querying the HLR for routing information when a subscriber is roaming, thereby avoiding inefficient tromboning routes.

Category
Core Network
Introduced
Rel-4
Where
Core Network › Legacy Core
Specifications
2 specs
SOR Description Purpose Related Classification Detected Changes Specifications

Description

Support of Optimal Routing (SOR) is a feature within the CAMEL (Customized Applications for Mobile network Enhanced Logic) protocol that optimizes the routing of Mobile-Terminated (MT) calls, particularly for roaming subscribers. Its architecture involves key Core Network nodes: the Gateway MSC (GMSC), the Home Location Register (HLR), and the Visited MSC (VMSC). When a call is placed to a roaming subscriber, the call typically first routes to a GMSC in the subscriber's home network. Without SOR, the GMSC would query the HLR, receive the Mobile Station Roaming Number (MSRN) from the VMSC in the visited network, and then route the call internationally from the home network to the visited network. However, if the calling party is located in the same visited country or a third country, this creates a 'tromboning' effect where the call leg travels unnecessarily to the home network and back, increasing latency and cost.

SOR works by enhancing the CAMEL interrogation process. When a call arrives at a GMSC, the GMSC can be configured to determine if optimal routing is possible based on the location of the caller. If the caller is determined to be in a location where a more direct route to the visited network exists, the GMSC initiates a CAMEL dialogue with a Service Control Point (SCP). The SCP, using its logic and potentially the caller's location, can instruct the GMSC to forward the call to a different network node or to use an alternative routing procedure. A key mechanism involves the GMSC sending a special parameter in the MAP_SEND_ROUTING_INFORMATION message to the HLR, indicating a request for optimal routing information. The HLR and VMSC cooperate to facilitate a more direct routing path, potentially by providing routing numbers that allow interconnection in a different, more optimal point in the network.

The primary role of SOR in the network is economic and performance optimization for international roaming scenarios. It minimizes the use of expensive international transit circuits managed by the home network operator, reducing Inter-Operator Tariffs (IOT). Technically, it reduces post-dial delay by shortening the call path, which can improve the user experience. SOR is tightly integrated with the MAP (Mobile Application Part) protocol and CAMEL service logic. Its deployment requires support in the GMSC, HLR, and potentially in the signaling network (e.g., STP configurations) to ensure the optimal routing queries and responses are handled correctly across different operators' networks, often governed by bilateral agreements.

Purpose & Motivation

SOR was created to solve the specific and costly problem of suboptimal call routing for roaming mobile subscribers, a major pain point in early international GSM roaming. Before SOR, the call routing for a roaming subscriber was rigid and followed a standard path: call to home network GMSC -> query home HLR -> contact visited VMSC for MSRN -> route call from home network to visited network. This model assumed the calling party was in the home country. However, with increasing international travel, a common scenario emerged: a caller in the same foreign country as the roaming subscriber (e.g., two tourists in Spain) would have their call routed back to the subscriber's home network (e.g., in the USA) only to be sent back to Spain, creating an inefficient and expensive 'trombone' route across international carriers.

This tromboning resulted in several problems: higher call setup times due to longer signaling paths, increased call failure rates due to more network segments involved, and significantly higher costs for both operators and end-users, as the call incurred international carriage charges on two long-haul legs. SOR addressed these limitations by introducing intelligence and flexibility into the call routing decision. It allowed the network to dynamically determine a more optimal path based on the caller's location, bypassing the home network when it was not the most efficient routing point. The motivation was primarily economic—to reduce the Inter-Operator Tariff (IOT) settlements between operators—but it also delivered a tangible improvement in service quality by making international roaming calls faster and more reliable. SOR became a crucial feature for operators with large outbound roaming subscriber bases to control costs and remain competitive.

Classification

Part ofCAMEL
Related approachesMAP

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (42 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Rel-15 4 changes

In Release 15, the SOR function was enhanced through updates to the DL and UL NAS Transport procedures and by mandating that the UE send a Registration Complete message for SOR. It was also extended to operate over the control plane in non-3GPP access networks. Furthermore, specific coding was defined for the SOR acknowledge message.

  • SOR acknowledge message coding TS 24.501CR0216
  • DL and UL NAS Transport procedure updates for SOR TS 24.501CR0357
  • SOR over control plane in non-3GPP access TS 24.501CR0592
  • Mandating UE sending registration complete for SOR TS 24.501CR0894
Rel-16 2 changes

In Release 16, the SOR function was enhanced with corrections to the length of the SOR transparent container and the UE parameters update transparent container. It also introduced corrections for the storage of 5GMM information, specifically defining the handling of the SOR counter and a UE parameter update counter. These updates provided more precise management of subscriber routing data and associated counters within the network procedures.

  • Corrections to the length of the SOR transparent container and UE parameters update transparent container TS 24.501CR0950
  • Correction to the storage of 5GMM information; SOR counter and a UE parameter update counter TS 24.501CR1426
Rel-17 18 changes

In Release 17, key enhancements for the Support of Optimal Routing (SOR) function included the introduction of the SOR-CMCI (Capability Management Control Information) for its transport and usage, along with a specific security check criterion for this container. The release also expanded SOR support to SNPNs (Standalone Non-Public Networks), defining procedures for CP SOR and enabling updates to SOR-SNPN-SI, while adding mechanisms for secure storage and acknowledgment of SOR information.

  • SOR-CMCI transport and usage TS 24.501CR3207
  • Alignments for the introduction of SOR-CMCI TS 24.501CR3365
  • CP SoR in SNPN - procedures and coding TS 24.501CR3584
  • Adding the SOR security check criterion to the SOR-CMCI TS 24.501CR3702
  • Enabling update of SOR-SNPN-SI in a PLMN TS 24.501CR3839
  • Addition of missing requirements for storing KAUSF, KSEAF, SOR counter and UE parameter update counter TS 24.501CR2858

+ 12 more changes

Rel-18 14 changes

In Release 18, the SOR function was enhanced with new capabilities for SNPNs, including the separate handling of the SOR-SNPN-SI-LS indicator and its clarification in the SOR ACK. The release also introduced time validity and location assistance information within the SOR transport container and provided corrections for UE handling of the SOR counter and connected mode procedures.

  • Time validity information and location assistance information in SOR transport container TS 24.501CR5682
  • CP-SOR corrections in 24.501 TS 24.501CR5920
  • Correction on SOR-SNPN-SI-LS IE coding TS 24.501CR5371
  • SOR transparent container clean up TS 24.501CR5413
  • Clarification for SOR-SNPN-SI-LS in SOR ACK TS 24.501CR5444
  • SOR-SNPN-SI-LS separate from SOR-SNPN-SI TS 24.501CR5471

+ 8 more changes

Rel-19 4 changes

In Release 19, the enhancements for the Support of Optimal Routing (SOR) function included clarifications and corrections to the SOR transparent container, specifically addressing the coding of the DNN within SOR-CMCI rules and adjustments to the SOR-CMCI length note. The updates also introduced the management of a "SoR count" parameter to refine the procedure executed by the MNP-SRF for optimally routing calls to ported numbers.

  • Correction on UPU and SOR transparent container TS 24.501CR6374
  • Correction to the Note for SOR-CMCI length TS 24.501CR6564
  • SoR count TS 24.501CR7105
  • Coding of the DNN in SOR-CMCI rule of SOR transparent container IE TS 24.501CR6778

Explore further

Broader topics and technologies where SOR plays a role.

Defining Specifications

3GPP specifications that define or reference SOR, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TS 23.066 vj00 Mobile Number Portability Technical Realization Rel-19
TS 24.501 vj50 5G NAS Protocols Specification Rel-19
Patrick Zandl

About the author: Patrick Zandl (b. 1974)

Telecommunications specialist, technology journalist (founder of the Mobil server), and developer who has been running since 2025 — the largest Czech-language resource on AI-assisted programming. Formerly Chief Wizard Architect at Prusa3D and head of development for Turris at CZ.NIC; currently a consultant and instructor on AI implementation in companies.