Pages

Showing posts with label IMS. Show all posts
Showing posts with label IMS. Show all posts

Thursday, 13 February 2014

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


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




Monday, 20 January 2014

Different flavours of SRVCC (Single Radio Voice Call Continuity)



Single Radio Voice Call Continuity (SRVCC) has been quietly evolving with the different 3GPP releases. Here is a quick summary of these different flavors

In its simplest form, SRVCC comes into picture when an IMS based VoLTE call is handed over to the existing 2G/3G network as a normal CS call. SRVCC is particularly important when LTE is rolled out in small islands and the operator decided to provide VoLTE based call when in LTE. An alternative (used widely in practice) is to use CS Fallback (CSFB) as the voice option until LTE is rolled out in a wider area. The main problem with CSFB is that the data rates would drop to the 2G/3G rates when the UE falls back to the 2G/3G network during the voice call.



The book "LTE-Advanced: A Practical Systems Approach to Understanding 3GPP LTE Releases 10 and 11 Radio Access Technologies" by Sassan Ahmadi has some detailed information on SRVCC, the following is an edited version from the book:

SRVCC is built on the IMS centralized services (ICS) framework for delivering voice and messaging services to the users regardless of the type of network to which they are attached, and for maintaining service continuity for moving terminals.

To support GSM and UMTS, some modifications in the MSC server are required. When the E-UTRAN selects a target cell for SRVCC handover, it needs to indicate to the MME that this handover procedure requires SRVCC. Upon receiving the handover request, the MME triggers the SRVCC procedure with the MSC server. The MSC then initiates the session transfer procedure to IMS and coordinates it with the circuit-switched handover procedure to the target cell.

Handling of any non-voice packet-switched bearer is by the packet-switched bearer splitting function in the MME. The handover of non-voice packet-switched bearers, if performed, is according to a regular inter-RAT packet-switched handover procedure.

When SRVCC is enacted, the downlink flow of voice packets is switched toward the target circuit-switched network. The call is moved from the packet-switched to the circuit-switched domain, and the UE switches from VoIP to circuit-switched voice.

3GPP Rel-10 architecture has been recommended by GSMA for SRVCC because it reduces both voice interruption time during handover and the dropped call rate compared to earlier configurations. The network controls and moves the UE from E-UTRAN to UTRAN/GERAN as the user moves out of the LTE network coverage area. The SRVCC handover mechanism is entirely network-controlled and calls remain under the control of the IMS core network, which maintains access to subscribed services implemented in the IMS service engine throughout the handover process. 3GPP Rel-10 configuration includes all components needed to manage the time-critical signaling between the user’s device and the network, and between network elements within the serving network, including visited networks during roaming. As a result, signaling follows the shortest possible path and is as robust as possible, minimizing voice interruption time caused by switching from the packet-switched core network to the circuit-switched core network, whether the UE is in its home network or roaming. With the industry aligned around the 3GPP standard and GSMA recommendations, SRVCC-enabled user devices and networks will be interoperable, ensuring that solutions work in many scenarios of interest.

Along with the introduction of the LTE radio access network, 3GPP also standardized SRVCC in Rel-8 specifications to provide seamless service continuity when a UE performs a handover from the E-UTRAN to UTRAN/GERAN. With SRVCC, calls are anchored in the IMS network while the UE is capable of transmitting/ receiving on only one of those access networks at a given time, where a call anchored in the IMS core can continue in UMTS/GSM networks and outside of the LTE coverage area. Since its introduction in Rel-8, the SRVCC has evolved with each new release, a brief summary of SRVCC capability and enhancements are noted below

3GPP Rel-8: Introduces SRVCC for voice calls that are anchored in the IMS core network from E-UTRAN to CDMA2000 and from E-UTRAN/UTRAN (HSPA) to UTRAN/GERAN circuit-switched. To support this functionality, 3GPP introduced new protocol interface and procedures between MME and MSC for SRVCC from E-UTRAN to UTRAN/GERAN, between SGSN and MSC for SRVCC from UTRAN (HSPA) to UTRAN/GERAN, and between the MME and a 3GPP2-defined interworking function for SRVCC from E-UTRAN to CDMA 2000.

3GPP Rel-9: Introduces the SRVCC support for emergency calls that are anchored in the IMS core network. IMS emergency calls, placed via LTE access, need to continue when SRVCC handover occurs from the LTE network to GSM/UMTS/CDMA2000 networks. This evolution resolves a key regulatory exception. This enhancement supports IMS emergency call continuity from E-UTRAN to CDMA2000 and from E-UTRAN/UTRAN (HSPA) to UTRAN/ GERAN circuit-switched network. Functional and interface evolution of EPS entities were needed to support IMS emergency calls with SRVCC.

3GPP Rel-10: Introduces procedures of enhanced SRVCC including support of mid-call feature during SRVCC handover (eSRVCC); support of SRVCC packet-switched to circuit-switched transfer of a call in alerting phase (aSRVCC); MSC server-assisted mid-call feature enables packet-switched/ circuit-switched access transfer for the UEs not using IMS centralized service capabilities, while preserving the provision of mid-call services (inactive sessions or sessions using the conference service). The SRVCC in alerting phase feature adds the ability to perform access transfer of media of an instant message session in packet-switched to circuit-switched direction in alerting phase for access transfers.

3GPP Rel-11: Introduces two new capabilities: single radio video call continuity for 3G-circuit-switched network (vSRVCC); and SRVCC from UTRAN/GERAN to E-UTRAN/HSPA (rSRVCC). The vSRVCC feature provides support of video call handover from E-UTRAN to UTRAN-circuitswitched network for service continuity when the video call is anchored in IMS and the UE is capable of transmitting/receiving on only one of those access networks at a given time. Service continuity from UTRAN/GERAN circuitswitched access to E-UTRAN/HSPA was not specified in 3GPP Rel-8/9/10. To overcome this drawback, 3GPP Rel-11 provided support of voice call continuity from UTRAN/GERAN to E-UTRAN/HSPA. To enable video call transfer from E-UTRAN to UTRAN-circuit-switched network, IMS/EPC is evolved to pass relevant information to the EPC side and S5/S11/Sv/Gx/Gxx interfaces are enhanced for video bearer-related information transfer. To support SRVCC from GERAN to E-UTRAN/HSPA, GERAN specifications are evolved to enable a mobile station and base station sub-system to support seamless service continuity when a mobile station hands over from GERAN circuit-switched access to EUTRAN/ HSPA for a voice call. To support SRVCC from UTRAN to EUTRAN/ HSPA, UTRAN specifications are evolved to enable the RNC to perform rSRVCC handover and to provide relative UE capability information to the RNC.

NTT Docomo has a presentation on SRVCC and eSRVCC which is embedded below:



Thursday, 16 January 2014

3GPP Rel-12 and Future Security Work


Here is the 3GPP presentation from the 9th ETSI Security workshop. Quite a few bits on IMS and IMS Services and also good to see new Authentication algorithm TUAK as an alternative to the widely used Milenage algorithm.



Sunday, 5 May 2013

Thursday, 14 March 2013

What is WebRTC and where does it fit with LTE and IMS

This simple video from MWC should give an idea on what WebRTC is and can do:


So what exactly WebRTC is in technical terms. Here is a recent presentation from WebRTC Conference and Expo



And here is another presentation that explains where it fits in with the LTE Architecture.



Dean Bubley from Disruptive Analysis has writted extensively on this topic and his recent post "Is the telephony "threat" from VoIP & WebRTC about competition or contextualisation?" is an interesting read.

Iain Sharp from Netovate recently pointed out that 3GPP have 'nearly' approved a work item for WebRTC access to IMS.

It would be interesting to see how operators will view WebRTC. As an opportunity or as a threat. Please feel free to air your opinions via comments.

Thursday, 20 December 2012

IMS Whitepapers from Spirent



Couple of old but interesting whitepapers from Spirent available, in case you are interesting in IMS. Available to download from here (registration required)

Related blog posts:



Sunday, 26 August 2012

Voice-Over-LTE (VoLTE) Signalling

MetroPCS has recently launched rolled out VoLTE in USA using LG connect phones. More operators would be rolling it out soon so here is example of Signaling in VoLTE.




To read in detail, please see the article from NTT Docomo technical journal here.

Thursday, 22 March 2012

UICC and ISIM (IMS SIM)



I have mentioned before that UICC is the physical card and 2G SIM/USIM/ISIM are applications on the UICC card. The IMS SIM holds data provided by the IMS Operator, generally the same operator that would provide USIM services that would allow to camp on the 3G or LTE network.

Private User Identity: This identifies the user uniquely with the IMS operator and is used when the user registers with the IMS network. This is used by the operator to check the subscription and which services the user can avail of.

Public User Identity: A user can have multiple public identities that can be used for different services. To avail a particular service, user has to register with the particular public identity that has been allowed for that service.

Security Keys: Security keys are used for authentication to the IMS Network.

Home Network Domain Name: This is the name of the entry point that the user uses to register. This makes sure that a users request is sent to the Home Network.

Access Rule Reference: This is used to store information about which personal identification number needs verification for accessing a particular application

Address of P-CSCF: If it is not possible do dynamically find the Proxy-Call Session Control Function then this address is helpful

Administrative Data: Some of this could be operator specific proprietary information

Wednesday, 14 December 2011

ETSI INT IMS/EPC Interoperability Standardisation: Motivation, Roadmap & First Results

INT = IMS Network Testing. ETSI INT website here. More details below the presentation:

This was presented by Giulio Maggiore, Telecom Italia, ETSI TC INT Chairman in the 2nd FOKUS FUSECO Forum 2011, Berlin 17-18 Nov. 2011

From the ETSI leaflet (note that this is quite old information but still on the ETSI website here):

IMS interoperability is a key issue for boosting IMS (IP Multimedia Subsystem) roll-out and more specifically network interconnection between operators. Only through thorough testing in practical scenarios can operators ensure operational excellence in a multi-vendor and multi-provider environment.


IMS comprises a set of specifications designed to enable network operators to implement IP-based networks that can carry services for both fixed and mobile customers simultaneously.


IMS was developed originally in the mobile world (specifically in the specifications created by the 3rd Generation Partnership Project, 3GPP), and was adopted for fixed networks by ETSI’s TISPAN Technical Committee (Telecoms & Internet Converged Services & Protocols for Advanced Networks).


However this promise of advanced communications over the next generation network will only be delivered if those same networks can interconnect.


ETSI’s Technical Committee INT: IMS Network Testing


ETSI is bridging the existing gap between 3GPP IMS Core Network standards and the initial industry IMS implementations through the organization of IMS interoperability events in connection with ETSI’s Centre for Testing & Interoperability (CTI) and Plugtests™ interoperability testing service.


Our Technical Committee for IMS Network Testing (TC INT) is actively establishing close contact with a number of industry fora and organizations dealing with IMS interoperability, including 3GPP, GSMA, MSF (Multi Service Forum), IMS Forum and the ITU-T. TC INT develops IMS test specification according to conformance, network integration and interoperability testing methodologies. Other ongoing work includes development of tests for Supplementary Services based on regulatory requirements and IMS tests with legacy networks (e.g. SIP-I).


ETSI has already held two IMS interoperability events. The first examined interconnection aspects of 3GPP IMS Release 6, including such issues as basic call on the Mw interface. The second event had a wider scope that included the testing of 3GPP IMS Release 7 interworking, roaming, border control, and integration of application servers executing selected Multimedia Telephony supplementary services.


Future ETSI activities and events will go even deeper towards bridging 3GPP IMS standards and industry implementations. These will include the organization of further IMS interoperability events designed to boost the roll-out and take-off of IMS services and operators’ network interconnections.

Wednesday, 10 August 2011

Self-Evolving Networks (SEN): Next step of SON

In a post last year, I listed the 3GPP features planned for the Self-Organising networks. Self-optimisation has been a part of the SON. It is becoming more of a common practice to refer to SON as Self-Optimising networks. A recent 4G Americas whitepaper was titled "Benefits of self-optimizing networks in LTE".

The next phase in the evolution of the Self-Configuring, Self-organizing and Self-optimizing network are the Self-Evolving Networks (aka. SEN) that will combine the Organizing and Optimizing features with the Self-testing and Self-Healing features. Self-testing and Self-healing have been recommended as subtasks of SON in the NGMN white paper. Self-testing and self-healing means that a system detects itself problems and mitigates or solves them avoiding user impact and significantly reducing maintenance costs.

We may still be a long way away from achieving this SEN as there are quite a few items being still standardised in 3GPP. Some of the standardised items have not yet been fully implemented and tested as well. Some of this new features that will help are listed as follows:

Automatic Radio Network Configuration Data Preparation (Rel-9)

When radio Network Elements (e.g. cells and/or eNBs) are inserted into an operational radio network, some network configuration parameters cannot be set before-hand because they have interdependencies with the configuration of operational NEs. "Dynamic Radio Network Configuration Data Preparation" comprises the generation and distribution of such interdependent parameters to the newly inserted network element and optionally already operational NEs.

This functionality allows fully automatic establishment of an eNB into a network. Otherwise an operator needs to set these configurations manually. Without this functionality self-configuration cannot be considered not fully as "self".


SON Self-healing management (Rel-10)

The target of Self-Healing (SH) is to recover from or mitigate errors in the network with a minimum of manual intervention from the operator.

Self-healing functionality will monitor and analyse relevant data like fault management data, alarms, notifications, and self-test results etc. and will automatically trigger or perform corrective actions on the affected network element(s) when necessary. This will significantly reduce manual interventions and replace them with automatically triggered re-s, re-configurations, or software reloads/upgrades thereby helping to reduce operating expense.


LTE Self Optimizing Networks (SON) enhancements (Rel-10)

This WI continues work started in Rel-9. Some cases that were considered in the initial phases of SON development are listed in the TR 36.902. From this list, almost all use cases are already specified. Capacity and Coverage Optimization (CCO) was already nominally part of the Rel-9 WI, but could not be completed due to amount of work related to other use cases. Energy Savings are a very important topic, especially for operators, as solutions derived for this use case can significantly limit their expenses. According to TR 36.902 this solution should concern switching off cells or whole base stations. This may require additional standardised methods, once there is need identified for.

Basic functionality of Mobility Load Balancing (MLB) and Mobility Robustness Optimization (MRO), also listed in TR 36.902, were defined in Rel-9. However, successful roll-out of the LTE network requires analysing possible enhancements to the Rel-9 solutions for MLB and MRO. In particular, enhancements that address inter-RAT scenarios and inter-RAT information exchange must be considered. These enhancements should be addressed in Rel-10. There may also be other use cases for LTE for which SON functionality would bring optimizations. The upcoming LTE-A brings about also new challenges that can be addressed by SON. However, since not all features are clearly defined yet, it is difficult to work on SON algorithms for them. It is therefore proposed to assign lower priority to the features specific for LTE-A.


UTRAN Self-Organizing Networks (SON) management (Rel-11)

For LTE, SON (Self-Organizing Networks) concept and many features have been discussed and standardised.

The SON target is to maintain network quality and performance with minimum manual intervention from the operator. Introducing SON functions into the UTRAN legacy is also very important for operators to minimize OPEX.

Automatic Neighbour Relation (ANR) function, specified in the LTE context, automates the discovery of neighbour relations. ANR can help the operators to avoid the burden of manual neighbour cell relations management.

Self-optimization functionalities will monitor and analyze performance measurements, notifications, and self-test results and will automatically trigger re-configuration actions on the affected network node(s) when necessary.

This will significantly reduce manual interventions and replace them with automatically triggered re-optimizations or re-configurations thereby helping to reduce operating expenses.

Minimization of Drive Tests (MDT) for E-UTRAN and UTRAN is an important topic in 3GPP Rel-10.

With the help of standardized UTRAN MDT solutions, Capacity and Coverage Optimization (CCO) for UTRAN should also be considered in UTRAN SON activities.


Study on IMS Evolution (Rel-11)

IMS network service availability largely relies on the reliability of network entity. If some critical network elements (e.g. S-CSCF, HSS) go out of service, service availability will be severely impacted. Moreover network elements are not fully utilized because network load is not usually well distributed, e.g. some nodes are often overloaded due to sudden traffic explosion, while others are under loaded to some extent. Though there’re some element level approaches to solve these problems, such as the ongoing work in CT4, the system level solution should be studied, for example, the method to distribute load between network elements in different regions especially when some disaster happens, such as earthquake.

The network expansion requires a great deal of manual configurations, and the network maintenance and upgrade are usually time-consuming and also costly for operators. Introducing self-organization features will improve the network intelligence and reduce the efforts of manual configuration. For example, upon discovering the entry point of the network, new nodes can join the network and auto-configure themselves without manual intervention. And if any node fails, other nodes will take over the traffic through the failed node timely and automatically.


The above mentioned features are just few ways in which we will achieve a truly zero-operational 4G network.

Monday, 6 June 2011

Billing based on QoS and QoE

With Spectrum coming at a price the operators are keen to make as much money as possible out of the data packages being provided to the consumers. The operators want to stop users using over the top (OTT) services like Skype thereby losing potential revenue. They also want the users to stop using services that are offered by the operator thereby maximising their revenue.

A valid argument put forward by the operators is that 90% of the bandwidth is used by just 10% of the users. This gives them the reason to look at the packets and restrict the rogue users.

As a result they are now turning to deep packet inspection (DPI) to make sure that the users are not using the services they are being restricted to use. AllOt is one such company offering this service.

The following presentation is from the LTE World Summit:
They also have some interesting Videos on the net that have been embedded below. They give a good idea on the services being offered to the operators.

Smart Pipes
View more videos from alenaor
Finally, a term QoS and QoE always causes confusion. Here is a simple explanation via Dan Warren on twitter:

QoS = call gets established and I can hear what is being said, everything else is QoE

Tuesday, 10 May 2011

Advanced IP Interconnection of Services (IPXS) in 3GPP Rel-11

The following is edited from the 3GPP documents:

IP is being introduced in both fixed and mobile networks as a more cost-effective alternative to circuit switched technology in the legacy PSTN/PLMN, as well as the underpinning transport for delivering IMS based multi-media services.

In order to ensure carrier grade end to end performance, appropriate interconnect solutions are required to support communications between users connected to different networks. There are currently a number of initiatives underway outside 3GPP addressing IP Interconnection of services scenarios and commercial models to achieve this; for example, the GSM Association has developed the IPX (IP Packet Exchange). Also, ETSI has recently defined requirements and use case scenarios for IP Interconnection of services. These initiatives require the use of appropriate technical solutions and corresponding technical standards, some of which are already available and others which will require development in 3GPP.

Moreover, new models of interconnection may emerge in the market where Network Operators expose network capabilities to 3rd party Application Providers including user plane connectivity for the media related to the service.

The main objective of IPXS is thus:
To specify the technical requirements for carrier grade inter-operator IP Interconnection of Services for the support of Multimedia services provided by IMS and for legacy voice PTSN/PLMN services transported over IP infrastructure (e.g. VoIP).

These technical requirements should cover the new interconnect models developed by GSMA (i.e. the IPX interconnect model) and take into account interconnect models between national operators (including transit functionality) and peering based business trunking.

Any new requirements identified should not overlap with requirements already defined by other bodies (e.g. GSMA, ETSI TISPAN). Specifically the work will cover:
Service level aspects for direct IP inter-connection between Operators, service level aspects for national transit IP interconnect and service level aspects for next generation corporate network IP interconnect (peer-to-peer business trunking).
Service layer aspects for interconnection of voice services (e.g. toll-free, premium rate and emergency calls).
Service level aspects for IP Interconnection (service control and user plane aspects) between Operators and 3rd party Application Providers.

To ensure that requirements are identified for the Stage 2 & 3 work to identify relevant existing specifications, initiate enhancements and the development of the new specifications as necessary.

The following is a related presentation on Release-8 II-NNI with an introduction to Rel-9 and Rel-10 features.

The 3GPP references can be seen from the presentation above.

European Commission conducted a study on this topic back in 2008 and produced a lengthy report on this. Since the report is 187 pages long, you can also read the executive summary to learn about the direction in technical, economic and public policy.

Monday, 25 April 2011

Advanced Telephony Services for LTE

With LTE World Summit just round the corner, I was going through the last year's presentations and realised that we didn't talk of this one before.

The concept for the advanced telephony services has been around since the early days of IMS and this was one of the ways IMS was sold. Unfortunately IMS didn't take off as planned and only now with the standardisation of VoLTE, there is a possibility of the advanced services becoming a reality.

The following presentation summarises some of these advanced telephony services concepts.

Sunday, 24 April 2011

ANDSF: Access Network Discovery and Selection Function

The following is a recent news from Mobile Europe:

WeFi has launched a product that is intended to enable mobile operators to route traffic over the mobile macro network or a WiFi hotspot without the consumer having to manage their own settings.

The product, from WeFi, enables operators to set network management policies using a 3GPP-defined function for the Evolved Packet Core called ANDSF – Access Network Discovery and Selection Function. WeFi said that its WeANDSF is the first standards-compliant product on the market, although it said that as the standards are not yet fully finalised, the product is more accurately described as a pre-standards compliant product.

ANDSF, specified in 3GPP standards 23.402 and 24.312, is intended to allow mobile operators to set network management policies and priorities, and to control where, when and under what circumstances a subscriber’s device connects to which wireless network, be it cellular or Wi-Fi.

Operators may choose to route traffic according to application type to reduce network load, or to provide the best available customer experience. Although operators are increasingly looking at using WiFi for offload in congested areas, one problem for them is that once traffic is routed over WiFi control is lost over any traffic policies they have set for that user. ANDSF keeps a link to the operator's core network, allowing the operator visibility of traffic even when it is routed over WiFi.

WeFi said that the product is already in trials with several mobile operators. As handset manufacturers are yet to include the device element of ANDSF, WeFi is also providing a device client, although it sees that role diminishing as handset vendors deliver ANDSF-compliant handsets, “when these become available in the market by 2012”.

The following presentation is by Fraunhofer Fokus on ANDSF:

For more details see:

3GPP TS 23.402: Architecture enhancements for non-3GPP accesses

3GPP TS 24.312: Access Network Discovery and Selection Function (ANDSF) Management Object (MO)

Tuesday, 19 April 2011

Unstructured Supplementary Service Data (USSD) simulation service in IMS (USSI)

I hope we all know USSD. If not then hopefully my old blog post will help remind you of USSD. Apparently USSD is as popular as it was nearly a decade back since it is supported by 100% of the phones. As a result 3GPP have made sure that a USSD like service is available in LTE/SAE since USSD was designed for a CS domain and in SAE we have only the PS domain.


Picture Source: Aayush Weblog

The following is from the 3GPP document:

Today mobile initiated unstructured SS data in MMI mode are widely used to interact with proprietary home-network provided services, e.g. to activate or deactivate certain features or to interrogate some parameter settings.

The user dials a certain feature code, e.g. in the format “*# ”, this code is forwarded to the home network and answered with a text string providing the requested information. Unlike common SMS the string is displayed immediately and not stored on the UE.

A typical use case is the interrogation of the account balance in a prepaid service. The prepaid user e.g. dials "*101#", the message is forwarded to the HPLMN and further to the IN system where the account balance is checked and finally the current value is transferred to the user in a short answer string, e.g. "Balance: € 35,40". Another use case is controlling the active UE for incoming calls and messages in case of a hunting service / multi SIM service.

From a network perspective the functionality is as follows:
1. The user sends the request
2. USSD is sent as MAP message to the HPLMN
3. USSD is forwarded to a Service Node (SN) [non-standardized functionality]
4. USSD is answered
5. answer
6. answer

The mentioned functionality is not available in the EPS. So e.g. a business customer who is subscribed to a certain multi SIM service will use his UEs via CS and EPS/IMS. Dependent on the access he would have to use different mechanisms for controlling the active UE.

This problem can be avoided when introducing completely new services. Then mechanisms can be used that are available via all access networks, e.g. web interfaces via GPRS or EPS. However we are talking about existing services with a broad customer base that is accustomed to use USSD codes as they are fast and simple to use.

As USSD is widely used in CS domain, operators would benefit from re-using the already deployed servers also when the user accesses services that make use of USSD over IMS.

It is therefore desirable to create in 3GPP a service which provides the same capabilities for the user, like the well known "GSM Mobile User Initiated USSD" feature.

For the user, it is important that the user experience is transparent (I.e. the look and feel of the service is independent of the transport mechanism used to convey the USSD payload to the network).


Possible solutions

There are several possibilities to solve this issue. One would be to re-introduce USSD in EPS. This is not the intention as it creates too much overhead. The idea is to specify a light weight solution which provides the same look and feel for the user but uses existing network mechanisms, i.e. only to simulate the USSD service.

One variant could be that the UE when being attached via the EPS to the IMS encapsulates the USSD codes in IP messages and forwards them to the network. This could happen either via the Ut interface as XCAP data using http or in a SIP message.

It should be noted that there are also user initiated MMI mode USSDs for VPLMN use. The differentiation, if USSD are intended for HPLMN or VPLMN use, is done via the range of the feature code. If USSD for VPLMN use were to be supported / simulated this may prevent certain solutions (e.g. using the Ut) and have some architectural impact (considering all possible roaming scenarios for the IMS).

Proposal

To specify an easy solution having no architectural impact. Only the simulation of mobile initiated USSD – MMI mode for HPLMN use should be supported. The functionality should be available for Multimedia Telephony, i.e. it can be implemented with the MMTel UE client and USSD messages are sent to and answered by the MMTel AS.


Though there isn't much details on this feature available, Ayush's weblog has some more details on this feature here.