IMS from 10.000 feet

Over and over I need to go through the basics. One would think that everything was already said but sometimes a refresher is a good thing. Especially when we rely a bit on what we guess than on what we really know. I’m not any exception ūüôā

There are many¬†changes we can witness these days in operators’ networks.

The core network has become much more complex. We still have the 2G/3G mix in place, we added new LTE network, WiFi network, some operators are even introducing WebRTC GW. I’ll leave aside the IoT/M2M traffic – however very soon it will be the most important guy in town (now 2nd – 3rd biggest source of revenue for mobile operators).

Continue reading

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

 

Continue reading

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

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.

Continue reading

Ut interface – what is it for?

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 interface, ut volte

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.)

Continue reading

At your service..

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.

Route: <sip:mmtel@mmtel01.operator.com;lr;orig>,sip:1.2.3.44.50678.0.9000.@10.22.1.2:5070;lr;OdiPsi=mmtel>
P-Served-User: <sip:+123456789123@operator.com>;sescase=orig;regstate=reg

VoLTE Supplementary Services

Continue reading

Whatsapp Voice

RTC is speeding. Do you remember – just a few weeks ago there were 700 million monthly active Whatsapp users. Now it just passed 800 million monthly active users!

Whatsapp is also rolling out with voice calls! That can be a really bad news for operators. Does it mean that everyone will use Whatsapp now? Maybe – I’ve just found a post written by Dan York

[…]

Oh, and it’s owned by Facebook! ūüôā

Now, I personally don’t use WhatsApp that much right now. The people who I want to message are primarily using iMessage, Facebook Messenger or Wire. (And every once in a great while I’ll fire up Skype on my iPhone.)

But obviously there are 800 million people who do use WhatsApp each month…¬†and they now have free calling! (If they are on Android, iOS or BlackBerry 10… and subject to a staggered rollout, i.e. people will get the actual ability to call over the next while.) It will be fascinating to see how this plays out.

The problem of universal id (WhatsApp, Skype, Viber, telcos …) can be solve already by OAuth and¬†¬†OpenID¬†which are taking over. So the only issue which remains is who will pay the bill at the end ūüôā

If you are interested in some technical details and in what has the WhatsApp in common with the WebRTC, you can find an interesting post on https://webrtchacks.com/whats-up-with-whatsapp-and-webrtc/

This is an emergency!

I used to enjoy the feeling to be for two weeks in the mountings skiing or canoeing down the river and not to know anything about what happens in the world, without a weather forecast and without knowing about my friends and family. That’s what I call relaxation ūüėȬ†Mobile phones changed our behavior significantly. We’re always reachable and we never ever really switch off unless there is no signal. ¬†When there is no signal we start to feel uneasy – we can’t call and what if anything happens?

Mobile communication changed our way how we act in case of emergency and also its effectiveness. Emergency crews can get on scene much faster, have more information and can update emergency centers with the latest development. It is even possible to provide so called assisted first aid. On the other hand people rely sometimes on mobiles a bit too much.

‚ÄěZZS KV, KZOS v Jihlavńõ (01)‚Äú od Radim HoliŇ°, Wikimedia Commons. Licensed by CC BY-SA 3.0 cz via Wikimedia Commons

 

To support emergency calling is one of the basic requirements for VoLTE. When we need to reach a Public Safety Answering/Access Point (PSAP) or Emergency Control/Communication Centre (ECC), the common VoIP is not enough. That’s why we have some new elements in the IMS network. The relevant standards are¬†RFC 5031,¬†3GPP TS 24.229 and TS 23.167.

Continue reading