Data roaming is an indispensable revenue generator for a telco operator. But, providing international data roaming service is no trivial feat.
The process starts with finding a suitable IPX (IP Exchange, formally known as GRX -GPRS Roaming Exchange) and establishing IP connectivity (usually) over 1Gbps links. Then the operator needs to update its Gp/S8, DNS, Diameter information in the IR.21 database. These efforts become fruitful only after securing roaming agreements with a significant number of RP (roaming partners, who need to have a presence on the same IPX). Once the contract is signed, the operators need to modify their firewall policy, configure diameter peering, define partners PLMN on MME and HSS, update preferred networks setting on UICC (the SIM card), etc.
When an operator commissions new nodes, let’s say -to scale up the capacity, a subset of the above workflow needs repetition, for example -floating updated IR.21 and waiting for RPs to complete network configuration. If the operator is fortunate enough, all these may take several months!
In a traditional Packet Core network, a typical deployment requires a few months of planning/installation/integration cycle. This lengthy implementation duration often hides the impact of slow roaming readiness. But with virtualized Packet Core (aka, vEPC), an operator can put specific VNF into production within a few days (for example -S/PGW-U in case of CUPS). But, such speedy VNF lifecycle management becomes severely limited by the excruciating sluggish roaming workflow.
The operators around the world adopted IPX NNI mainly due to the security vulnerability in the protocols used in the Packet Core. Interestingly, similar security risks are adequately addressed in the RAN. LTE, for example -uses a steam-ciphering algorithm (such as A5/x) to protect the air interface between handset and eNB, while it uses IPSec ESP (so-called, tunnel-mode) between eNB and core network. In the core, the IPSec tunnel terminates on a SeGW placed before S/PGW.
Unlike RAN, no rigorous protection exists for the core interfaces. The reference points, for example -S10, S11, S8, S5, S6a, etc. are supposedly confined within an operator’s private network, thus not subject to vulnerabilities that are applicable to the air interface or the Internet. But, for data roaming to take place, these core interfaces need to be exposed among many RPs.
GTP-C and Diameter are the two major protocols used for core signaling. Both of which carry a magnitude of network and user-specific information without any notion security.
GTP was chosen exclusively for its tiny overhead and ability to carry specific 3GPP parameters into its header. For example, an eNB can take the QCI value from the GTP header and map corresponding ERAB to appropriate DRB (Data Radio Bearer). As GTP resides on top of IP, the only way to secure GTP is through IPSec.
On the other hand, the Diameter, as the name suggests, is an enhancement to the RADIUS protocol (mathematically, Diameter is twice the Radius). Running on top of TCP, Diameter has a twofold problem. Like GTP, it needs IPSec for protection. Secondly, since there is no way to discover a Diameter peer dynamically, any new peering must be configurated manually.
Practically, to protect the signaling, it is not feasible for an operator to configure and maintain hundreds of IPSec tunnels between RPs. On the other hand, operators cannot use the public Internet to connect with RPs. As a solution, IPX NNI was introduced -which is a closed public network isolated from the Internet with a stiff standard.
In sharp contrast, the Internet already has an extremely agile NNI model, so-call IX (Internet Exchange). Many ISP collocate their POP in IXP (IX Point) and establish IP connectivity over 10Gbps links. Based on mutual agreement, they can immediately start peering with other ISP and Content Provider to exchange local Internet traffic. Unlike IPX, the large IX are often operated by 3rd parties -hence operator neutral. Moreover, with enormous capacity, the IX are more suitable for handling high aggregate throughput for 5G eMBB use-case.
In a broad sense, IPX and IXP are very similar NNI. In IPX, the V-PLMN is the source, and H-PLMN is the destination, and the traffic between the two is exchanged through IPX. The only reason, telco operators didn’t utilize an existing Internet NNI is due to “Security” concerns (as explained above). In the ISP industry, transit bandwidth is expensive, as a result, the only motivation behind IXP is the cost-efficiency. The market force shaped IXP operating model simple and flexible.
The 5G may change the situation. The RESTful API in SBA will replace both GTP-C and Diameter. A new function, SEPP (Security Edge Protection Proxy) is introduced to handle API signaling between V-PLMN and H-PLMN securely. In general sense, the SEPP is an API gateway, it uses TLS for authentication as well as for encryption, and OAuth framework for authorization. Such security capability and along with scalability of HTTP implies that the SEPP is more suitable for an IXP type NNI than IPX. Operating a SEPP on the Internet needs updating outbound BGP policy (instead of publishing IR.21 and waiting endlessly) and the use of public DNS (instead of Gp DNS and Gp Firewall). Using public DNS implies that, the hostname inside URL needs an Internet FQDN (instead of so-called “<mcc>.<mnc>.3gpp.org” delegation).
Lastly, the protection of user plane traffic over GTP-U depends on user applications. For example, if a user browses an HTTPS website, all traffic will be secured at the application layer. As a result, user plane traffic between UPFs in 5GC can be considered regular Internet traffic without additional security.
As we can see, 5G can unify both roaming and Internet NNI under ISP operating model. By doing so, it may disrupt the existing IPX industry (though 2G/3G/4G roaming will continue to exist over IPX). To harness the full potentiality of the virtualization of the telco cloud, we should embrace such disruption.