News: LTE in Sky

It’s called convergence. Two different approaches end-up with the same solution. In the nature it can be a bird and a bat (mammal). The both fly using wings although their ways to the result were quite independent.

In technology we can also use the synergism of the convergence. Simply we can reuse a technology which is already in place instead of creating a new one. A good example is the activity of NASA and Verizon to use the LTE eNodeB towers for air traffic control of drones (UAVs). Amazing – just a few years ago there was no LTE and no Drones.

Yesterday Deutsche Telecom (T-Mobile Germany) along with Inmarsat and Lufthansa announced their plans to create a new LTE network which would enable high-speed Internet for aviation passengers in Europe.


The network is called European Aviation Network (EAN). It will consist of the Inmarsat S-band satellite with multi-beam pan-European coverage and approximately 300 LTE sites. Each of the LTE sites will have a range of more than 80 km (comparing to traditional range of 10 km or less) and will be able to transmit data to the planes’ operating altitude. Moreover they should be flexible enough to deal with the speed of a plane. Lufthansa should start with a flight trial program in 2017.

Update: First trials

One wonders (with the coming IoT),  how far we’re from unpiloted flights now?


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

eSRVCC – Mind the coverage hole!

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


Continue reading

P-Early-Media – You are running low on credit!

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:

Early Media

Early Media

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.

Continue reading

It is about quality!

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:

Require: precondition

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
                            SP direction-tag
      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


The year 2015 is definitely a year of VoLTE. VoLTE is everywhere and operators are rolling out as crazy. There are plenty of articles describing how the LTE or LTE-A do work. We’ll put the LTE Packet Core part aside and take a look on the IMS related VoLTE architecture and VoLTE flows.

Voice over LTE service specified in GSMA IR.92. If you think it seriously with VoLTE, don’t waste your time on any blog and read the VoLTE Service Description and Implementation Guide. On the other hand real beginners can try our VoLTE Illustrated: Beginners Guide.

The very basic architecture of IMS for VoLTE can look like this:

VoLTE network architecture – simplified

During the LTE attach procedure VoLTE client receives IP address of P-CSCF.

  • P-CSCF (Proxy Call Session Control Function)
    • An entry point for IMS signalling. It is directly connected to the VoLTE device (UE) over SIP protocol.
    • P-CSCF maintains the security associations between itself and the UE.

The P-CSCF is usually a part of A-SBC.

  • A-SBC (Access Session Border Controller)
    • Provides connectivity for two or more IP networks, including IPv4 and IPv6 interworking, NAT traversal, etc.
    • Implements Security features, e.g. DoS, DDoS attack prevention, Topology Hiding, Encryption, CAC, ..
    • Communicates with access network (e.g. LTE) and is responsible for QoS
    • Handles Media Services, provides transcoding if needed

For the end-2-end signalling (voice call setup) we use SIP protocol. The multimedia then goes out-of-band using RTP protocol.

The heart of IMS network is IMS Core. It consists of often collocated I/S-CSCF, which cares about authentication, session routing and management.

  • I-CSCF (Interrogating Call Session Control Function)
    • I-CSCF provides a Location service. That means that for each subscriber (or public service) I-CSCF is able to locate the right S-CSCF.
    • I-CSCF also represents IMS network to peers. E.g. for peer networks the I-CSCF is the first point of contact.
  • S-CSCF (Serving Call Session Control Function) 
    • The S-CSCF is responsible for basic IMS services.  It is a SIP server providing session set-up, session tear-down, session control and routing functions.
    • S-CSCF acts as SIP Registrar – stores the binding between Public User Identity (e.g. sip uri or tel uri) and its actual point of presence (Contact IP address) and maintains user registration status. During VoLTE registration procedure S-CSCF performs user authentication.
    • S-CSCF also invokes Application Servers (TAS, IPSMGW) based on rules (IFCs) received from the HSS.

The IMS Core however doesn’t know anything about Voice or SMS service. That is a task for Application servers. The Application Server for voice and video telephony is called TAS – Telephony Application Server or MMTel AS – Multimedia Telephony AS.

  • Telephony Application Server (TAS) 
    • The application server responsible for all the services as address normalization, call diverting, call forwarding, barring, etc.
    • In a nutshell TAS is what makes the VoLTE enhancements on top of the pure VoIP.

VoLTE specification also defines SMS interworking. To support SMS over SIP we have a dedicated Application Server called IPSMGW. In more detail it is described in IPSMGW – Transport Level Interworking post.

IMS Core and Application Servers don’t have any persistent storage. All the information about subscribers and their services is stored in HSS (Home Subscriber Server). The communication between HSS and I/S-CSCF or TAS makes use of Diameter protocol.

Other IMS elements are:

  • MRF – Media Resource Function
    • Can be used as a media mixer or as a media server for playing of tones and announcements.
  • MGCF – Media Gateway Control Function
    • MGCF is used for the breakout to and from CS network. Usually the MGCF and MGW – Media GW is a part of enhanced MSC.
  • BGCF – Breakout Gateway Control Function
    • BGCF might be used in case when S-CSCF is not able to find the routing based on ENUM/DNS (e.g. PSTN number). Usually it is a part of IMS Core (along with S-CSCF and I-CSCF).

The IMS definition is very broad and flexible. GSMA VoLTE standard restricts it and defines what services are mandatory and how we should implement them. E.g. it defines how to implement Emergency Services, SRVCC, Roaming, SMS interworking, etc. In our post we will go through the basic LTE to LTE callflow.


Continue reading