Tag Archives: IMS

LTE Femto Gateway with X2 Broker

14 Mar
 An LTE femtocell* (HeNB) is an ultra-small cellular base station that connects to a mobile operator’s LTE core network via broadband Internet. Using this femtocell, a mobile operator can eliminate indoor shadowing areas, thereby extending LTE service coverage and improving call quality.

* Femtocell and HeNB are interchangeable, and so are Femtocell Gateway and HeNB Gateway in this document.

The mobile operator can benefit from the femtocell as it allows LTE traffic to be distributed between macro eNB and femtocells at home and also at indoor and outdoor hotspots in crowded places like coffee shops, restaurants, bus stop, malls, schools, and so on. This helps the operator to effectively reduce loads at macro cells and in the backhaul, and provide its users with better QoE.

The beauty of LTE femtocell is that, as all it takes is simply connecting existing broadband Internet to an ultra-small base station, it gives the advantage of quick deployment. It also minimizes additional costs and burdens that may be imposed in case of building macro cells, in relation to installation site acquisition, site rental, power supply, construction of backhaul network, etc. Such benefits make it one of the most cost-effective ways to expand coverage and capacity in an LTE network.

Figure 1-1. Key values provided by femtocell in 4G era

Years ago, mobile operators started building macro LTE networks, and have always been in the quest for solutions to shadowing areas and high costs of operating multiple networks (2G, 3G and 4G) since then. Recently, operators are pursuing a strategy to i) provide uninterrupted voice coverage without relying on legacy networks like 2G or 3G by introducing small cells in shadowing areas and supporting seamless handover between them and macro cells, and ii) ultimately migrate into an all LTE network through gradual replacement of legacy networks.

That is, many operators are pushing forward with this strategy to minimize the total OPEX of the entire network by operating only one LTE network instead of multiple mobile networks. Femtocells are considered the most likely candidate to serve this purpose.

Meanwhile, operators without 2G or 3G, but with LTE macro network, are also active in introducing LTE femtocells in their networks as a cost-effective solution to enhance LTE coverage and capacity.

Here, what concerns the operators most is “uncertainty that can be caused while these femtocells (HeNB). Unlike existing macro cells, if deployed in a large scale – in tens or hundreds of thousands, these cells can cause unpredictable, operational risk while interworking with legacy LTE systems (EPC, eNB, etc.).”

SMEC’s Femto GW (HeNB-GW), designed to work as a sponge to absorb such uncertainty and risk, helps to operate the femto network just as stably as macro networks.

Chapter 2 will look into the benefits and issues of HeNB-GW, and chapter 3 will introduce HeNB-GW solution of SMEC, specifically X2 broker feature in details. Chapter 4 will summarize the benefits of the SMEC solution.


2. HeNB-GW: Benefit and Issues

2.1 Benefits

Table 2-1 summarizes issues in connecting HeNBs directly to MME, without HeNB-GW, as compared to the benefits of deploying HeNB-GW.

Table 2-1. Benefits of deploying HeNB-GW

2.2 Issues – X2 Handover Support

Mobile operators prefer X2 handover that uses just X2 interface between eNBs to more complicated S1 handover that increases loads at MME. As seen in Figure 2-1(a), the more HeNBs are deployed, the more hand-in and hand-out activities are performed between macro eNBs and HeNBs (particularly outdoors).

This means even more loads are caused at MME and S-GW by S1 handover, affecting the reliability of the LTE network. For more reliable, secured operation of the LTE core network, X2 handover without MME’s intervention is essential in a femto network (Figure 2-1(b)).

Figure 2-1. Handover options between macro eNB and HeNBs: S1 vs. X2


Figure 2-2. Issues: scalability and uncertainty

But in reality, supporting X2 handover in a femtocell environment is not easy because of possible scalability and instability issues. If existing macro eNBs establish X2 connections directly with a large number of HeNBs, scalability can be compromised due to the limit in the number of X2 connections that can be managed (Figure 2-2(a)).

For X2 handover, existing MME and eNB must interact directly with HeNBs (S1-MME, X2), and this process can bring about instability between the two (Figure 2-2(b)). Also, configuring X2 GW requires upgrade of eNBs and HeNBs all to R-12, consequently aggravating the complexity of the network even further.

These issues have been an obstacle standing in the way of applying X2 handover between macro eNB and HeNB in the commercial network. The HeNB-GW solution by SMEC is designed to address these issues. We will learn how in chapter 3.


3. SMEC HeNB-GW Solution


The Figure 3-1 describes a high level view of LTE network with femtocell and SMEC HeNB-GW. SMEC HeNB-GW can provide:

  • Virtual eNB (eNB ID based HeNB grouping)
  • X2 service broker (X2 proxy between eNB and HeNB)
  • S1 and X2 handover between eNB and HeNB
  • S1 signaling and bearer aggregation with SeGW functionality

Figure 3-1. SMEC HeNB-GW architecture

SMEC HeNB-GW, technologically based on virtual eNB concept, can group a number of HeNBs for management by group. Each virtual eNB, capable of aggregating 256 HeNBs, functions as a logical HeNB GW, providing S1 interface to EPC and HeNBs, and X2 interface to macro eNB and HeNB. From a S1 interface point of view, MME and S-GW see virtual eNB as ‘one macro eNB’, and HeNB sees it as ‘MME and S-GW’. Virtual eNB provides the following functionalities in respect of S1 interfaces:

  • Relaying UE-associated S1AP messages between MME and HeNB
  • Terminating non-UE associated S1AP procedures towards HeNB and towards MME
  • Terminating S1-U interfaces with HeNB and with S-GW

Virtual eNB, as a logical macro eNB, provides X2 interfaces. From X2 interface point of view, the macro eNB sees virtual eNB as an eNB with 256 cells that offers following functionalities:

  • Providing X2 interfaces between macro eNB and HeNBs
  • Terminating non-UE associated X2AP messages between eNB and HeNB
  • Converting UE-X2AP-ID between eNB and HeNB
  • Routing UE-associated X2AP messages between eNB and HeNB

3.2 X2 Service Broker

SMEC HeNB-GW features X2 service broker for complexity and stability issues as seen in Figure 2-2. As shown in Figure 3-2(b), each HeNB establishes X2 connection with virtual eNB (acting as a ‘X2 service broker’) at SMEC HeNB-GW, and macro eNB establishes only one X2 connection with the virtual eNB.

This X2 aggregation function provided by X2 broker drastically reduces the number of X2 connections needed between macro eNB and  HeNBs (256 X2 connections to only one X2 connection). SMEC HeNB-GW makes existing macro eNBs recognize it as another regular macro eNB, by hiding all the HeNBs behind its back.

Existing MME and eNB must interact directly with HeNBs (S1-MME, X2) for X2 handover, etc., and this can bring about instability between the two. X2 broker, upon receiving S1 and X2 messages from HeNB, modifies  the messages as if it is eNB itself, and sends them to MME and eNB. This ensures the stability of the LTE core network and eNB remains unaffected.

As a result, network complexity and unstability anticipated by deployment of HeNB can be significantly decreased, and kept as low as in existing macro eNB network. LG U+, a South Korean LTE network operator, has already deployed SMEC’s HeNB-GW, applying X2 handover between macro eNB and HeNBs in its commercial network. The company has been able to keep the load level at MME at a minimum and provide uninterrupted VoLTE service across femto hotspots in macro cells.


Figure 3-2. Benefits of X2 broker: scalability and stability

3.3 X2 Service Broker Operation

In order for X2 service broker to work, HeMS allocates HeNB IDs to HeNBs as seen in Figure 3-3. An HeNB ID is 28 bits long, and consists of i) an eNB ID (20 bits long), identical for all HeNBs (up to 256) that belong to the same virtual eNB, and ii) a cell ID (8 bits long), unique for all the HeNBs (up to 256). This HeNB ID plaNning scheme lets a macro eNB recognize a virtual eNB as just another macro eNB, and all the HeNBs belonging to it as its cells.


Figure 3-3. SMEC X2 service broker: HeNB ID planning

Detailed call flow for X2 broker operation is as follows:

❶ HeNB1 initiates TNL address discovery procedure towards an MeNB: HeNB1 detects a new cell (cell A of macro eNB) and decides to setup X2 towards Macro eNB (MeNB). It initiates an TNL address discovery procedure by sending eNB Configuration Transfer message indicating its own HeNB ID (HeNB1, 28 bits long) and MeNB ID (20 bits long) as neighbor information to virtual eNB through S1 interface.

The virtual eNB does not have any information on the MeNB’s X2 IP address, and it must forward the message to MME to find the X2 IP address of MeNB. Before forwarding the message, virtual eNB (X2 broker) replaces the 28-bit HeNB ID with its own ID (virtual eNB, 20 bit long) in the message and forwards it to MME. MME knows the MeNB and so sends an MME Configuration Transfer message to it (note that virtual eNB does not disclose 28-bit-long HeNB ID to MME and MeNB).


Figure 3-4. SMEC X2 service broker: HeNB1 initiates TNL address discovery procedure towards an MeNB

MeNB returns its X2 IP address, and MME sends it to virtual eNB (now, virtual eNB obtains MeNB’s X2 IP address). Virtual eNB replaces the MeNB’s X2 IP address in SeNB Information with its own IP address, and sends MME Configuration Transfer message to HeNB1. Then, this leads HeNB1 to recognize the virtual eNB IP address as MeNB’s X2 IP address.

❷ X2 setup between HeNB1 and MeNB: HeNB1 starts X2 setup towards MeNB, indicating its HeNB ID (virtual eNB (20b) + cell 1 (8b)) and MeNB as neighbor information. Since HeNB1 knows virtual eNB’s IP address as MeNB’s X2 IP address, this message is actually forwarded to virtual eNB. Virtual eNB starts another X2 setup procedure to continue the setup of X2-connectivity towards MeNB, indicating its own eNB ID (virtual eNB) and cell information (cell 1) and MeNB ID as neighbor information. When MeNB and virtual eNB responds, a single X2 connection is set up between HeNB1 and virtual eNB, and also between virtual eNB and MeNB.
This process lets MeNB add the cell information of HeNB1 (virtual eNB/cell1) to its X2 neighbor list and also lets HeNB1 add the cell information of MeNB (MeNB/cell A) to its X2 neighbor list.

Figure 3-5. SMEC X2 service broker: X2 setup between HeNB1 and MeNB

❸ Subsequent X2 connection setups: As X2 connection between virtual eNB and MeNB has already been setup, any further X2-address request from other HeNBs for X2-connectivity towards MeNB will be responded by the virtual eNB without forwarding the request via the MME towards the MeNB. Virtual eNB sends its own IP address in response to other HeNB’s X2-address request to the MeNB.

For any further X2 setup request to the MeNB, virtual eNB, through the already-established X2 connection, sends an X2 message (eNB Configuration Update) containing HeNB2 cell information to inform MeNB of the updated cell information.

Virtual eNB sends X2 Setup Response to HeNB2 if the X2 Configuration Update between the virtual eNB and MeNB is performed successfully.

Figure 3-6. SMEC X2 service broker: Subsequent X2 connection setups

Once the above process is completed, an X2 connection is set up between each HeNB and virtual eNB (HeNB-GW), and also between virtual eNB and macro eNB. Logically, existing macro eNB recognizes HeNB-GW as a new macro eNB, and all HeNBs belonging to it as cells in the macro eNB as shown in Figure 3-7.


Figure 3-7. SMEC X2 service broker: Logical configuration

This means, the legacy LTE network (eNB and EPC) will see even a large-scale deployment of HeNBs as a small-scale deployment of additional macro eNBs. This completely eliminates any chance of uncertainty, complexity, or risk factors that would otherwise be caused by a large-scale deployment of HeNB in the legacy LTE network. For example, because the 28-bit HeNB IDs are not exposed to MME or eNB, there is no potential issue in interworking between HeNBs and MME/eNBs, which makes the network architecture even more stable and reliable.

As the X2 service broker feature by SMEC is implemented using S1 interface (eNB n MME) and X2 interface (eNB n eNB) defined in Rel. 8, no change or modification is needed in the EPC core or eNBs already deployed in the legacy LTE network. This makes the feature readily applicable to any LTE commercial network where Rel. 8 or higher is implemented (i.e., in any LTE network).


4. Benefits of SMEC HeNB-GW

SMEC’s HeNB-GW helps to keep the impact of introducing LTE femtocell – even when massively deployed – in the legacy LTE network low, as low as that of small scale addition of macro eNB. This ensures the stability of the LTE core network remains unaffected and the additional investment costs resulting from such deployment are kept to a minimum.

  • SMEC’s HeNB-GW delivers both SeGW feature and aggregation feature (for control plane, S1-MME and user plane, S1-U) at a single point, proactively preventing overload at existing MME and S-GW, and also easing potential uncertainty in the legacy LTE network to be caused by tens of thousands of newly deployed femtocells. Also, it helps to bring down the costs for additional installation of MME resulting from the large scale deployment of femtocells (e.g. purchasing additional equipment and license).
  • SMEC’s HeNB-GW supports S1 and X2 handover between macro eNB and femtocell, which ensures uninterrupted, reliable call quality, even during switches between the two cells – all just through 4G network (i.e. just through VoLTE) without 2G or 3G.
  • SMEC’s HeNB-GW offers X2 service broker feature that provides X2 handover between macro eNB and HeNB without having to modify X2 interface used between the macro eNBs.
  1. Traditional HeNB-GW can only support S1 handover, and thus heavy overloads are inevitably passed on to MME during handover. SMEC HeNB GW, however, supports X2 handover where no MME involvement during handover process is needed, drastically reducing overload at MME.
  2. It significantly reduces the number of X2 interfaces needed through aggregation of X2 interfaces between macro eNB and femtocells, thereby decreasing network complexity to be caused by X2 interface used in small cell environment.
  3. The X2 service broker feature by SMEC, implementable through S1 and X2 interfaces defined in 3GPP Rel. 8., is readily deployable in any LTE system regardless of its release version. Without additional installation of X2 GW nodes defined in R-12 or upgrade of R-12 X2 GW feature license of MME, eNB and HeNB, or of LTE network, X2 handover between macro eNB and HeNB can be readily supported.



3GPP 3rd Generation Partnership Project
eNB Evolved Node B
EPC Evolved Packet Core
GTP GPRS Tunneling Protocol
GW Gateway
HeMS HeNB Management System
HeNB Home eNodeB (Femtocell)
HeNB-GW Home eNodeB Gateway (Femto Gateway)
ID Identifier
IMS IP Multimedia Subsystem
ISP Internet Service Provider
LTE Long Term Evolution
MeNB Macro eNB
MME Mobility Management Entity
PGW Packet Data Network Gateway
QoE Quality of Experience
RAN Radio Access Network
SCTP Stream Control Transmission Protocol
SeGW Security Gateway
SeNB Source eNB
SOHO Small Office Home Office
S-GW Serving Gateway
TNL Transport Network Layer
UE User Equipment
VoLTE Voice over LTE
X2 AP X2 Application Protocol
X2 GW X2 Gateway


SMEC’s LTE Femto Gateway with X2 Broker – Facilitating instant mass deployment of LTE femtocells in existing LTE infrastructure
March 14, 2016 | By Y.C. Lee (www.esmec.com), Dr. Harrison Jangwoo Son (tech@netmanias.com)


Source: http://www.netmanias.com/en/?m=view&id=reports&no=8493


LTE-A Pro for Public Safety Services – Part 1

25 Jan

In October 2015, 3GPP has decided to refer to LTE Release 13 and beyond as LTE-Advanced Pro to point out that LTE specifications have been enhanced to address new markets with special requirements such as Public Safety Services. This has been quite long in the making because a number of functionalities were required that go beyond just delivery of IP packets from point A to point B. A Nokia paper published at the end of 2014 gives a good introduction to the features required by Public Safety Services such as the police, fire departments and medical emergency services:

  • Group Communication and Push To Talk features (referred to as “Mission Critical Push To Talk” (MCPPT) in the specs, perhaps for the dramatic effect or to perhaps to distinguish them from previous specifications on the topic).
  • Priority and Quality of Service.
  • Device to Device communication and relaying of communication when the network is not available.
  • Local communication when the backhaul link of an LTE base station is not working but the base station itself is still operational.

Group Communication and Mission Critical Push to Talk have been specified as IP Multimedia Subsystem (IMS) services just like Voice over LTE (VoLTE) that is being introduced in commercial LTE networks these days and can use the eMBMS (evolved Mobile Broadcast Multicast Service) extension in case many group participants are present in the same cell to only send a voice stream in the downlink once instead of separately to each individual device.

In a previous job I’ve worked on the GSM group call and push to talk service and other safety related features for railways for a number of years so all of this sounds very familiar. In fact I haven’t come across a single topic that wasn’t already discussed at that time for GSM and most of them were implemented and are being used by railway companies across Europe and Asia today. While the services are pretty similar, the GSM implementation is, as you can probably imagine, quite different from what has now been specified for LTE.

There is lots to discover in the LTE-A Pro specifications on these topics and I will go into more details both from a theoretical and practical point of view in a couple of follow up posts.

Source: http://mobilesociety.typepad.com/mobile_life/2016/01/lte-a-pro-for-public-safety-services-part-1.html

Telephony – Telco service or Internet application?

9 Jun


When comparing different forms of VoIP, one risk comparing “apples and oranges”. Broadly speaking, we can divide VoIP into two main categories. First, the service can be implemented as a faithful copy of circuit switched telephony; in a network with full control over performance and quality. Second, VoIP can be implemented as a standalone application used over the open Internet.

Originally published in NetworkWorld Norway.


3GPP and IMS

3GPP (3rd Generation Partnership Project) has played an important role when VoIP has become a recognised substitute for traditional telephony among telecom operators. 3GPP standardises the mobile technologies 2G, 3G and 4G, and they have done so based on the general IP technology standardised by IETF (Internet Engineering Task Force).

At first 3GPP concentrated on developing mobile networks as an evolving telecommunications architecture, following a vertically integrated model for provision of telephony. As the Internet revolution influenced the telecom market, the focus has shifted more towards IP-based services of various kinds.

IP networks and the Internet are not equivalent concepts. As IP technology was introduced in the mobile architecture, this was done in a way that maintained telecommunications networks’ support for QoS (Quality of Service). They had a clear view to continue provision of telecom services, as opposed to Internet applications, but based on a new IP-based network.

The service platform which was standardised as part of the mobile architecture was named IMS (IP Multimedia Subsystem). IMS is based on SIP (Session Initiation Protocol), the VoIP protocol from IETF, but extended with a comprehensive architecture for QoS. IMS has an “open” interface for service development, but requires a business agreement with the mobile operator. So this is a completely different kind of openness than the one found on the Internet where “everyone” can develop their own services.


The basic mobile architecture has undergone a tremendous development by 3GPP. Now we are in a phase where LTE (Long Term Evolution) is being adopted, often referred to as 4G despite the fact that it is not “real” 4G. LTE is the first 3GPP architecture that has eliminated the circuit switched domain, appearing as a pure IP network. Therefore there are great expectations for VoIP in this architecture, a functionality called VoLTE (Voice over LTE).

The transition from traditional telephony to VoIP has been going on for a long time. In mobile networks this has taken longer than expected. IMS has been around as a part of the mobile architecture for many years already. Furthermore, VoLTE includes options that could still delay this transition; LTE phones will initially combine LTE with older mobile technologies, allowing telephones to fall back to these older technologies. There is also a quasi-solution that transports traditional telecom protocols encapsulated in IP packets, so-called VoLGA (Voice over LTE via Generic Access).

The telecom industry also promotes advanced VoIP services that can stimulate the transition from traditional telephony and SMS to IP-based “equivalents” called RCS (Rich Communication Services). RCS provides services such as voice and video telephony, presence, instant messages and more, integrated in a unified user client for mobile phones that will provide seamless user experience of multimedia communication.

RCS is based on the IMS platform using SIP and SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions). Thus, the basis of this is IETF protocols, but implemented in an architecture that is intended to replicate the telecom network in the shape of an IP-based multimedia network. RCS is promoted by GSMA (GSM Association) and OMA (Open Mobile Alliance). OMA is the descendant of the WAP Forum, if there are still some who remember WAP.

QoS and Policy Control

RCS seems like an impressive technology, and what is the big deal? What distinguishes this from the applications that are already in use on the Internet? A major difference is that RCS can benefit directly from the mobile network built-in mechanisms for QoS. But it is difficult to predict what will give the best user experience, multimedia services integrated in the mobile architecture or free choice among different applications offered over the Internet.

A well-known characteristic of the Internet is that it is “best effort” and can’t guarantee the quality of the communication. In the mobile architecture, QoS is a key feature across the entire design. The underlying IP network will typically be based on DiffServ (Differentiated Services) and MPLS (Multiprotocol Label Switching), both well-known technologies from IETF supporting traffic management and QoS.

In the LTE architecture, QoS is policed by a function called PCC (Policy and Charging Control). As the name suggests, not unnaturally, management of QoS and charging are two sides of the same coin. PCC controls establishment of user sessions with various performance levels, and charging information is generated based to the capacity used by the different sessions.

Initially, IMS was specified for mobile networks, but in retrospect it has been found very useful extending the scope to include fixed networks, giving a combo solution which is often referred as NGN (Next Generation Networks). This facilitates convergence between fixed and mobile networks (Fixed-Mobile Convergence).

Over-the-top (OTT)

The traditional telcos are operating in a market that is completely changed because of the Internet. This leads to a situation where the business that telecom players envision, is facing strong competition from Internet players. The Internet model is based on decoupling of applications from the network layer, as opposed to the telecom model that relies on the services that are vertically integrated with the network.

Innovative solutions that can be used “over-the-top” without specific facilitation from telecom operators, enables virtually unlimited choices for end users. Internet applications, even real-time applications such as VoIP, work fairly well without the quality architecture of NGN. Congestion control mechanisms regulate traffic load of the Internet, sharing the available capacity between users.

However, users’ choice is not easy. Such innovative solutions in some cases evolve into isolated “islands” that are not compatible with each other. Major players are trying to create their own closed ecosystems consisting of operating systems or app stores for example. On the other hand, some traditional telecom operators introduce OTT solutions to meet the competition, making use of similar means.

The future will show which model is most adaptable. Net neutrality is tasked to ensure that the Internet model can develop freely. Meanwhile, the Norwegian guidelines for net neutrality are balanced, allowing the telecom model to evolve in parallel. This is often referred to as “specialised services”, as opposed to the Internet access service that works as a general electronic communication service.

Source: http://ipfrode.wordpress.com/2013/01/21/telephony-telco-service-or-internet-application/

VoLTE Roaming with RAVEL (Roaming Architecture for Voice over IMS with Local Breakout)

17 Feb

Voice over LTE or VoLTE has many problems to solve. One of the issues that did not have a clear solution initially was Roaming. iBasis has a whitepaper on this topic here, from which the above picture is taken. The following is what is said above:

The routing of international calls has always been a problem for mobile operators. All too often the answer—particularly in the case of ‘tromboning’ calls all the way back to the home network—has been inelegant and costly. LTE data sessions can be broken out locally, negating the need for convoluted routing solutions. But in a VoIMS environment all of the intelligence that decides how to route the call resides in the home network, meaning that the call still has to be routed back.

The industry’s solution to this issue is Roaming Architecture for Voice over LTE with Local Breakout (RAVEL). Currently in the midst of standardisation at 3GPP, RAVEL is intended to enable the home network to decide, where appropriate, for the VoIMS call to be broken out locally.

Three quarters of respondents to the survey said they support an industry-wide move to RAVEL for VoLTE roaming. This is emphatic in its enthusiasm but 25 per cent remains a significant share of respondents still to be convinced. Just over half of respondents said they plan to support VoIMS for LTE roaming using the RAVEL architecture, while 12.3 per cent said they would support it, but not using RAVEL.

Until RAVEL is available, 27.4 per cent of respondents said they plan to use home-routing for all VoLTE traffic, while just under one fifth said they would use a non-standard VoLTE roaming solution.

Well, the solution was standardised in 3GPP Release-11. NTT Docomo has an excellent whitepaper (embedded below) explaining the issue and the proposed solution.

In 3GPP Release 11, the VoLTE roaming and interconnection architecture was standardized in cooperation with the GSMA Association. The new architecture is able to implement voice call charging in the same way as circuit-switched voice roaming and interconnection models by routing both C-Plane messages and voice data on the same path. This was not possible with the earlier VoLTE roaming and interconnection architecture.

Anyway, here is the complete whitepaper

Source: http://blog.3g4g.co.uk/2014/02/volte-roaming-with-ravel-roaming.html

The Case for VoLTE

9 Sep

Despite the introduction of LTE with its heavy focus on improved mobile broadband speeds, mobile operators still rely on voice and SMS services for a large part of their revenues (roughly 70% globally). In previous generations of mobile technology these services were explicitly supported as part of the mobile network stack, with voice bearers supported in the radio access network and SMS making use of the voice signalling mechanisms. Indeed in 2G mobile standards data was originally only supported by sending data over a nailed up voice channel (high-speed circuit switched data or HSCSD) with the native data transport mechanisms of the general packet radio service (GPRS) introduced later as part of the so called 2.5G standards and in enhanced form as EDGE with 2.75G.

With the advent of 3G mobile standards (such as UMTS) voice and data were catered for on an equal footing, with distinct voice and data air interfaces being defined, each optimised for their respective payload. The lu-CS interface, used for voice, uses circuit switching to provide deterministic, guaranteed capacity for in-progress voice calls. In contrast, the lu-PS interface, used for data, uses packet switching on a shared data carrier to maximise the efficiency of data transport.

Compared to 2G, the 4G LTE standard turns the situation on its head and is optimised for data services without any specific native support (i.e. circuit switched) for voice transport. The rational for this is that broadband traffic is now the predominant use of mobile bandwidth and it is better to optimise the network for data transport and carry voice as an application over data using voice over IP. This is possible in an LTE network due to the substantial enhancements in the data plane, which compared to 3G has significantly reduced latency and has the quality of service mechanisms required to support a good quality voice service.

Although LTE was, from the outset, designed to support voice service via voice over IP (VoIP), the call flows, their associated signalling and media encoding where not defined or standardised. So although all the “hooks” where in place to support voice their was no voice standard that an operator could deploy and indeed there were many options, a number of which were debated at length by equipment vendors and network operators as part of the standards process.

Given the importance of voice (and SMS) this lack of standardised support for voice could be regarded as a serious omission. To mitigate this a mechanism called circuit switched fall-back (CSFB) has been introduced which entails the phone switching to 3G operation when a voice call is to be made or received.

As indicated above, there has been much debate about the standard approach for supporting voice (and SMS) over LTE. One approach, called VoLGA, which was proposed was to utilise existing UMA mechanisms such as those supported on some mobile phones (notably Blackberries) to tunnel voice across WiFi. Whilst this would have leveraged existing voice switching networks it had the disadvantage of being quite backward looking and not providing a future path to full multi-media communications. Instead the approach using native VoIP with SIP signalling and an IMS (IP multi-media subsystem) core found favour as the approach for voice over LTE (VoLTE) with circuit switched fall-back being used as a transitionary step.

As of today (September 2013) VoLTE standardisation is more or less complete and both handsets and network equipment are available. Nevertheless, there are very few deployments of VoLTE – to this author’s understanding one in the US (MetroPCS) and three in South Korea (SK Telekom, KT and LG U+). Whilst it is clear that operators will eventually embrace VoLTE what is not clear is how rapidly operators will move to do so.

On the one hand aggressively introducing VoLTE could enable network operators to refresh their voice product set, so as not to be left behind by the over the top (OTT) voice and messaging service providers such as Skype and WhatsApp. On the other hand, existing voice and SMS revenues are not yet necessarily under threat and it may be better to take a slow and steady approach. This paper sets out the different approaches network operators could take and the rational for preferring one approach to another.

Broadly speaking network operators have three approaches they may take for introducing VoLTE (with various shades of grey in between). They may:

  • Stick with the existing solution of circuit switched fall-back (CSFB) for the foreseeable future,
  • Gradually introduce VoLTE over a period of time thus operating CSFB and VoLTE in parallel, or
  • Aggressively migrate to VoLTE to obtain the benefits of improved service and network rationalisation sooner rather than later.

Circuit Switched Fall-Back (CSFB)

For an operator with an established 3G network and customer base, continuing to use CSFB (circuit switched fall-back) can make a lot of business sense, as it continues to exploit an existing asset that often will already have sufficient call carrying capacity. In this case, for those customers with LTE handsets, the downside of CSFB is slightly impacted voice service performance:

  • There is an increased call set-up time of several seconds as the phone connects to the 3G network, and
  • Data connections will likely be dropped as the phone reconnects to the network and is likely allocated a different IP address.

Whilst these issues do impact the service they are unlikely to be sufficiently troublesome to the customer to underpin a business case for the substantial investment required to enable VoLTE.

Introducing VoLTE into a network is not straightforward. It requires a new mobile voice core (IMS) and represents a substantial change in the way voice service is provided. This change from circuit switched to end-to-end VoIP as required by VoLTE means that new skill sets are required within the organisation and there is much to be learnt with respect to how to optimise the network to get the best voice performance. Putting aside business case considerations, these factors alone would suggest that an operator should approach the introduction of VoLTE cautiously.

OTT Service Competition

Whilst operators should approach the introduction of new technology cautiously, operators may also wish to seize the opportunity presented by the introduction of an IMS core as a enabler to more generally reinvigorate voice service, linking the launch of VoLTE service to wider reaching service improvements:

  • Introduction of a better quality voice service, with wide-band CODECs and faster call set-up time,
  • Linking to the introduction of RCS (rich communication services), often marketed as “joyn”, incorporating presence, instant messaging, group calling and video sharing,
  • Enabling service to be accessed more generally, for example, enabling calls to or from the mobile phone number to be made from a PC client, tablet or fixed line.

Nevertheless, it can be argued and often is, that these services will not attract additional revenue but instead just protect current revenues, giving customers additional value for their money, making them less inclined to use alternative services. In this view, customers will not pay more for voice services and consequently other revenues sources must be sought – of which the most likely candidate is video. For example a video sharing service called “See what I can see” is a service that we can all identify with. Additional revenues associated with such new services, however, are unlikely to pay for the cost of introducing an IMS core to support VoLTE and the rich communications services (RCS) server.

In the opinion of this author, much of the analysis presented in the previous paragraph is in all likelihood correct but the conclusion that there is little value in investing in voice services is questionable. If voice services are genuinely under threat from competition, especially from over the top (OTT) providers and device manufacturers such as Skype, WhatsApp, Google, Apple and even FaceBook then there is financial value in defending existing revenues. It should not be forgotten that much of the competition from OTT providers has heretofore impacted fixed voice revenues. However, with the increasing performance of mobile broadband networks, especially after the wide spread introduction of LTE (and in the future LTE-A) there will be little to stop OTT providers encroaching on traditional mobile operators’ revenue streams.

Compared to fixed operators, mobile operators are typically at an advantage as mobile calling is normally part of a bundle and if a subscriber makes fewer calls within the bundle it actually saves the operator money. This is fine in the short term, but customers will sooner or later perceive that when they are making few traditional voice calls, and not sending so many SMSs that they are getting poor value for money and migrate to operators who are selling “value based” mobile packages with a focus on charging just for data. In this world, operators will then fall into one of two categories:

  • Those that effectively compete with OTT providers and retain voice and messaging revenues, or
  • Those that accept that they cannot compete with OTT providers and focus on providing a mobile broadband pipe in the most cost effective manner.

Currently most operators see themselves as being in the first category but are doing very little to make this a reality. Much more could be written on this topic, and this will indeed be the topic for a future paper.

The problem for operators faced with producing a business case for VoLTE and by implication IMS is that there is much uncertainty to the extent of the risk from competition from OTT services and equally there is uncertainty into how well defensive measures against the threat may work. In most organisations it is difficult to get financial approval for such uncertain business cases. Indeed matters can be worse than this, for example, a strategy to replace SMS by an operator’s own equivalent of WhatsApp could well be perceived to undermine existing SMS revenue and consequently be unpalatable.

It is seen in industries again and again that the market leaders are unwilling to risk undermining existing revenue streams and investing in uncertain innovation. This is left to entrepreneurs who thrive on risk and are willing to take a chance, “having a go” at the established market players. Few typically succeed, but the ones that do reap rich rewards, whilst the original market leaders fade into insignificance. One only has to look at the computing industry where DEC and Sun are no more, and the situation in the mobile industry where Nokia and Blackberry have fallen from their positions of pre-eminence.

In summary, a small proportion of operators will believe that it is their strategic interest to deploy IMS and VoLTE and will find ways to make the business case work. However, most operators will not take this leap of faith and will take a much tougher view of revenue threats and opportunities, effectively only considering in the bottom line of the business case those factors that they can be definitive about.

Operator Benefits

Looking beyond the direct customer benefits, from an infrastructure perspective, VoLTE presents a number of opportunities to network operators:

  • Over time it will let them simplify their network as the old circuit switched voice infrastructure is closed down.
  • It will no longer be necessary for the operator to continue operating 3G service in all LTE coverage areas (as would be required by CSFB). This means that the 3G spectrum can potentially be re-farmed, for example to increase the available LTE spectrum.
  • The complexity of handsets may be reduced. At the present time, for example, there are not chipsets that support both LTE and CDMA. In this case dropping support for CDMA would reduce the cost of the handset – but would of course require the voice to be transported natively over LTE (via VoLTE). This is less of a driver for 3G UMTS operators as there are chipsets that support both this and LTE.

It will be clear that most of these benefits come from being able to turn circuit switched voice infrastructure off and re-farm 3G (or 2G) spectrum as LTE. The most significant barrier to this is likely to be the existing customer base and their handsets. Whilst the traditional upgrade cycle for mobile phones is quite rapid it is still in most markets too early too expect everyone to upgrade to the latest LTE SmartPhone that supports VoLTE. Moreover most operators will have a sizeable rump of low usage customers who change their handset infrequently, and whilst these will not be the highest paying users an operator will still be reluctant to loose these subscribers.


Another challenge at the present time with VoLTE is the support for roaming. Whilst the technical (3GPP) and interconnect (GSMA) standards are being progressed, even when they are complete, for the initial network deployments of VoLTE there will be few other networks to connect to that do have VoLTE – so for roaming users, even if VoLTE is present in the home network, circuit switched fall-back will have to be relied on for a substantial period yet. This means that handsets for users who expect to roam will have to support 3G with circuit switched fall-back for voice.

Example 1: MetroPCS

One of the few network operators to have launched VoLTE is MetroPCS in the US. What the author understands of their case, based on publically available information and assumptions is the following:

  • They are a pre-pay operator focused on specific markets in the US.
  • They have limited spectrum and are keen to re-farm existing 3G spectrum as LTE.
  • Their existing 3G network is CDMA requiring dual chipset in the handset to support both it and LTE.

MetroPCS’s public statements make it clear that they are aggressively launching VoLTE in their different markets with a view to:

  • Simplifying / reducing the cost of the handset as just including an LTE radio means that a CDMA chipset is not required.
  • Enhancing the service via the introduction of RCS based services.
  • Plan to shift investment to LTE infrastructure only with a view to re-farming CDMA spectrum as LTE when possible.

Given MetroPCS’s heavy promotion of the benefits of an LTE only handset with VoLTE. It must be assumed that the majority of its customers have limited need for coverage outside of their specific market area (though this will improve as MetroPCS rolls out LTE to more of its markets) and limited, if any roaming requirements. This may well be true for their target market segment – low cost, pre-pay users. It is assumed that users requiring great coverage flexibility will continue to use at least dual band LTE / CDMA handsets.

To enable it to cap investment in CDMA and eventually re-farm CDMA spectrum as LTE MetroPCS will need to rapidly shift its customers to LTE / VoLTE capable handsets. It is assumed that given the nature of the pre-pay market, there is a high degree of customer churn which could facilitate this. Nevertheless, to achieve it, MetroPCS will require an attractive range of LTE/VoLTE handsets, something which is still somewhat of a challenge.

Note that as of May 2013 MetroPCS has been acquired by T-Mobile. This may well change their approach to the aggressive introduction of VoLTE as it offers them a number of options to use T-Mobile’s existing coverage and extensive handset range. Nevertheless, MetroPCS has acted as a proving ground for VoLTE and this may well also lead to a change in T-Mobile’s approach.

Example 2: EE

Following the merger of Orange and T-Mobile in the UK to form EE, EE are now the largest mobile operator in the UK. They were the first operator to launch LTE in the UK using their existing 1800MHz spectrum prior to the auction of the “official” LTE spectrum.

EE’s public position is that whilst they will to continue to invest heavily in LTE to improve data rates they are not aggressively developing VoLTE. They state:

We found circuit-switched fallback [CSFB] for voice very stable from the beginning by putting deliberate aspects in for it with our core network vendors. We find that fallback is very reliable, and delays are minimal. It’s efficient as a solution, so we haven’t seen a need to rush to VoLTE. It will bring some additional benefits, but CSFB solution is good enough as a service.

It would be a fair guess to make that EE are actively investigating VoLTE and ensuring that new SIMs and handsets will be compatible with it wherever possible. It is also fair to say is that they do not see a business case for deploying VoLTE in the near future. This makes sense for EE:

  • They have more than sufficient spectrum holdings to operate 3G and LTE,
  • They have an existing voice network with sufficient capacity for their needs,
  • They are focussed on promoting mobile broadband as their “hero” product, exploiting the market lead they have over the other UK mobile network operators,
  • They believe the voice service provided by circuit switched fall-back is good enough for the time being.


It is clear that over a period of time most if not all operators will deploy VoLTE and migrate customers to it. What is less clear is how rapidly they will do so.  Clearly MetroPCS have proceeded rapidly in the US whereas EE in the UK are proceeding cautiously and are quite happy at present with circuit switched fall-back. These two examples could be viewed as extremes of network operators’ positions. That being said, the author would not be surprised if, in light of their merger with T-Mobile, MetroPCS rollout less aggressively, and no doubt behind the scenes EE are working on their approach to VoLTE. In reality most operators are likely to fall somewhere in between.

For an operator considering VoLTE the benefits will fall into two categories:

  • Voice product enhancements potentially also including multi-media and RCS based services, and
  • Network rationalisation opportunities, whereby 3G equipment and spectrum can eventually be retired.

Operators in general prefer concrete business cases with clear cost benefits. The financial benefits associated with product enhancements are notoriously difficult to quantify whereas those associated with network rationalisation more straightforward. In an ideal world an operator would justify the cost of VoLTE deployment based on the network rationalisation savings and consider the benefits gained from product enhancements as “up-side”. For most operators, a business case of this nature is unlikely to show a return.

For substantial savings to come from 3G infrastructure rationalisation, network operators will need to shift a significant majority of customers to LTE and VoLTE capable handsets. This includes not only consumers but also business customers who may have large deployments of 3G (or even 2G) devices. Whilst the upgrade cycle for mobile phones is often quite rapid there will nonetheless be a sizeable rump of customers that will continue to have 3G phones for a considerable period. This inevitably will limit the speed at which operators can force a migration to LTE and undermine business cases based on network savings.

Clearly, given that one of the major barriers to migration to VoLTE is the entrenched base of customer handsets, operators should be planning now to ensure that any as many of the new handsets and SIMs deployed over the next few years are LTE and VoLTE capable. Even this though will just be the SmartPhone customer base. Whilst SmartPhone penetration is growing rapidly it is not clear if and when SmartPhones will entirely replace more basic phones and at what point a basic, low cost LTE/VoLTE phone might be manufactured as an alternative to todays basic 2G/3G phones.

Considering now the potential of product enhancements: VoLTE requires the introduction of an entirely new IMS voice core and major changes in the way the network is designed and operated. Business case aside, for any operator, this is no small undertaking. As has been indicated the benefits from product enhancement will be difficult to quantify and may be considered as a way to protect existing revenue from OTT competition rather than as a way to gain new revenues. Therefore, for most operators there is going to be a marked reluctance to move rapidly to VoLTE.

Most large operators are naturally conservative in nature and would view the case of moving to VoLTE as having questionable financial benefits and significant technical risk. That is not to say that sticking with circuit switched fall-back is not without risk. Indeed the voice product offered by mobile and fixed voice operators has changed very little over the last 15 years. Although handsets and the features they provide have been transformed the basic service provided by network operators remains the same. In the long run, this is not a sustainable position – operators will either need to improve their products or see customers move to OTT voice and messaging providers.

VoLTE actually offers an opportunity to operators to break from the legacy voice and messaging services and innovate. True, it is not yet clear what will be successful in the market, and to what extent it will generate new revenue. Nevertheless, operators need to start planning for IMS and VoLTE, it is to their advantage at the moment that they can start small, substantially reducing the risk for something they will inevitably have to do. In the view of this author, the prudent approach for most mobile operators with respect to VoLTE is the following:

  • Push SmartPhones and make sure they are LTE and VoLTE capable. Ensure that all SIMs are IMS compatible.
  • Build a small IMS core with associated systems and experiment – both technically and product-wise. Do not just limit service to mobile devices, but allow users to access their phone service from any device.
  • Get IMS based VoLTE services in to the hands of a number of trial customers who are enthusiastic to try different services.
  • Start making plans and building the key network and IT building blocks that will be required in the future for communication services. Which services will be successful is not necessarily clear, but the building blocks of future services are easier to define.

This is not to say that operators should proceed in undue haste, but they need to spend the time learning how to deploy voice over IP based VoLTE services, the service opportunities this presents and the challenges to their current systems and practices of offering something other than a basic voice service.

It may well pay operators to wait for VoLTE to be more mature, for IMS systems to have further developed and come down in cost, and for IT systems to have developed to support a rich fixed-mobile product set. What will be true, however, is that the knowledge they can gain now by experimenting and trialling will pay them back handsomely when the time does come to put together a robust business case for VoLTE, define system architectures, select vendors and move to deployment.

The message of this paper is that for most operators the case for aggressively implementing VoLTE is likely to appear weak. Nevertheless it is very important that VoLTE should not be ignored. It is for good reason that vendors and operators chose an IMS based approach for voice over LTE – they saw this as the best way to evolve voice service, to enable them to incrementally enhance their product. The alternative is for an operator to focus on delivering mobile broadband in the most efficient manner, at the lowest possible cost and accepting that voice and messaging revenues will eventually drift elsewhere.

The question of what strategy an operator should adopt for VoLTE forces them to consider the broader strategic question of the nature of their core business. Should they continue to remain a vertically integrated company offering all communications services or focus on operating a low-cost bit-pipe network that other service providers can overlay services upon. This is a hard question to answer; most operators will say they want to adopt the former position but then do nothing about it. A well-considered project to trial and implement (albeit at small scale) VoLTE actually offers them the opportunity to jump-start this process: understanding the challenges of launching more complex communications services, the impacts on network and IT systems, and the likely customer interest in such services.

Operators that ignore this risk falling between two stools:

  • Not being ready to launch VoLTE and other VoIP based communications services and seeing increasing revenue erosion to other operators or OTT service providers.
  • Not aggressively simplifying and cutting cost to make the network as cost effective as possible for basic bit-pipe based services and struggling to meet the price point set by other more efficient operators.

If past history is anything to go by, many operators will struggle to adapt rapidly enough to the changing market. Quite how this will play-out is yet to be seen – unlike other high technology industries network operators have the entrenched asset of their deployed network. Whilst this will protect them somewhat, networks are increasingly capital intensive and an operator will need strong revenues to continue to fund developments such as LTE, VoLTE and the next generation of LTE (LTE-A).

Source: http://pscomms.wordpress.com/2013/09/07/the-case-for-volte/

Envisioning a Software Defined IP Multimedia System (SD-IMS)

28 Aug


This post takes this idea a logical step forward and proposes a Software Defined IP Multimedia System (SD-IMS).

In today’s world of scorching technological pace, static configurations for IT infrastructure, network bandwidth and QOS, and fixed storage volumes will no longer be sufficient.

We are in the age of being able to define requirements dynamically through software. This is the new paradigm in today’s world. Hence we have Software Defined Compute, Software Defined Network, Software Defined Storage and also Software Defined Radio.

This post will demonstrate the need for architecting an IP Multimedia System that uses all the above methodologies to further enable CSPs & Operators to get better returns faster without the headaches of earlier static networks.

IP Multimedia Systems (IMS) is the architectural framework proposed by 3GPP body to establish and maintain multimedia sessions using an all IP network. IMS is a grand vision that is access network agnostic, uses an all IP backbone to begin, manage and release multimedia sessions.

The problem:

Any core network has the problem of dimensioning the various network elements. There is always a fear of either under dimensioning the network and causing failed calls or in over dimensioning resulting in wasted excess capacity.

The IMS was created to handle voice, data and video calls. In addition in the IMS, the SIP User Endpoints can negotiate the media parameters and either move up from voice to video or down from video to voice by adding different encoders.  This requires that the key parameters of the pipe be changed dynamically to handle different QOS, bandwidth requirements dynamically.

The solution

The approach suggested in this post to have a Software Defined IP Multimedia System (SD-IMS) as follows.

In other words the compute instances, network, storage and the frequency need to be managed through software based on the demand.

Software Defined Compute (SDC): The traffic in a Core network can be seasonal, bursty and bandwidth intensive. To be able to handle this changing demands it is necessary that the CSCF instances (P-CSCF, S-CSCF,I-CSCF etc) all scale up or down. This can be done through Software Defined Compute or the process of auto scaling the CSCF instances. The CSCF compute instances will be created or destroyed depending on the traffic traversing the switch.

Software Defined Network (SDN): The IMS envisages the ability to transport voice, data and video besides allowing for media sessions to be negotiated by the SIP user endpoints. Software Defined Networks (SDNs) allow the network resources (routers, switches, hubs) to be virtualized.

SDNs can be made to dynamically route traffic flows based on decisions in real time. The flow of data packets through the network can be controlled in a programmatic manner through the Flow controller using the Openflow protocol. This is very well suited to the IMS architecture. Hence the SDN can allocate flows based on bandwidth, QoS and type of traffic (voice, data or video).

Software Defined Storage (SDS): A key component in the Core Network is the need to be able charge customers. Call Detail Records (CDRs) are generated at various points of the call which are then aggregated and sent to the bill center to generate the customer bill.

Software Defined (SDS) abstracts storage resources and enables pooling, replication, and on-demand provisioning of storage resources. The ability to be able to pool storage resources and allocate based on need is extremely important for the large amounts of data that is generated in Core Networks

Software Defined Radio (SDR): This is another aspect that all Core Networks must adhere to. The advent of mobile broadband has resulted in a mobile data explosion portending a possible spectrum crunch. In order to use the available spectrum efficiently and avoid the spectrum exhaustion Software Define Radio (SDR) has been proposed. SDRs allows the radio stations to hop frequencies enabling the radio stations to use a frequency where this less contention (seeWe need to think differently about spectrum allocation … now).In the future LTE-Advanced or LTE with CS fallback will have to be designed with SDRs in place.


A Software Defined IMS makes eminent sense in the light of characteristics of a core network architecture.  Besides ‘cloudifying’ the network elements, the ability to programmatically control the CSCFs, network resources, storage and frequency, will be critical for the IMS. This is a novel idea but well worth a thought!


Source: http://gigadom.wordpress.com/2013/08/27/envisioning-a-software-defined-ip-multimedia-system-sd-ims/

World’s First End-to-End VoTD-LTE Call

23 Jun

ZTE Corporation completes the world’s first end-to-end voice-over TD-LTE (VoTD-LTE) call in partnership with China Mobile and Marvell Technology Group.

The VoTD-LTE call was conducted on China Mobile’s network in Guangzhou, which deploys ZTE’s TD-LTE technology and core IP Multimedia Subsystem (IMS) platform. The global industry’s first terminal-to-core network, end-to-end VoTD-LTE call was successfully carried out using 5-mode, 13-band smartphones powered by Marvell’s chipsets. A delegation of engineering experts from the Ministry of Industry and Information Technology personally experienced the VoTD-LTE service during their mission to Guangzhou to study 4G networks.

LTE Strategy 2013 – 2018 – All you need to know about LTE!

At present, there are three main methods to offer voice services to LTE users: CS Fall Back (CSFB), dual standby and VoLTE. The CSFB solution requires operators to hand off voice calls to slower 2G or 3G networks. The dual standby solution requires terminals to support the 2G/3G and 4G services simultaneously, with the 2G/3G network dedicated to provide voice services. VoLTE is an IMS-based voice service, with voice transmitted as IP data, and can be entirely supported by the LTE network, without 2G or 3G networks. Compared with the CSFB and dual standby solutions, the VoLTE solution offers superior voice quality and lower latency, with improved energy consumption for terminals, delivering a better user experience for 4G services.

Therefore, VoLTE is considered as the ultimate goal of evolution of LTE voice solution.

Compared with 2G and 3G networks, VoLTE features higher spectral efficiency in voice services, which enables operators to support a greater number of voice users for the same amount of spectrum. Although the voice data is transmitted through IP packet data, VoLTE offers better user experience than 2G and 3G voice service. Performance is also superior to over-the-top (OTT) services, as VoLTE features carrier-class QoS and HD codec technology. For operators, VoLTE enables the integration of data and voice services in a network, helping operators reduce complexity of Operation Support System(OSS), and achieve greater efficiency.

The VoTD-LTE breakthrough in Guangzhou will help accelerate the adoption of voice services on TD-LTE networks, and usher in the TD-LTE full-service era, aligning the TD-LTE industry with the FDD-LTE industry. As the development of mobile devices, TD-LTE wireless networks and IMS platforms become more mature, more VoLTE services will be deployed.

As of early 2013, ZTE had established TD-LTE field trials and commercial networks for 48 leading operators in 33 countries, including deployments in Europe, India, CIS, Asia-Pacific, and Southeast Asia. More at: 4G/LTE Network deployments worldwide

WebRTC: a double-edged sword for mobile operators!

28 Jan

The world is never going to look the same for the mobile industry. After three decades of an effectively closed service environment, everything but the bit pipe is now up for grabs. With the rise of Smartphones capable of running applications with access to internet-enabled services, a world of new and disruptive technologies has become available.  As HTML evolves towards HTML5, the line between browser and application gets blurred.

WebRTC has been heralded as a major disruptor to the mobile value chain, enabling real time voice and video (and data) services through a well-defined API. Web developers can nimbly create communication applications and plug them into existing web pages enhancing the user experience. These apps will run in the browser on any (low spec) mobile or computing device, independently of network or device user interface implementation, possibly augmented from the cloud.

A disruptor for the industry, clearly, but when mobile operators play to their strengths, WebRTC creates a unique value-add and therefore business opportunity. This comes from the signaling and session management layer being left open for the application developer. For this layer there are several choices that can be made, the most attractive for mobile operators is naturally SIP.

Offering a web-socket based SIP connection from WebRTC to the operator’s IMS infrastructure can add significant value to WebRTC based consumer and enterprise services, such as:

  • Rendezvous: Provide the current IP address for the addressed party (an essential detail!)
  • Facilitate multi-party (conference) connections
  • Provide interworking among telco domains (RCS, SMS, MMS) and XMPP
  • Ensure appropriate Quality of Service

The question now is not, can mobile operators risk not taking part – instead, given the opportunity and advantage, why would they not?

Source: http://theartofmessaging.com/2013/01/25/webrtc-a-double-edged-sword-for-mobile-operators/

PSTN subscriber to IMS subscriber call flow

15 Jan
IP Multimedia Subsystem is the new IP based signaling system for setting up multimedia sessions. We have already covered the call flow for an IMS subscriber calling another IMS subscriber. Here we will look at the call flow of a regular PSTN subscriber calling an IMS user.

PSTN to IMS call flow

PSTN subscriber to IMS subscriber call flow

This call flow covers the handling of a CS network originated call with ISUP. In the diagram the MGCF requests seizure of the IM CN subsystem side termination and CS network side bearer termination. When the MGCF receives an answer indication, it requests the IM-MGW to both-way through-connect the terminations. Originating and terminating end initiated call releases are also covered.

The following sequence is covered:

  1. ISUP IAM Handling and Initial IM-MGW and MGCF (Mn) Interactions
  2. Initial Handshake between MGCF and IMS CSCF Servers
  3. Mn Interactions for Codec selection
  4. ISUP ACM related interactions on Mn interface
  5. IMS Answer to ISUP ANM Handling
  6. Conversation Mode
  7. Call Release:
    • Calling PSTN Subscriber Initiated Call Release
    • Called Subsciber Initiates Call Release

Link: PSTN subscriber to IMS call flows

Focus on different aspects of the call flow

PSTN to IMS call is a very complex flow. The main sequence flow is supplemented with flows that focus on a particular aspect of the flow. A snapshot of one such diagrams is shown here:PSTN subscriber to IMS subscriber - Terminating S-CSCF interactions

Link: PSTN subscriber to IMS call flows

Source: http://blog.eventhelix.com/2013/01/13/pstn-subscriber-to-ims-subscriber-call-flow/

VoLTE billing architecture explained

25 Sep

Charging is an important aspect for VoLTE calls and a must for commercial deployment— but it literally pays to get it right. As the same session flows through PGW in LTE network and IMS core there is a danger that subscribers could be double charged for both data and voice for the same call.

IMS nodes provide the necessary means to solve the billing issues. During the SIP call establishment or message transaction IMS nodes generates an IMS correlation id for each and every event. IMS correlation ids are included in the CDR for each VoLTE calls. During dedicated bearer establishment for VoLTE calls PCSCF and PGW exchange ICID and GCID through PCRF Rx/Gx messages. Based upon VoLTE APN bearer establishment PGW can redirect all the VoLTE charging information to a different billing server to avoid double charge of voice and data sessions.

ICID and GCID in CDR help to correlate the call in the IMS and access network. IMS charging information is transferred to billing system through Diameter or ISC interfaces.

Charging can be based on

• Duration Based Charging

• Event based charging

• Volume based charging

Single call with different access legs can be easily correlated by billing servers since all the calls are anchored by IMS.

Source: http://lteconference.wordpress.com/2012/09/24/volte-billing-architecture-explained/ 24 Sep 2012 Written by dancoleinforma

%d bloggers like this: