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

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.

Monday 18 April 2011

Multimedia Telephony (MMTel) in 3GPP Rel-7

Came across MMTel multiple times in the last few months so decided to dig a bit more in detail.

The following from wikipedia:

The 3GPP/NGN IMS Multimedia Telephony Service (MMTel) is a global standard based on the IP Multimedia Subsystem (IMS), offering converged, fixed and mobile real-time multimedia communication using the media capabilities such as voice, real-time video, text, file transfer and sharing of pictures, audio and video clips. With MMTel, users have the capability to add and drop media during a session. You can start with chat, add voice (for instance Mobile VoIP), add another caller, add video, share media and transfer files, and drop any of these without losing or having to end the session.

The MMTel standard is a joint project between the 3GPP and ETSI/TISPAN standardization bodies. The MMTel standard is today the only global standard that defines an evolved telephony service that enables real-time multimedia communication with the characteristics of a telephony service over both fixed broadband, fixed narrowband and mobile access types. MMTel also provides a standardized Network-to-Network Interface (NNI). This allow operators to interconnect their networks which in turn enables users belonging to different operators to communicate with each other, using the full set of media capabilities and supplementary services defined within the MMTel service definition.

One of the main differences with the MMTel standard is that, in contrast of legacy circuit switched telephony services, IP transport is used over the mobile access. This means that the mobile access technologies that are in main focus for MMTel are access types such as High Speed Packet Access (HSPA), 3GPP Long Term Evolution (LTE) and EDGE Evolution that all are developed with efficient IP transport in mind.

MMTel allows a single SIP session to control virtually all MMTel supplementary services and MMTel media. All available media components can easily be accessed or activated within the session. Employing a single session for all media parts means that no additional sessions need to be set up to activate video, to add new users, or to start transferring a file. Even though it is possible to manage single-session user scenarios with several sessions – for instance, using a circuit-switched voice service that is complemented with a packet-switched video session, a messaging service or both – there are some concrete benefits to MMTel’s single-session approach. A single SIP session in an all-IP environment benefits conferencing; in particular, lip synchronization, which is quite complex when the voice part is carried over a circuit-switched service and the video part is carried over a packet-switched service. In fixed-mobile convergence scenarios, the single-session approach enables all media parts of the multimedia communication solution to interoperate.

An interesting presentation on MMTel is embedded below.

If you are still hungry for more on this topic then Ericsson's old presentation on MMTel is available on Slideshare here.

Tuesday 1 March 2011

Rich Communication Suite (RCS)

I have heard quite a bit about Rich Communication Suite (RCS) recently. It was supposed to start become popular by 2011 but Infonetics puts it as a little too late to become mass market anytime soon in a recent report. The new report forecasts that there would be around 6.8 million RCS subscribers worldwide by end of 2012.

Dean Bubley from Disruptive Wireless released a report some months back saying that RCS is a bit too late and inflexible and the built-in assumptions have problems which wont make it a mass market technology.

Anyway, I decided to explore the technology a bit to understand it better. Before we start digging into this, the following Youtube Video gives a good overview of what RCS is supposed to be:



The following article gives a good summary of RCS as of now:

The GSMA is welcoming a new version of Rich Communication Suite (RCS) that will enable mobile phone customers to use instant messaging (IM), live video sharing and file transfer across any device on any network operator. Deutsche Telekom, Orange, Telecom Italia, Telefonica and Vodafone intend to commercially launch RCS across several European markets from late 2011, and additional operators are expected to launch later in 2012.

Once adopted, Rich Communication Suite – e* (RCS-e) will enable customers to use these enhanced communication services across mobile networks in a simpler and more intuitive way. It is based on a specification put forward by Bharti, Deutsche Telekom, Orange, Orascom Telecom, SK Telecom, Telecom Italia, Telefonica, Telenor and Vodafone which aims to lower the hurdle and speed up the market introduction and adoption of these services.

With RCS-e, customers will be able to use IM, share live video and share files such as photos simultaneously during calls, regardless of the network or device used. RCS-e will enable users to communicate in a very natural way, much like with GSM voice and text today, and will also offer the simplicity and security customers expect from mobile operator services.

As customers open their address book, they will be able to see which communication services are available to them. They can then choose their preferred communications option. For example, a customer would see if their contact is in an area with 3G coverage and is able to receive video.

The participating operators will work with handset suppliers to ensure the service is integrated into the address books of devices, so that customers will not have to download any additional software or technically configure their handsets in order to benefit from the enhanced experience.

“Mobile operators are committed to giving their customers greater choice in the way they communicate with one and other,” said Rob Conway, CEO and Member of the Board of the GSMA. “We welcome the pragmatic approach taken by these operators to accelerate the commercialisation of RCS and simplify the experience for mobile customers and we will work to adopt this specification within the RCS initiative.”

The RCS specification is designed to be interoperable between all operators and devices, giving customers greater choice in how they communicate. The new RCS-e is the result of extensive trials and is a subset of the current RCS 2.0 standard with enhancements. It is focused on extending the principles of voice and SMS calls to deliver an advanced set of interoperable data-centric communications services.

* RCS-e is a new enhanced version of the RCS specification which is based on the use across networks of IP Multimedia Subsystem (IMS) technology, an architectural framework for delivering Internet Protocol (IP) multimedia services.

The following presentation provides a bit more detail

Eduardo Martin's blog provides some more insight into the RCS Releases:

RCS has 3 releases, each upgrades the previous one. I will focus on SIP Presence only, but RCS touches more than SIP Presence, it also works other services such as IM.

RCS Release 1 evolves around the concept of the Enhanced Address Book (EAB), an evolution of the usual address book. In short the address book is decorated with enriched information, coming from different services. This plays nicely with today's wishes for cloud stored information, unified social networks status updates, contact content such as portrait icons. I'm not going into technical details, but I for sure am someone who is aware of the design issues around SIP Presence, its hard time scaling due to huge traffic, the dozens of ugly workarounds to make it work, and RCS is a nice step forward into the right direction, there are simple decisions that deeply simplify the network design, making it more like "old" presence networks, which simply work. One remark, it takes quite an effort to define this endorsing IMS and OMA, 27 pages of functional description, plus 39 of technical realization, it should be a lesson for everyone in these standard bodies when defining more extensions or new versions.

The RCS Release 2 effort focuses on enabling access to rich communication services from a wider range of devices. In short it tells that the user has multiple devices, for instance a mobile phone and a PC, possibly concurring for services, and adapts Release 1 for that. It also introduces the Network Address Book, which is just the realization that the EAB needs to be in the network and sync the multiple user devices.

The RCS Release 3 mostly consolidates Release 2 features, and adds some minor enhancements, such as preparing the network for different usages of it, for instance users with devices, which are not connected to mobile network, instead only have broadband connections. In my humble opinion a very important and positive decision, it's about time to consider these scenarios and find out new opportunities. It is weird to say this, but the fact that the industry finally acknowledges that content sharing between two users may happen off the voice/video session is a victory, welcome to the world not session centric.

The RCS specs are available here.

Thursday 20 January 2011

eMPS: Enhanced Multimedia Priority Service in Release-10 and beyond


The response to emergency situations (e.g., floods, hurricanes, earthquakes, terrorist attacks) depends on the communication capabilities of public networks. In most cases, emergency responders use private radio systems to aid in the logistics of providing critically needed restoration services. However, certain government and emergency management officials and other authorised users have to rely on public network services when the communication capability of the serving network may be impaired, for example due to congestion or partial network infrastructure outages, perhaps due to a direct or indirect result of the emergency situation.

Multimedia Priority Service, supported by the 3GPP system set of services and features, is one element creating the ability to deliver calls or complete sessions of a high priority nature from mobile to mobile networks, mobile to fixed networks, and fixed to mobile networks.

Requirements for the Multimedia Priority Service (MPS) have been specified in TS 22.153 for the 3GPP Release-9

The intention of MPS is to enable National Security/Emergency Preparedness (NS/EP) users (herein called Service Users) to make priority calls/sessions using the public networks during network congestion conditions. Service Users are the government-authorized personnel, emergency management officials and/or other authorized users. Effective disaster response and management rely on the Service User’s ability to communicate during congestion conditions. Service Users are expected to receive priority treatment, in support of mission critical multimedia communications.

LTE/EPC Release 9 supports IMS-based voice call origination by a Service User and voice call termination to a Service User with priority. However, mechanisms for completing a call with priority do not exist for call delivery to a regular user for a priority call originated by a Service User. MPS enhancements are needed to support priority treatment for Release 10 and beyond for call termination and for the support of packet data and multimedia services.

MPS will provide broadband IP-based multimedia services (IMS-based and non-IMS-based) over wireless networks in support of voice, video, and data services. Network support for MPS will require end-to-end priority treatment in call/session origination/termination including the Non Access Stratum (NAS) and Access Stratum (AS) signaling establishment procedures at originating/terminating network side as well as resource allocation in the core and radio networks for bearers. The MPS will also require end-to-end priority treatment in case of roaming if supported by the visiting network and if the roaming user is authorized to receive priority service.

MPS requirement is already achieved in the 3G circuit-switched network. Therefore, if the network supports CS Fallback, it is necessary to provide at least the same capability as 3G circuit switched-network in order not to degrade the level of voice service. In CS Fallback, UE initiates the fallback procedures over the LTE as specified in TS 23.272 when UE decides to use the CS voice service for mobile originating and mobile terminating calls. To achieve priority handling of CS Fallback, NAS and AS signaling establishment procedures, common for both IP-based multimedia services and CS Fallback, shall be treated in a prioritized way.

In Release-10, for LTE/EPC, the following mechanisms will be specified.
  • Mechanisms to allocate resources for signaling and media with priority based on subscribed priority or based on priority indicated by service signaling.
  • For a terminating IMS session over LTE, a mechanism for the network to detect priority of the session and treat it with priority.
In Release-10, for CS Fallback, the following mechanism will be specified:
  • A mechanism to properly handle the priority terminating voice call and enable the target UE to establish the AS and NAS connection to fall-back to the GERAN/UTRAN/1xRTT.
For more information, see:

3GPP TR 23.854: Enhancements for Multimedia Priority Service (Release 10)

3GPP TS 22.153: Multimedia priority service (Release 10)

Saturday 4 December 2010

Role of ENUM in NGN Interconnect

I have blogged about ENUM here and here and its been quite a while. In these last couple of years ENUM has evolved a bit and now GSMA has its own Number translation service called Pathfinder.

The following is a presentation by GSMA in the recently concluded The 3GPP release 8 IMS Implementation, Deployment & Testing workshop.

Friday 3 December 2010

Presentation: IMS for 3G Voice Services and Migration Strategies

Very interesting presentation from NTT DoCoMo in the IMS workshop I blogged about yesterday. It shows their strategy to move from legacy core network to an All IP Network (AIPN).


Thursday 2 December 2010

The 3GPP release 8 IMS Implementation, Deployment & Testing workshop

The 3GPP release 8 IMS Implementation, Deployment & Testing workshop took place in Sophia Antipolis on 24-25 November 2010.

The event was attended by 70 delegates actively participating to the discussions.
Presenting companies included: Tel : A1 Telekom Austria, Alcatel Lucent, Codenomicon, Conformiq, Eircom, Elvior, ETSI, France Telecom, GSMA, Huawei, Huawei, Mobitel, NTT DoCoMo, SFR, Telecom Italia, TestingTech, TU Berlin, Wind, Wipro, ZTE.

Here are the highlights from the ETSI document:

Goals and Outcome for this workshop

Share exprience from IMS implementation
Highlight areas for further specifications, for
Standards and Testing
Learn of issues and possible resolutions

Comments from The IMS Network Testing Group

Develop IMS core network test specifications based upon 3GPP, for:
• Interoperability
• conformance
• network integration
Hold interoperability events (IMS Plugtests)
Coordinate with other organisations such as OMA, MSF, GSMA

Implementations

• Beyond small islands, second wave to replace unscalable, unmaintenable early VoIP systems
• Implementation options - Hybrid CS-GW for transition from CS to LTE, which already has 2 million subscribers on IMS/CS-GW/RNC
• Auto provisioning - to simplify complexity
• IMS functions must be implemented in the core – not in any access network, such as LTE, and can be used for non-Voice as well


Implementing RCS (Rich Communication Suite)

• RCS trial feedback - Good feedback from 400 trial users on RCS but difficult to configure SBC
• RCS implementations should include aggregation with SNS (Social Network Services)– eg contact list from Facebook
• Most appreciated feature of RCS is: - cross-operator interworking and compatibility with ordinary phones, not just smartphones


Specific Issues and Resolutions

• FAX – Delay and Jitter issues - FTTH will solve long delays etc
• Emergency and Lawful Intercept with IMS -There are standards and developed solutions available but Currently still falls back to CS /TDM
• Data Provisioning speed is important, to achieve no service interruption.
• 3GPP II-NNI: Inter-IMS Network to Network Interface - Two levels: Solx (service with control function) and Coix (connection – a pipe for media).
• “PathFinder” Global ENUM – like DNS for phone number; It is a solution to number portability and can optimise routing


About Services

• Most issues are Beyond IMS - integrating OSS/BSS, existing systems, inter-vendors interfaces
• IMS and IN - Pity the Standards did not bring IN and IMS close together; Need iFC enhancements, like in IN; Need to support combining services
• OTT and SNS dominate growth - occupies the minds of commercial people, GSMA-like services have slowed down
• Service layer (Wipro) – Telcos want one SDP to serve all - include IMS and non-IMS services, human and non-humans on NAB, context based, and charge only what is ‘consumed’


Testing Methods, Tools and Test Beds

• Integrate Conformance checking with interoperability testing
• Automation of interoperability trace checking – it can reduce costs by more than 50 % compared to manual validation
• Independent Test Bed- available EPC playground for prototyping applications
• Protocol message customisation tool - allows changing the message and customise the flow
• Security testing tool - testing by ‘fuzzing’, 100% TTCN free – everything is already build in
• IMS is a multi vendor environment - Testing and validation must be an integral part of the deployment process


Memorable Quotes

“IMS is a Journey, not a destination” (ALU)
“SDP is almost anything” (Matjas Bericic, Mobitel)
“Voice as an app versus Voice as a Service” is a challenge (Manuel Vexler, Huawei)
“IMS is not a box, it is a network” (Matjas Bericic, Mobitel)
“global ENUM is DNS for phone numbers” (Adrian Dodd, GSMA)
“Kill with one SIP” (Ari Takanen, Codenomicon)
“ IOP is the red thread running through the entire ETSI standards development process “ (Milan Zoric, ETSI)

All documents from this workshop is available at: http://docbox.etsi.org/Workshop/2010/201011_IMSWORKSHOP/

Monday 8 November 2010

Single Radio Voice Call Continuity (SR‐VCC)

From a 3GPP presentation by Hannu Hietalahti

1. SR-VCC use case
1a. IMS call initiated in LTE can continue in CS domain after moving outside of LTE coverage area
1b. SR-VCC is invoked if no other VoIP capable PS system (e.g., HSPA/eHRPD) is available for VoIP PS-PS HO (Handovers)
1c. Only HO of a single voice bearer from PS to CS is specified
1d. Requires overlapping with 1xRTT/GSM/WCDMA coverage

2. SR-VCC allows a voice calls are anchored in IMS
2a. One-way HO from PS to CS systems (LTE to GSM/UMTS or LTE to 1xRTT)
2b. No simultaneous operation of different radio transceivers needed

3. Rel-9 SR-VCC improvements
3a. IMS support of mid call services (e.g., HOLD, MPTY)
3b. SR-VCC support for emergency calls

4. Video calls, reverse direction from CS call to IMS and optimisations are being studied in Rel-10

Thursday 4 November 2010

Emergency Calls in LTE/SAE Release-9


From a 3GPP presentation by Hannu Hietalahti:

Emergency calls in LTE

Regulatory requirement of emergency calls is supported in Rel-9 for LTE:
1. Detection of emergency numbers in UE
2. Indication and prioritisation of emergency calls
3. Location services, both for routing and user location data for PSAP (Public Safety Answering Point)
4. Callback is possible, but processed as normal call without exceptions

UE matches digits dialledby the user with list of known emergency numbers
1. Emergency number list in the UE is common for CS and PS domain use
2. Default 112 and 911, USIM pre-configuration, downloaded in MM procedure
3. In case of match, the UE shall initiate the call as an emergency call

In IMS emergency calls the UE translates dialled number into emergency service URN
1. Service URN with a top-level service type of "sos" as specified in RFC5031
2. Additionally, sub-service type can be added to indicate emergency category if information on the type of emergency service is known (fire, ambulance, police,…)

P-CSCF (Proxy - Call Session Control Function) must also be prepared to detect emergency call if the UE is not aware of local emergency call
1. This is backup for those cases when the (roaming) UE does not have full information of all local emergency call numbers and initiates a normal call
2. From EPC perspective, it will be a normal PDN connection

Benefit of location information
1. P-CSCF discovers the regionally correct PSAP to take the emergency call
2. PSAP gets information on the precise user location


Related Posts:

Wednesday 22 September 2010

SS7, IMS, SIP and Diamater


Going through my pile of 1 million things to read before I die, I came across this presentation by Tekelec with regards to why Diamater and SIP would be used instead of SS7 in LTE and IMS. The slide in the picture above shows the comparison of SS7 and Diamater.

More and more operators are asking for replacement of SS7 with the Diamater interface. The main reason being that it has been adopted by 3GPP and when we move to an all IP network as in case of LTE it makes sense to have Diamater instead of SS7. There is a good description of Diameter on Wikipedia (cant guarantee the accuracy though) here.

You can read more about SIP at the Tekelec blog here.

There is also an interesting Radvision presentation on Slideshare that I have embedded below:


Thursday 3 June 2010

Quick preview of 3GPP Release-11 Features and Study items


Release 11 Features

Advanced IP Interconnection of Services

The objective is 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.


Release 11 Studies

Study on IMS based Peer-to-Peer Content Distribution Services

The objectives are to study IMS based content distribution services with the following aspects:

- Identifying the user cases to describe how users, operators and service providers will benefit by using/deploying IMS based content distribution services. such as with the improvement of Peer-to-Peer technology. The following shall be considered:
- Mobile access only (e.g. UTRAN, E-UTRAN, I-WLAN);
- Fixed access only (e.g. xDSL, LAN);- Fixed and mobile convergence scenarios;
- Identifying service aspects where IMS network improvements are needed to cater for content distributed services for above accesses;
- Evaluating possible impacts and improvements on network when IMS based content distribution services are deployed;
- Identifying QoS, mobility, charging and security related requirements in the case of content distribution services on IMS;
- Identifying potential copyright issues;


Study on Non Voice Emergency Services

The Non Voice Emergency Services could support the following examples of non-verbal communications to an emergency services network:

1. Text messages from citizen to emergency services
2. Session based and session-less instant messaging type sessions with emergency services
3. Multi-media (e.g., pictures, video clips) transfer to emergency services either during or after other communications with emergency services.
4. Real-time video session with emergency services

In addition to support the general public, this capability would facilitate emergency communications to emergency services by individuals with special needs (e.g., hearing impaired citizens).

The objectives of this study include the following questions for Non Voice Emergency Services with media other than or in addition to voice:

1. What are the requirements for Non Voice Emergency Services?
2. What are the security, reliability, and priority handling requirements for Non Voice Emergency Services?
3. How is the appropriate recipient emergency services system (e.g., PSAP) determined?
4. Are there any implications due to roaming?
5. Are there any implications to hand-over between access networks
6. Are there any implications due to the subscriber crossing a PSAP boundary during Non Voice Emergency Services communications (e.g., subsequent text messages should go to the same PSAP)?
7. Do multiple communication streams (e.g., voice, text, video emergency services) need to be associated together?
8. What types of “call-back” capabilities are required?9. Investigate the load impact of Non Voice Emergency Services in the case of a large scale emergency event or malicious use.

Non Voice Emergency Services will be applicable to GPRS (GERAN, UTRAN) and to EPS (GERAN, UTRAN, E-UTRAN and non-3GPP).


Study on UICC/USIM enhancements

The intent of this study item is to identify use cases and requirements enabling Mobile Network Operators to distribute new services based on the USIM, to improve the customer experience and ease the portability and customisation of operator-owned and customer-owned settings from one device to another (such as APN and other 3G Notebook settings, graphical user interface, MNO brand, Connection Manager settings,…), and help in reducing operation costs and radio resources usage.


Objectives of this study item are:

-To identify use cases and requirements for new USIM
-based services taking into account the GSMA Smart SIM deliverables;
- To identify use cases and requirements for the USIM used inside terminals with specialised functionalities (e.g. radio modems, 3G Notebook terminals) taking into account the GSMA 3GNBK deliverables;
- To identify use cases and requirements to drive the evolution from the traditional USAT to a multimedia USIM toolkit support, with a particular aim to the Smart Card Web Server;


Study on Alternatives to E.164 for Machine-Type Communications

M2M demand is forecast to grow from 50M connections to over 200M by 2013. A large number of these services are today deployed over circuit-switched GSM architectures and require E.164 MSISDNs although such services do not require "dialable" numbers, and generally do not communicate with each other by human interaction.


Without technical alternative to using public numbering resources as addresses, and considering the current forecasts and pending applications for numbers made to numbering plan administration agencies, there is a significant risk that some national numbering/dialling plans will run out of numbers in the near future, which would impact not only these M2M services but also the GSM/UMTS service providers in general.


The Objective is to determine an alternative to identify individual devices and route messages between those devices. Requirements for this alternative include:

- Effectively identify addressing method to be used for end point devices
- Effectively route messaging between those devices
- Support multiple methods for delivering messages, as defined by 22.368
- Support land-based and wireless connectivity
- Make use of IP-based network architectures
- Addressing/identifiers must support mobility and roaming- support on high speed packet
-switched networks when available and on circuit-switched networks
- Consider if there are security issues associated with any alternatives

Friday 6 November 2009

'One Voice Initiative': IMS Based approach adopted


AT&T*, Orange, Telefonica, TeliaSonera, Verizon, Vodafone, Alcatel-Lucent, Ericsson, Nokia Siemens Networks, Nokia, Samsung Electronics Co. Ltd., and Sony Ericsson have defined the preferred way to ensure the smooth introduction and delivery of voice and SMS services on Long Term Evolution (LTE) networks worldwide.

The above telecommunications industry leaders have jointly developed a technical profile for LTE voice and SMS services, also known as the One Voice initiative. The profile defines an optimal set of existing 3GPP-specified functionalities that all industry stakeholders, including network vendors, service providers and handset manufacturers, can use to offer compatible LTE voice solutions.

Open collaborative discussions have concluded that the IP Multimedia Subsystem (IMS) based solution, as defined by 3GPP, is the most applicable approach to meeting the consumers’ expectations for service quality, reliability and availability when moving from existing circuit switched telephony services to IP-based LTE services. This approach will also open the path to service convergence, as IMS is able to simultaneously serve broadband wireline and LTE wireless networks.

By following the jointly defined technical profile, the industry can help guarantee international roaming and interoperability for LTE voice and SMS services, ensuring subscribers continuity of these vital services – all while offering service providers a smooth and well-defined path to LTE.

The objective of the initiative is to ensure the widest possible ecosystem for LTE and to avoid fragmentation of technical solutions. LTE will, with this initiative, not only serve as a broadband access for increasing data traffic, but also for continuing voice and SMS services. Network operators will be able to more quickly develop their customized LTE ecosystem in collaboration with both network equipment vendors and device manufacturers. In addition, the reassurance of global interoperability in an LTE voice landscape and the ability to offer both broadband access and telephony services over LTE will create strong foundations for future business.

The profile for the initial solution has been finalized and is available through the companies associated with this press release. The objective is to hand over the profile and continuing work to existing industry forums.

To view the technical profile, please visit http://news.vzw.com/OneVoiceProfile.pdf.

From Rethink Wireless:

One of the trickiest issues for early LTE deployers is uncertainty over how voice and SMS services - still the key cash cows for most operators - can be supported. Eventually, all these services will be carried over IP, using the IMS (IP Multimedia Subsystem) standard, but only a few carriers, like Verizon Wireless, are looking to deploy all-IP from day one. However, there is pressure to accelerate the process and reduce the cost and risk of LTE/IMS for carriers, and this is the objective of the new One Voice initiative.

Some operators believe they will initially deploy LTE as a data-only network, but most want to support voice and, even more importantly, SMS (which underpins many cellco processes and customer communications). Faced with the risk that large players might delay their plans until they have a strong route to voice, One Voice has defined a profile based on existing 3GPP standards for IMS-enabled voice.

The work has initially emerged from Nokia Siemens, which was previously trying to get wide industry support for its own interim voice over LTE solution, VoLTE (which only worked with its own softswitches). The company's convergent core marketing manager, Sandro Tavares, said One Voice should ease fears over how voice will be deployed by resolving roaming and interworking issues at an early stage. It is not creating a new standard, but aims to ensure compatibility between networks and devices by creating a common profile, which defines an optimal set of existing 3GPP functionalities for use by vendors and operators. "There is no new standard," added Tavares. "It's just using what is there already."

NSN is already producing LTE equipment that complies with the new profile, and so has a headstart in offering an important feature to early triallists - which could boost its so-far low profile in LTE tests, dominated by Ericsson and Huawei. However, the vendor will now hand its work to the 3GPP and GSM Association so that other companies can work on and adopt the profile. So far, it has signed support from most of the key operators that tend to wield influence over cellular standards, apart from DoCoMo and China Mobile - AT&T, Orange, Telefonica, TeliaSonera, Verizon Wireless and Vodafone are there, plus a strong line-up of vendors. These are Alcatel-Lucent and Ericsson on the infrastructure side and Nokia, Samsung and Sony Ericsson for devices. The group needs to get the Chinese vendors on board to complete the set, as well as Motorola.

The supporters of the initiative say this is their "preferred path" for voice over LTE, though for carriers that do not want to move to IMS at an early stage, there are other options available - namely open web-based voice; the stopgap solution of Circuit Switch Fallback (also enshrined in 3GPP standards), where the handset is forced off the LTE network onto 2G or 3G for voice calls; and variations on the theme of using circuit switch over packet techniques. There are two main approaches to this - MSC Voice, which is tied to a switch, with NSN's VoLTE the most prominent example; and VoLGA, which is architecture independent, and uses the UMA/GAN (Unlicensed Mobile Access/Generic Access Network) protocol. This Kineto originated technology was originally adopted for Wi-Fi/3G fixed-mobile convergence and as such did find its way into the 3GPP. VoLGA does not require modifications in the LTE RAN or core, or the MSC, but uses a separate gateway controller.

Some of the One Voice supporters are already involved in VoLGA (though its major carrier T-Mobile has not yet joined the new group). Steve Shaw, who heads up corporate marketing for Kineto and VoLGA, believes that IMS is the way that, ultimately, voice will be handled, but it has a long way to go before it is usable, and so there will still be a role for several years for approaches like VoLGA.

T-Mobile will I assume soon have to follow suit and fall in line otherwise they may have limited devices that are available and there will also be inter-operability issues.

Last week I attended a presentation by IET Berkshire on Voice Services over LTE, presented by Iain Sharp from Nortel. Even though this announcement came yesterday, Iain did say that IMS is the way forward for Voice over LTE. If interested you can see the presentation here.


Tuesday 14 April 2009

IMS Deployment and Future Strategy

A very interesting post by Christophe Gourraud in The IMS Lantern. If you are even remotely interested in IMS then you should read the post here.

Sunday 23 November 2008

Solving the LTE voice dilemma

Continuing the discussion from LTE World Summit, this is something that has been discussed in the past by myself and other blogs as well. We know that there is no out of the box solution for voice calls in Release 8 but there are some solutions that are being standardised for this problem. Dr. Howard Benn, Director of Cellular Standards, Motorola Mobile Devices gave an interesting presentation on this topic titled, "Voice –how to talk over LTE". Here is the summary of his presentation along with some more information:
As we know, IMS was introduced in Rel 5 but even till today, there has been no major IMS rollouts. There are some operators working on deploying the IMS solution but in reality its not been as successful as it should have been. If IMS is available then the problem of voice call on LTE goes away. The problem can be solved using Voice Call Continuity or VCC. Infact there is a bunch of specifications on IMS Centralized Services (ICS) and network Centric VCC for solving this and other similar problems.

So with IMS not being available, the first alternative for this problem is Circuit Switched Fallack (CSFB). In this, as can be seen from the MSC above, the user is attached to an LTE network. MSC can send Paging to the UE and if the user accepts the voice call then he is handed over to 2G/3G network. The big problem with this approach is additional time required to establish the voice call and the PS services might get disrupted, depending on how its handled.

The second solution is to have a Generic Access Network (GAN... previously known as UMA) based solution. This is similar solution to the ones used by some Femtocells. This would mean that the UE's would require GAN chipsets and GAN is known to be power hungry so it can impact the battery life significantly.

China Mobile's, Bill Huang in a recent interview mentioned that “We could carry voice over UMA” and “We will have an LTE network that supports voice…”. He was referring to this approach mentioned above.

Finally there are always proprietary options like Skype that can be used along with the data services to solve the voice problem.

Infact a service like Vonage, modified for mobiles, can solve this problem easily. You can connect a VoIP client from your phone or device to Vonage and you are given a landline number that you can pass to others. When calls are received on this number, the client in the mobile rings and you answer the call normally.

Nick Yamasaki from KDDI mentioned that KDDI will roll out LTE with CS fallback option for voice initially but then SRVCC (Single Radio VCC) solution will be adopted in future.

Tuesday 23 September 2008

NEC and Ubiquisys to help deploy first IMS based Femtocell Solution

Japanese operator SoftBank is to score a world first in January, when it becomes the first service provider to launch 3G femtocells in a commercial capacity.

SoftBank, Japan's third placed carrier behind NTT DoCoMo and KDDI, said it will offer 3G femtos from January 2009 using kit from UK-based Ubiquisys and a supporting IMS core from NEC.

According to Unstrung:

Japan's Softbank Mobile Corp. is still trying to get the national regulator to change a quirky policy that could thwart its plan for a large-scale femtocell deployment, according to an industry source. In Japan, only a qualified engineer can install a base station, and that rule applies to the small, low-power base stations, too.

Femtocells are supposed to be "zero touch" and easily installed by the users themselves. So, a regulation that mandates sending out an engineer to plug in each and every home access point would kill an operator's femto business case.

The Japanese policy is expected to be changed by the end of the year, which wouldn’t be too soon for Softbank. According to our source, the operator has already installed 20,000 devices, has chosen an NEC Corp. solution -- which uses Ubiquisys Ltd's femtocell -- and is also checking out equipment from Huawei Technologies Co. Ltd. Softbank isn't quite ready for a mass market deployment because there are still some technical issues, according to the industry source.

Meantime, NTT DoCoMo Inc. said last week that it was going to use the new HSPA version of Mitsubishi Corp. femtocell for its Home Area service.

There have been couple of so called Femtocell launches already namely T-Mobile Hotspot@ and Sprints CDMA Femtocell but they are not really Femtocells because they just provide an extension for voice services and no other type of services.

The Femtocells are called ZAPs (Zonegate Access Points) and Japanese customers will be able to get their hands on them from Jan 2009.

Saturday 13 September 2008

Next Generation All-IP Telecom Networks: Quality of Service Challenges and Is...

There is an Interesting tutorial on Next generation All IP Networks from Google on Youtube. Unfortunately they have not allowed sharing of that but you can see that on youtube:

http://www.youtube.com/watch?v=FC4E946i6aE