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.
There are two big enemies of mobile communication. Weak signal and battery drain. With the LTE technology in place we need to deal with the situation when our signal gets too weak. The higher frequencies have a problem to penetrate walls, currently the radio network is not covering whole country yet, etc.. these problems seems to be only temporary (as the LTE is moving forward) but at this point of time we can’t rely on the LTE network only. When we are out of 4G coverage while we are not calling we’ll simply fallback to CS network and VoLTE supports CS breakout or CS retry so our voice service is still working.
But what if it happens during an ongoing call? Can we handover and still maintain the session? It is possible but not easy as because of the battery drain we can access only one radio network at the time. What we are looking for is called enhanced Single Radio Voice Call Continuity (eSRVCC) and it is described in the GSMA IR.64 and ETSI TS 124 237. (SRVCC is applied during PS to CS access transfer in a single radio system from LTE to 3G/2G. For devices that support active WiFi, and 3G/2G and LTE dual radio, the enhanced Dual Radio Voice Call Continuity (eDRVCC) is applied.)
eSRVCC call flow is probably one of the most complex flows you can encounter in VoLTE. Read firstly about the basic flows VoLTE in IMS. In case of doubts or when more scenarios/details needed please refer to the spec.
To allow this functionality we need to add some more IMS elements in the network:
Access Transfer Control Function (ATCF)
ATCF acts as SIP signalling anchor and is located in the SIP signalling path between P-SCSF and S-CSCF. Very often it is part of the SBC. ATCF controls the ATGW, where the media plane is anchored. During the session transfer, the ATCF establishes a new session with the SCC AS. This new session substitutes the old session between the ATCF and the SCC AS.
Access Transfer Gateway (ATGW)
The ATGW anchors the media session.
Service Centralization and Continuity Application Server (SCC AS)
The SCC AS anchors originated and terminated sessions when using the PS or CS access. It is also responsible for the Terminating Access Domain Selection (T-ADS).
IMS Architecture for eSRVCC
WebRTC – what a great technology! The simple technologies are the best. Thank you Google for open-sourcing it! Now the WebRTC is a part of the Mobile Web Initiative/HTML5 driven by W3C.
Some technologies that were originally defined in Mobile Web Initiative are now defined in separate specifications. The WebRTC is one of them:
How is it possible? That’s because the most of the work was already done by developers of web browsers. Just try https://appear.in/realtimecommunication.
HTML5 ready browsers provide API to enable
- Voice and Video calling
- File sharing
as a standard content – so without plugins.
Well it’s nice, it’s working (although still in progress). WebRTC is being used by Google in their google hangout, most probably Amazon Mayday for Kindle Fire is based on WebRTC and many smaller players are following. For an enterprise business is this technology priceless. There are also some great solutions created with help of WebRTC which are focused also on other devices e.g.
Fluke Connect tm
Net Medical Xpress tm
So why we just don’t throw away all that uselessly complex stuff of IMS, VoLTE and (on the first place) RCS?
It is a part of nearly each IMS deployment. Session Border Controller. As the name indicates it sits on a border. A border between two networks. SBC is a controller so it controls all the traffic (both signalling and media) going through. So far so good. But what is really the SBC? What standards we can find? Where is some detail description of the SBC internal architecture? Sure, there are plenty of specs which are somehow describing the role of SBC. The basic one describing SBC is the RFC 5853.
SBC in VoLTE
The meaning of SBC has changed over the last 15 years significantly. We can say that SBCs are solving the problems which are not addressed by other IMS elements – problems with multiple access networks (e.g. IPv4 and IPv6, SIP normalization, VPNs..), security issues (DOS attacks, topology hiding, ..), legislative issues (emergency calls, legal intercept, interworking,..), media related problems (QoS, transcoding, media security,..). And of course, the number of these problems and issues which need to be solved is increasing. So what is the SBC now? As an SBC we understand a network element which is implementing following functionalities:
- Malicious attacks such as a denial-of-service attack (DoS) or distributed DoS
- Toll fraud via rogue media streams
- Topology hiding
- Malformed packet protection
- Encryption of signaling (via TLS and IPSec) and media (SRTP)
- Quality of service – the QoS policy of a network and prioritization of flows is usually implemented by the SBC. It can include such functions as:
- Traffic policing
- Resource allocation
- Rate limiting
- Call admission control
- ToS/DSCP bit setting
- Regulatory – many times the SBC is expected to provide support for regulatory requirements such as:
- Media services – many of the new generation of SBCs also provide built-in digital signal processors (DSPs) to enable them to offer border-based media control and services such as:
- DTMF relay and interworking
- Media transcoding
- Tones and announcements
- Data and fax interworking
- Support for voice and video calls
- Statistics and billing information
- WebRTC Gateway
If you know a bit about SIP and IMS you are probably aware that they are quite flexible. There are many ways how to do some solution and different vendors can easily come up with different implementation for the same thing.
In trainings people are asking very often – is this SIP message mandatory, what will happen if our client will not support this feature, what header attribute is the right one to identify xyz?
Well we have a huge number of specifications (from different organizations and bodies as 3GPP, IETF, OMA, GSMA, …). To avoid the confusion for VoLTE service GSMA created (yes another) document called VoLTE Service Description and Implementation Guide. This is not a classical spec, rather a guide what are the exact call flows and what message fields are relevant for the VoLTE.
We already know the registration from other posts (Registration, How to read tcpdump – Registration, Third party registration, Sh, ..). In the VoLTE the flow looks like this:
Have you ever thought about how this simple announcement works? Most of the (IMS aware) people believe that in order to establish a media session an UAC (originator’s handset) has to send the SIP ACK. This is true as long as we don’t need to inform the originator before the real voice or video call is established – e.g. running low on credit, informing about calling into foreign network, playing customized ring back tones etc.
In order to achieve this functionality the RFC 3960 introduced a concept of Early Media. The basic call can look like this:
In general this early media can be generated by caller, callee or both. In case that B2BUA is present – which is the case of TAS in VoLTE, the B2BUA can establish the Early Media session too.
One of the marketing reasons why one should prefer VoLTE instead of common VoIP is the Quality of Service. The framework for Policy and Charging Control is described in its own post. Here we’ll focus QoS support in SIP/SDP protocols. Note that this post goes in details and expects that you’re familiar with SIP/SDP session negotiation procedure. When we want to support QoS during the session negotiation we need to add so-called preconditions in the SIP INVITE:
The details can be found in the RFC 4032 and RFC 3312. The preconditions can be of several types as qos, connectivity or security. In order to support QoS there are dedicated fields in SDP:
current-status = "a=curr:" precondition-type
SP status-type SP direction-tag
desired-status = "a=des:" precondition-type
SP strength-tag SP status-type
confirm-status = "a=conf:" precondition-type
SP status-type SP direction-tag
precondition-type = "qos" | token
strength-tag = ("mandatory" | "optional" | "none"
= | "failure" | "unknown")
status-type = ("e2e" | "local" | "remote")
direction-tag = ("none" | "send" | "recv" | "sendrecv")
The logic is very simple. Each participant will define whether he/she has some desired status he/she wants to reach. Then during the SDP offer/answer negotiation they are simply checking if the current state >= desired state. Continue reading