An Éminence Grise – the DNS

In marriage we need to find a way how to make common decisions. In my case we decided that my wife will make those routine, unimportant decisions as what to cook for a dinner, how will spend a weekend or holidays or what to do with the money we have. My responsibility is to take the key, long-term decisions which will have the major influence on our well-being. So I decide what soccer team is our favorite for the next season, brand of a BBQ grill and what is our relationship towards EU.

In the IMS network there are many key network functions which take the decisions about routing, charging, applied services etc. But should I choose one which would allow me to manage the whole network, I’d go for DNS. Without DNS there would be no IMS. And don’t get me wrong. This is not only about the usage of IP protocol and symbolic address translation. DNS is responsible also for other vital mechanisms as routing, load-sharing, resiliency, service discovery and zero-configuration, provisioning, mobile number portability, timezone support, etc.

DNS is defined in many documents the most important for us are IETF RFC 1034, RFC 1035, RFC 3646 and mainly in RFC 3263 and RFC 7984 and GSMA IR.67.

Let’s take a look on routing in the IMS network.

Routing in IMS

 

We can start with the registration. Well, the DNS is used also during the ePC attach procedure. But we don’t discuses particular access networks here. (The Protocol Configuration Options – PCO response will contain the IPv4/IPv6 address of the P-CSCF anyway).  In the IMS the P-CSCF will take the Request-URI header of the SIP REGISTER message and based on the DNS response will identify the I-CSCF.

Headers in User-centric networks

One of the key reasons why we need the IMS is the support of multiple devices for the same public identity. Simply put we don’t care what physical device our counterpart has, we just call and it is up to the network to select the particular device or more devices. For example my buddy can be connected via 3G or 4G and wifi from his smartphone, and he can be also connected from a web browser using the WebRTC (and well there are already some operators testing this).

As the logic says the key headers which are being used for routing will remain the same.

The examples here are taken from real networks (AS/CSCF). The exact ids and IPs were modified. You can enjoy the diversity of headers we can find all around the world. There could be much more of them, but I don’t want to have the post too long and boring.

 

Request-URI

INVITE sip:0123456789;
phone-context=ims.mnc000.mcc000.3gppnetwork.org@ims.mnc000.mcc000.3gppnetwork.org;
user=phone SIP/2.0

or

INVITE sip:+12345678912@ims.operator.com;
user=phone SIP/2.0

or just

INVITE sip:12345678912@server.networks.operator.com SIP/2.0

 

P-Prefered-Identity

P-Preferred-Identity: sip:+12345678912@ims.operator.com

P-Asserted-Identity

P-Asserted-Identity: sip:+12345678912@ims.operator.com

P-Served-User

P-Served-User: <sip:+12345678912@ims.operator.com>;
sescase=orig;regstate=reg

 

Roaming in IMS

The biggest advantage of mobile operators – comparing to OTT applications – is that they are interconnected. No matter what country we are in we can connect into the network, we can place the calls, receive the calls, all under our own identity. We also don’t care in which network is our counterpart if he/she is now present in his/her home network or not. To achieve this operators need to support roaming and interworking.  The IMS Roaming and Interworking Guidelines can be found in the GSMA IR.65 and LTE Roaming Guidelines in GSMA IR.88.

GSMA Statistics – Interconnections

We’ve mentioned the roaming when we discussed the SBC. In this post we’ll take a look on what options we have. So what can be the flows when one of the participants is not physically present in the home network and needs to be connected via some other infrastructure – the visited network.

Just recently the GSMA announced the first commercial interconnected VoLTE service in South Korea. This just illustrates how far we’re still from the real IMS-based roaming.

Update: GSMA Next-generation Interconnection and Roaming Analysis for Mobile Services

In general there are 3 options how we can implement roaming nowadays:

Roaming opt. 1

Firstly the roaming can be done in the packet core. The P-CSCF is in the home network. But that requires a mechanism which obtains the IP address of the A-SBC. This solution called S8 (reference point) Home Routing (S8HR) is very easy and maybe a bit preferred by operators these days because that’s a standard way for data roaming.  However there are many open questions here related to Lawful Intercept, Emergency Calls, SRVCC, etc. GSMA works on a new variant of S8HR which is a part of the GSMA Network 2020 Programme and was recently as agreed as VoLTE Roaming candidate.

WebRTC GW

In the WebRTC and IMS post we briefly described the IMS and WebRTC integration. We explained that the WebRTC allows a rapid development of clients. The clients still need some infrastructure for the signalling and services – that’s the IMS. The network element which is acting as an interface between these two worlds – the world of web and the world of IMS is called a WebRTC GW. The WebRTC GW is a collection of network functions which we need for the translation of protocols, interworking and authentication procedures. It can be implemented as an enhancement of already present elements (e.g. eP-CSCF) or we can have a new stand-alone entity.

As we said the flows and procedures are described in the reference architecture for WebRTC – IMS communication in 3GPP TR 23.701 and 3GPP TR 33.871. Some new information and experience can be also found in GSMA WebRTC to complement IP Communication Services.

WebRTC GW

From the high-level WebRTC GW does the translation between http/ws to SIP and vice versa. When we go a bit more in detail there are many issues which have to be addressed.

• Authentication and Security Issues
• Protocol Issues
• Network Issues
• Media Issues
• Legal Issues