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.
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.
INVITE sip:firstname.lastname@example.org SIP/2.0
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.
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.
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
It is really hard to predict the future. The authors of SIP and SDP designed (1996) a great concept which really addressed the needs of not just real-time communication for the next two decades. But they also believed the the Network Address Translation (NAT) is only a temporary solution which will be obsolete once everyone will use IPv6. In 2015 we still use the NATs and I’d think (! the same mistake again) that we’ll use it for a couple more years.
NAT is technique which became in conjunction with IP masquerading a popular as an essential tool in conserving global address space allocations in face of IPv4 address exhaustion. These days the NAT is used also for security reasons e.g. topology hiding, port and IP restrictions etc.
The basic functionality of NAT is to translate one IP into another. Typically we can found NATs which mask behind one public IP a whole private network (one-to-many NAT). The traffic then can originate only from the private network (private IP space is not directly addressable from the public network).
Why we care about the NAT anyway? And what’s wrong with the SIP?
Right. Let’s remind that the SIP+SDP are used to establish a media session. It means we’re exchanging IP addresses of the originator and recipient which will be then used for (e.g. RTP, MSRP) data stream. These IP addresses are in the SIP body in the SDP content.
SDP with IP behind NAT
The media communication is then established on these IP:ports. As the addresses and ports are private the other clients can’t use them as they don’t see each other.
VoLTE and RCS support plenty of services – e.g. Call Forwarding, Call Barring or Presence. Some of these services can’t be pre-configured for the subscribers as each of them wants to provision his/her own forwarding/barred numbers or maybe doesn’t want to use the functionality at all. That means we need to have a way how to do a self-provisioning. In IMS we have a dedicated interface and network functionalities which allow to modify the setting of Supplementary Services and Presence Information directly from client (UE) via http/XCAP protocol. For VoLTE this is defined in the GSMA IR.92 and 3GPP TS 24.623, TS 24.423 and 3GPP TS 33.222. GSMA IR.92 directly says:
For supplementary service configuration, the UE and IMS core network must support XCAP at the Ut reference point as defined in 3GPP TS 24.623.
Wow – this is very important! There is not only the SIP/RTP between UE and IMS network but there can be also http (xcap)! Unlike SIP, HTTP is designed as a general-purpose data transport protocol. The purpose of SIP is mainly to create, modify, or terminate multimedia sessions. But sometimes we want to work with other types of data (e.g. configuration data, presence data, ..) which could easily overwhelm intermediate SIP proxies. HTTP is a good choice how to solve this issue.
What is the network architecture then?
Ut Reference Point
As we can see the http traffic does’t go through the SBC but through an Authentication Proxy (AP) instead. Its main purpose is to authenticate user requests. It is also used to separate the authentication procedure and the Application Server (AS) specific logic (e.g. Supplementary Service provisioning) to different network entities.
(In case of presence and OMA XDMS architecture we talk about so-called Aggregation Proxy, which is described in its own post.)
VoLTE in GSMA IR.92 is defining a set of standard Supplementary Services:
- Originating Identification Presentation 3GPP TS 24.607
- Terminating Identification Presentation 3GPP TS 24.608
- Originating Identification Restriction 3GPP TS 24.607
- Terminating Identification Restriction 3GPP TS 24.608
- Communication Forwarding Unconditional 3GPP TS 24.604
- Communication Forwarding on not Logged in 3GPP TS 24.604
- Communication Forwarding on Busy 3GPP TS 24.604
- Communication Forwarding on not Reachable 3GPP TS 24.604
- Communication Forwarding on No Reply 3GPP TS 24.604
- Barring of All Incoming Calls 3GPP TS 24.611
- Barring of All Outgoing Calls 3GPP TS 24.611
- Barring of Outgoing International Calls 3GPP TS 24.611
- Barring of Outgoing International Calls – ex Home Country 3GPP TS 24.611
- Barring of Incoming Calls – When Roaming 3GPP TS 24.611
- Communication Hold 3GPP TS 24.610
- Message Waiting Indication 3GPP TS 24.606
- Communication Waiting 3GPP TS 24.615
- Ad-Hoc Multi Party Conference 3GPP TS 24.605
IR.92 also says that for supplementary service configuration, the UE and IMS core network must support XCAP at the Ut reference point as defined in 3GPP TS 24.623.
The supplementary services are applied on the traffic by application server (MMTel) based on the information received from HSS/CNTDB (Sh/LDAP). Note we distinguish the originating and terminating services (based on presence of the ‘orig’ tag in the top-most Route header). We also distinguish weather or not is the user currently registered in the LTE network (based on the ‘regstate’ tag in the P-Served-User). E.g. some services are applied for recipients (terminating service) who are not present in the LTE (regstate=unreg) – as voice mail. More details can be found in the 3GPP TS 24.229.
VoLTE Supplementary Services