LTE Release-8 UE Categories table

I had posted a table earlier about the LTE UE Categories here. Just came across the 3GPP official UE Categories table today as shown in the picture above.

It would be very interesting to see a device supporting 4x4 MIMO later that can be useful in transferring high amounts of data.

3G Americas Publishes New Report on LTE SON Self-Optimizing / Self-Organizing Networks

I have blogged about SON networks before. Now has published an educational report titled, The Benefits of SON in LTE, to increase understanding of the improvements in network management that have been developed through 3GPP standards – Release 8, Release 9 and beyond.

Self-Optimizing and Self-Organizing Networks, called SON, can significantly improve network management performance, helping operators and their customers. The 3GPP standards organization is standardizing self-optimizing and self-organizing capabilities for LTE. LTE SON will leverage network intelligence, automation and network management features in order to automate the configuration and optimization of wireless networks, thereby increasing efficiency as well as improving network performance and flexibility.

“The time is right for SON as wireless carriers’ networks have increasing mobile broadband demand and a high level of complexity,” said Chris Pearson, President of 3G Americas. “The good news is that smartphones, netbooks and emerging classes of mobile devices are driving significant growth of wireless data usage. However, operators will need to continue to significantly improve network management capabilities to efficiently meet the demands of this new mobile broadband world.”

The Benefits of SON in LTE describes the motivation behind SON and provides an overview of key SON features contained in Releases 8 and 9 that will serve as a solution for network operators. Motivations for operators to deploy SON include:

• Wireless service providers must now support a growing number of higher-bandwidth data applications and services on their networks
• Operators must drive down the delivery cost per bit
• Radio access network complexity will increase through additions of small cells such as femtocells, picocells as well as WiFi access points to increase and improve coverage and capacity

These and other trends portend ever-increasing demands upon service providers in the areas of network performance and operations.

Initial solutions are offered in the 3GPP Release 8 specifications, which were completed in March 2009, and include SON features such as automatic inventory, software download, neighbor relations and PCI assignment that would be built over 3GPP network management architecture. LTE SON features begin with 3GPP Release 8 and evolve with the expected LTE network evolution stages. In 3GPP Release 9, other SON features are addressed, such as the optimization of coverage and capacity, mobility, RACH, load balancing and support of SON features in multi-vendor network environments.

Other organizations such as the Next Generation Mobile Networks (NGMN) have contributed significantly to the development and standardization of SON at 3GPP.

“Self-optimizing networks are a key part in the future-proofing of network reliability and operational efficiency,” said Dr. Peter Meissner, Operating Officer of the NGMN Alliance. “NGMN established a set of initial requirements and since then has worked with its partners to define the remaining requirements and to drive forward the early adoption in the standardization.”

You can find this whitepaper and many other whitepapers on LTE at the 3G4G Library here.

Femtocells Standardization in 3GPP

Femtocells have been around since 2007. Before Femtocells, the smallest possible cell was the picocell that was designed to serve a small area, generally a office or a conference room. With Femtocells came the idea of having really small cells that can be used in houses and they were designed to serve just one home. Ofcourse in my past blogs you would have noticed me mentioning about Super Femtos and Femto++ that can cater for more users in a small confined space, typically a small office or a meeting room but as far as the most common definition is concerned they are designed for small confined spaces and are intended to serve less than 10 users simultaneously.

This blog post is based on IEEE paper on "Standardization of Femtocells in 3GPP" that appeared in IEEE Communications Magazine, September 2009 issue. This is not a copy paste article but is based on my understanding of Femtos and the research based on the IEEE paper. This post only focusses on 3GPP based femtocells, i.e., Femtocells that use UMTS HSDPA/HSPA based technology and an introduction to OFDM based LTE femtocells.

The reason attention is being paid to the Femtocells is because as I have blogged in the past, there are some interesting studies that suggest that majority of the calls and data browsing on mobiles originate in the home and the higher the frequency being used, the less its ability to penetrate walls. As a result to take advantage of the latest high speed technologies like HSDPA/HSUPA, it makes sense to have a small cell sitting in the home giving ability to the mobiles to have high speed error free transmission. In addition to this if some of the users that are experiencing poor signal quality are handed over to these femtocells, the overall data rate of the macro cell will increase thereby providing better experience to other users.

Each technology brings its own set of problems and femocells are no exception. There are three important problems that needs to be answered. They are as follows:

• Radio interference mitigation and management: Since femtocells would be deployed in adhoc manner by the users and for the cost to be kept down they should require no additional work from the operators point of view, they can create interference with other femtocells and in the worst possible scenario, with the macro cell. It may not be possible initially to configure everything correctly but once operational, it should be possible to adjust the parameters like power, scrambling codes, UARFCN dynamically to minimise the interference.

• Regulatory aspects: Since the mobiles work in licensed spectrum bands, it is required that they follow the regulatory laws and operate in a partcular area in a band it is licensed. This is not a problem in Europe where the operators are given bands for the whole country but in places like USA and India where there are physical boundaries within the country for the allocation of spectrum for a particular operator. This brings us to the next important point.

• Location detection: This is important from the regulatory aspect to verify that a Femtocell can use a particular band over an area and also useful for emergency case where location information is essential. It is important to make sure that the user does not move the device after initial setup and hence the detection should be made everytime the femto is started and also at regular intervals.

3GPP FEMTOCELLS STANDARDIZATION

Since the femtocells have been available for quite a while now, most of them do not comply to standards and they are proprietary solutions. This means that they are not interoperable and can only work with one particular operator. To combat this and to create economy of scale, it became necessary to standardise femtocells. Standardized interfaces from the core network to femtocell devices can potentially allow system operators to deploy femtocell devices from multiple vendors in a mix-and-match manner. Such interfaces can also allow femtocell devices to connect to gateways made by multiple vendors in the system operator’s core network (e.g., home NodeB gateway [HNB-GW] devices).

In 2008, Femto Forum was formed and it started discussion on the architecture. From 15 different proposals, consensus was reached in May over the Iuh interface as shown below.

There are two main standard development organizations (SDOs) shaping the standard for UMTS-related (UTRAN) femto technology: 3GPP and The Broadband Forum (BBF).
More about 3GPP here. BBF (http://www.broadbandforum.org) was called the DSL Forum until last year. As an SDO to meet the needs of fixed broadband technologies, it has created specifications mainly for DSL-related technologies. It consists of multiple Working Groups. The Broadband Home WG in particular is responsible for the specification of CPE device remote management. The specification is called CPE wide area network (WAN) Management Protocol (CWMP), which is commonly known by its document number, TR-069.

There are several other important organisations for femto technology. The two popular ones are the Femto Forum (www.femtoforum.org) and Next Generation Mobile Network (NGMN).

3GPP has different terminology for Femtocells and components related to that. They are as follows:

Generic term: Femtocell
3GPP Term: home NodeB (HNB)
Definition: The consumer premises equipment (CPE) device that functions as the small-scale nodeB by interfacing to the handset over the standard air interface (Uu) and connecting to the mobile network over the Iuh interface.

Generic term: FAP Gateway (FAP-GW) or Concentrator
3GPP Term: home NodeB gateway (HNB-GW)
Definition: The network element that directly terminates the Iuh interface with the HNB and the existing IuCS and IuPS interface with the CN. It effectively aggregates a large number of HNBs (i.e., Iuh interface) and presents it as a single IuCS/PS interface to the CN.

Generic term: Auto-Configuration Server (ACS)
3GPP Term: home NodeB management system (HMS)
Definition: The network element that terminates TR-069 with the HNB to handle the remote management of a large number of HNBs.

In addition, there is a security gateway (SeGW) that establishes IPsec tunnel to HNB. This ensures that all the Iuh traffic is securely protected from the devices in home to the HNB-GW.
The HNB-GW acts as a concentrator to aggregate a large number of HNBs which are logically represented as a single IuCS/IuPS interface to the CN. In other words, from the CN’s perspective, it appears as if it is connected to a single large radio network controller (RNC). This satisfies a key requirement from 3GPP system operators and many vendors that the femtocell system architecture not require any changes to existing CN systems.

The radio interface between HNB and UE is the standard RRC based air interface but has been modified to incude HNB specific changes like the closed subscriber group (CSG) related information.

Two new protocols were defined to address HNB-specific differences from the existing Iu interface protocol to 3GPP UMTS base stations (chiefly, RANAP at the application layer).

• HNB Application Protocol (HNBAP): An application layer protocol that provides HNB-specific control features unique to HNB/femtocell deployment (e.g., registration of the HNB device with the HNBGW).

• RANAP User Adaptation (RUA): Provides a lightweight adaptation function to allow RANAP messages and signaling information to be transported directly over Stream Control Transport Protocol (SCTP) rather than Iu, which uses a heavier and more complex protocol stack that is less well suited to femtocells operating over untrusted networks from home users (e.g., transported over DSL or cable modem connections).

Figure above is representation of the protocol stack diagram being used in TS 25.467.

Security for femtocell networks consists of two major parts: femtocell (HNB) device authentication, and encryption/ciphering of bearer and control information across the untrusted Internet connection between the HNB and the HNB-GW (e.g., non-secure commercial Internet service). The 3GPP UMTS femtocell architecture provides solutions to both of these problems. 3GPP was not able to complete the standardization of security aspects in UMTS Release 8; however, the basic aspects of the architecture were agreed on, and were partially driven by broad industry support for a consensus security architecture facilitated in discussions within the Femto Forum. All security specifications will be completed in UMTS Release 9 (targeted for Dec. 2009).

FEMTOCELL MANAGEMENT

Management of femtocells is a very big topic and very important one for the reasons discussed above.

The BBF has created CWMP, also referred to as TR-069. TR-069 defines a generic framework to establish connection between the CPE and the automatic configuration server (ACS) to provide configuration of the CPE. The messages are defined in Simple Object Access Protocol (SOAP) methods based on XML encoding, transported over HTTP/TCP. It is flexible and extensive enough to incorporate various types of CPE devices using various technologies. In fact, although TR-069 was originally created to manage the DSL gateway device, it has been adopted by many other types of devices and technologies.

The fundamental functionalities TR-069 provides are as follows:

• Auto-configuration of the CPE and dynamic service provisioning

• Software/firmware management and upgrade

• Status and performance monitoring

• Diagnostics

The auto-configuration parameters are defined in a data model. Multiple data model specifications exist in the BBF in order to meet the needs of various CPE device types. In fact, the TR-069 data model is a family of documents that has grown over the years in order to meet the needs of supporting new types of CPE devices that emerge in the market. In this respect, femtocell is no exception. However, the two most common and generic data models are:

• TR-098: “Internet Gateway Device Data Model for TR-069”

• TR-106: “Data Model Template for TR-069-Enabled Devices”

HAND-IN AND FEMTO-TO-FEMTO HANDOVERS

The 3GPP specifications focused on handovers in only one direction initially — from femtocell devices to the macrocellular system (sometimes called handout). A conscious decision was made to exclude handover from the macrocellular system to the femtocell devices (sometimes called macro to femtocell hand-in). This decision was driven by two factors:

• There are a number of technical challenges in supporting hand-in with unmodified mobile devices and core network components.

• The system operator requirements clearly indicate that supporting handout is much more important to end users.

Nonetheless, there is still a strong desire to develop open, interoperable ways to support handin in an efficient and reliable manner, and the second phase of standards in 3GPP is anticipated to support such a capability.

NEXT-G EFFORTS

3GPP Release 8 defines the over-the-air radio signaling that is necessary to support LTE femtocells. However, there are a number of RAN transport and core network architecture, interface, and security aspects that will be addressed as part off 3GPP’s Release 9 work efforts. While it is preliminary as of the publication of this article, it seems highly likely that all necessary RAN transport and core network work efforts for LTE femtocells will be completed in 3GPP Release 9 (targeted for completion by the end of 2009).

3GPP STANDARDS ON FEMTOCELLS

[1] 3GPP TS 25.331: RRC

[2] 3GPP TS 25.367: Mobility Procedures for Home NodeB (HNB); Overall Description; Sage 2

[3] 3GPP TS 25.467: UTRAN Architecture for 3G Home NodeB; Stage 2

[4] 3GPP TS 25.469: UTRAN Iuh Interface Home NodeB (HNB) Application Part (HNBAP) Signaling

[5] 3GPP TS 25.468: UTRAN Iuh Interface RANAP User Adaption (RUA) Signaling

[6] 3GPP TR 3.020: Home (e)NodeB; Network Aspects -(http://www.3gpp.org/ftp/tsg_ran/WG3_Iu/R3_internal_TRs/R3.020_Home_eNodeB/)

[7] 3GPP TS 25.104: Base Station (BS) Radio Transmission and Reception (FDD)

[8] 3GPP TS 25.141: Base Station (BS) Conformance Testing (FDD)

[9] 3GPP TR 25.967: FDD Home NodeB RF Requirements

[10] 3GPP TS 22.011: Service Accessibility

[11] 3GPP TS 22.220: Service Requirements for Home NodeB (HNB) and Home eNodeB (HeNB)

[12] 3GPP TR 23.830: Architecture Aspects of Home NodeB and Home eNodeB

[13] 3GPP TR 23.832: IMS Aspects of Architecture for Home NodeB; Stage 2

[14] 3GPP TS 36.300: E-UTRA and E-UTRAN; Overall Description; Stage 2

[15] 3GPP TR 33.820: Security of H(e)NB 3GPP TR 32.821: Telecommunication Management; Study of Self-Organizing Networks (SON) Related OAM Interfaces for Home NodeB

[16] 3GPP TS 32.581: Telecommunications Management; Home Node B (HNB) Operations, Administration, Maintenance and Provisioning (OAM&P); Concepts and Requirements for Type 1 Interface HNB to HNB Management System (HMS)

[17] 3GPP TS 32.582: Telecommunications Management; Home NodeB (HNB) Operations, Administration, Maintenance and Provisioning (OAM&P); Information Model for Type 1 Interface HNB to HNB Management System (HMS)

[18] 3GPP TS 32.583: Telecommunications Management; Home NodeB (HNB) Operations, Administration, Maintenance and Provisioning (OAM&P); Procedure Flows for Type 1 Interface HNB to HNB Management System (HMS)

[19] 3GPP TS 32.584: Telecommunications Management; Home NodeB (HNB) Operations, Administration, Maintenance and Provisioning (OAM&P); XML Definitions for Type 1 Interface HNB to HNB Management System (HMS)

I would strongly recommend reading [3] and [6] for anyone who wants to gain better understanding of how Femtocells work.

Paging Permission with Access Control (PPAC) Study in Release 8

A new feature that was studied part of 3GPP Release 8 was PPAC (Paging Permission with Access Control). The aim of this feature was that in an emergency situation, the network can get congested and as a result all access is barred except for emergency services. This can cause problem when the user requires to be contacted but is unreachable.

Lets take Case 1: Disaster risk management office in government calls to emergency responder within disaster areas in order to supply temporary service to the disaster areas.

This should not be a problem because the emergency responder is an authorised user with higher priority of access class and will be able to make and receive calls in the disaster area.



Case2: Ambulance attendant reaches a rescue site in the disaster area but cannot find the person who asked for help originally because of unexpected destruction. The attendant should be able to call him/her in order to make sure where he/she is.

Case3: Firefighter is at a scene of fire of high-rise apartment in the disaster area and calls to a person who asked for help in order to give out directives on the evacuation.

These scenarios as such are no problem except when there is congestion on the receiving side. In that case either the emergency attendant or the risk management office should be able to get in touch and establish the call.

In technical terms, the people like emergency attendants and disaster risk management office attendants are called authorised users and the ordinary people who need help are known as unauthorised users.

It should also be possible to make a small duration call between unauthorised users so people can check each others safety. This can be controlled by changing the permission of different access class for small durations so that people can trigger calls for small duration.

The study found that eMLPP (Enhanced Multi-Level Precedence and Pre-emption) that is already available since GSM days can resolve the problem of prioritisation in resource allocation. A new capability will be required to allow UEs with indications from the network to perform location registration and respond to a paging request even though it is under access class barring conditions to complete certain classes of calls or messages (e.g. calls from emergency personnel, …).

This new capability will be available probably when Release 9 is finalised in December this year.

As far as understanding this eMLPP is concerned, the following book has quite a lot of details on this topic. If you can get hold of it then do go through it.

Preferential Emergency Communications: From Telecommunications to the Internet (The Springer International Series in Engineering and Computer Science)

Here is the google books link for that.

Flexible RLC in Release 7 and Release 8

In R99, RLC packets had to be relatively small to avoid the retransmission of very large packets in case of transmission errors. Another reason for the relatively small RLC packet size was the need to provide sufficiently small step sizes for adjusting the data rates for Release 99 channels.

The RLC packet size in Release 99 is not only small, but it is also fixed for Acknowledged Mode Data and there are just a limited number of block sizes in UM Data. This limitation is due to transport channel data rate limitations in Release 99. The RLC payload size is fixed to 40 bytes in Release 99 for Acknowledged Mode Data. The same RLC solution is applied to HSDPA Release 5 and HSUPA Release 6 as well: the 40-byte packets are transmitted from RNC to the base station for HSDPA. An additional confi guration option to use an 80-byte RLC packet size was introduced in Release 5 to avoid extensive RLC protocol overhead, L2 processing and RLC transmission window stalling. With the 2 ms TTI used with HSDPA this leads to possible data rates being multiples of 160 kbps and 320 kbps respectively.

As the data rates are further increased in Release 7, increasing the RLC packet size even further would significantly impact on the granularity of the data rates available for HSDPA scheduling and the possible minimum data rates.

3GPP HSDPA and HSUPA allow the optimization of the L2 operation since L1 retransmissions are used and the probability of L2 retransmissions is very low. Also, the Release 99 transport channel limitation does not apply to HSDPA/HSUPA since the L2 block sizes are independent of the transport formats. Therefore, it is possible to use fl exible and considerably larger RLC sizes and introduce segmentation to the Medium Access Control (MAC) layer in the base station.

This optimization is included for downlink in Release 7 and for uplink in Release 8 and it is called flexible RLC and MAC segmentation solution. The RLC block size in fl exible RLC solution can be as large as an Internet Protocol (IP) packet, which is typically 1500 bytes for download. There is no need for packet segmentation in RNC. By introducing the segmentation to the MAC, the MAC can perform the segmentation of the large RLC PDU based on physical layer requirements when needed. The fl exible RLC concept in downlink is illustrated in Figure above.


There is a lot of interesting information in R&S presentation on HSPA. See here.

Main source of the content above and for further information see: LTE for UMTS: OFDMA and SC-FDMA Based Radio Access

Enhanced UL for CELL_FACH state in Release 8

Users should always be kept in the state that gives the best trade-off between data rate availability, latency, battery consumption and usage of network resources. As a complement to the data rate enhancements made to the dedicated state (CELL_DCH), 3GPP has also made significant enhancements to the common states (URA_PCH, CELL_PCH and CELL_FACH). Release 7 introduced HSDPA mechanisms in the common states in order to improve their data rates, latency and code usage. Release 8 introduces corresponding enhancements in the uplink, allowing base stations to configure and dynamically manage up to 32 common Enhanced Uplink resources in each cell.



This enhancement improves latency and data rates for keep-alive messages (for example, from VPN or messenger applications) as well as web-browsing events, providing a seamless transition from EUL in common state to EUL in dedicated state.

As a further improvement of the CELL_FACH state, Release 8 introduces discontinuous reception (DRX), which significantly reduces battery consumption. DRX is now supported in all common and dedicated states.



Enhanced FACH and RACH bring a few performance benefits:

• RACH and FACH data rates can be increased beyond 1 Mbps. The end user could get immediate access to relatively high data rates without the latency of channel allocation.
• The state transition from Cell_FACH to Cell_DCH would be practically seamless. Once the network resources for the channel allocation are available, a seamless transition can take place to Cell_DCH since the physical channel is not changed.
• Unnecessary state transitions to Cell_DCH can be avoided when more data can be transmitted in Cell_FACH state. Many applications create some background traffic that is today carried on Cell_DCH. Therefore, Enhanced RACH and FACH can reduce the channel element consumption in NodeB.
• Discontinuous reception could be used in Cell_FACH to reduce the power consumption. The discontinuous reception can be implemented since Enhanced FACH uses short 2 ms TTI instead of 10 ms as in Release 99. The discontinuous reception in Cell_FACH state is introduced in 3GPP Release 8.

For more information see: LTE for UMTS: OFDMA and SC-FDMA Based Radio Access

On Self Organising Network Concept in Rel-8 and Rel-9

Self-Organising Networks popularly known as SON are feature of 3GPP Release 8 and Release 9. SON has been around for quite some time now and is not a new concept. Its not an evolutionary technology, rather a revolutionary technology. The first time I heard of SON was in relation to Femtocells. Remember, a Femtocell has to start in an unfamiliar environment, learn about its surrounding and then adapt to the environment.

Other terms often used to mean SON is 'Plug-n-play' or 'PnP', 'Zero Touch', 'Auto Configured', 'Self Managed...', etc. SON is a very useful feature that will allow for the automation of several tasks lowering the OPEX costs. Examples include plug and play or a cell in between existing ones, neighbour recognition and (re-)configuration, optimizations, etc. Properly implemented, it could kill off drive-testing.

In simplest of terms, SON can be explained with the basic diagram above. A new cell created in an existing environment possibly due to too many existing resources being in use or too many users in an area during a particular time (football match for example) and this cell has to look at the surrounding and adjust its conditions. The other existing cells also have to adjust tehmselves with the change in surroundings.

According to recent analysis in NEC Whitepaper on SON (available here), about 17 % of wireless operator’s CAPEX is spent on engineering and installation services. SON’s self-configuring functions are expected to eliminate many on-site operations for the basic settings and subsequent updating of network equipments, and thus reduce CAPEX.

It is also known that about 24 % of a typical wireless operator’s revenue goes to network OPEX, which are the cost of network operation and maintenance, training and support, power, transmission, and site rental. SON’s self-optimizing functions will reduce a workload for site survey and analysis of network performances, and thus reduce OPEX. Moreover, SON’s energy-saving functions reduce the costs of power consumed by the equipment.

Self-optimizing and self-healing architectures improve user perceived qualities by mitigating quality degradations that result from inaccuracies of the planning or equipment faults as early as possible and by optimizing the network parameters under interference and overload conditions.

Nomor research has got an excellent paper on SON with regards to LTE. The full paper is available here. Here is an extract from that paper.

The main functionality of SON includes: self-configuration, self-optimization and self-healing.

Self-configuration process is defined as the process where newly deployed nodes (eNBs) are configured by automatic installation procedures to get the necessary basic configuration for system operation

Self-optimization process is defined as the process where UE & eNB measurements and performance measurements are used to autotune the network

Self-healing function aims at automatic detection and localization of most of the failures and applies self-healing mechanisms to solve several failure classes, such as reducing the output power in case of temperature failure or automatic fallback to previous software version.

A Self-configuration Subsystem will be created in OAM to be responsible for the selfconfiguration of eNB. For self-optimisation functions, they can be located in OAM or eNB or both of them. So according to the location of optimisation algorithms, SON can be divided into three classes: Centralised SON, Distributed SON and Hybrid SON.

The paper also lists the Use cases and the problems ands solutions for the use cases.

NEC whitepaper on SON is quite recent and it lists the recent standards status:

3GPP has introduced SON items in its standardization path as required features for LTE deployments. Rel. 8 includes the first specifications on requirements, integration with operators’ processes, and identification of main use cases. Rel. 9 is expected to define advanced features, which will introduce self-healing and self-optimization capabilities into LTE. The SON related specifications are driven from the SA5 Working Group (WG) – mainly for architectural aspects– and the RAN3 WG – especially for the optimization of radio functions. Also, Rel. 8 defined the grounding documents for SON: “SON Concepts and Requirements” in TS 32.500, and two main use cases– “Self-Establishment of eNodeB” and “Automatic Neighbor Relation” – in TS 32.501, 32.502 and 32.511.

eCall to save lives

Qualcomm is offering its endorsement for the Third Generation Partnership Project’s (3GPP’s) recent approval of the eCall in-band modem specification, which supports the European Union’s eCall road safety initiative.

The 3GPP standardization group has approved the final specs of the eCall in-band modem standard. The specification work was undertaken by 3GPP at the request of the European Telecommunications Standards Institute (ETSI) and the European Commission, which sought a standardized technical solution to support the deployment of eCall across Europe. With the completion of this work, ETSI has adopted the 3GPP specifications and will publish them as ETSI standards.

The eCall public road safety initiative is designed to provide rapid assistance to motorists involved in a collision anywhere in the European Union by automatically generating an emergency voice call via the cellular network to local emergency agencies, as well as sending information such as position location. ECall, which is scheduled for introduction and operation across Europe in late 2010, is expected to help save lives by improving notification of road accidents and speeding up emergency service response.

The eCall Memorandum of Understanding (eCall MoU) got the backing of Estonia. The country thereby commits itself to the timely implementation of eCall, the pan-European emergency call system. eCall enables a car involved in a serious crash to automatically dial 112 and call the nearest emergency centre. In the call, it notifies the accident and transmits its exact location. Jüri Pihl, Estonian Minister of the Interior, signed the eCall MoU in the presence of Viviane Reding, European Commissioner for the Information Society and Media. Estonia is the 15th EU Member State to sign the MoU.

The pan-European in-vehicle emergency call system, "eCall", is a device in the car that uses 112, the single European emergency number, to automatically call the nearest emergency centre in the event of a serious traffic accident. In the call the exact location of the accident scene is transmitted to the centre, even is there is no voice connection, because, for example, all passengers have lost consciousness. Knowledge of the exact location of the crash reduces response time of the rescue teams by 40 % in built-up areas and 50 % in rural environments. 2.500 lives could be saved in the European Union annually, and 15 % of serious injuries mitigated, if all European cars were equipped with eCall. Other EU Member States that have signed the MoU so far are: Austria, Cyprus, Czech Republic, Finland, Germany, Greece, Italy, Lithuania, Portugal, Slovakia, Slovenia, Sweden, Spain and The Netherlands. Non-EU States Iceland, Norway and Switzerland belong to the signatories as well.

Watch this Video to understand all about eCall



eCall, Initially designed to fulfil European requirements, the eCall feature will:

• Enable the automated delivery of 140 bytes of information in astandardised format to a Public Safety Answering Point (PSAP)
• Complete that delivery with 4 seconds
• Provide accurate location information

The introduction of this feature will dramatically reduce the time taken for emergency assistance to arrive at the scene of an accident and hence help to save lives

For more information see:
3GPP TR 22.967
3GPP TS 22.105
3GPP TS 24.008
http://www.ertico.com/
Reference: Adrian Scrase Presentation in LTE World Summit

Temporary Identities in LTE/SAE - 1

An MS may be allocated three TMSIs, one for services provided through the MSC (TMSI), one for services provided through the SGSN (P-TMSI for short) and one for the services provided via the MME (M-TMSI part GUTI for short).

The purpose of the GUTI is to provide an unambiguous identification of the UE that does not reveal the UE or the user's permanent identity in the Evolved Packet System (EPS). It also allows the identification of the MME and network. It can be used by the network and the UE to establish the UE's identity during signalling between them in the EPS.

The GUTI has two main components:

• one that uniquely identifies the MME which allocated the GUTI; and
• one that uniquely identifies the UE within the MME that allocated the GUTI.

Within the MME, the mobile shall be identified by the M-TMSI.

The Globally Unique MME Identifier (GUMMEI) shall be constructed from the MCC, MNC and MME Identifier (MMEI).

The MMEI shall be constructed from an MME Group ID (MMEGI) and an MME Code (MMEC).

The GUTI shall be constructed from the GUMMEI and the M-TMSI.

For paging purposes, the mobile is paged with the S-TMSI. The S-TMSI shall be constructed from the MMEC and the M-TMSI.
S-TMSI = MMEC + M-TMSI

The operator shall need to ensure that the MMEC is unique within the MME pool area and, if overlapping pool areas are in use, unique within the area of overlapping MME pools.

The GUTI shall be used to support subscriber identity confidentiality, and, in the shortened S-TMSI form, to enable more efficient radio signalling procedures (e.g. paging and Service Request).


The format and size of the GUTI is therefore the following:
GUTI = GUMMEI + M-TMSI, where
GUMMEI = MCC + MNC + MME Identifier and
MME Identifier = MME Group ID + MME Code
MCC and MNC shall have the same field size as in earlier 3GPP systems.
M-TMSI shall be of 32 bits length.
MME Group ID shall be of 16 bits length.
MME Code shall be of 8 bits length.

During Handover to GERAN/UTRAN
RAI = MCC + MNC + LAC + RAC
E UTRAN "MCC" maps to GERAN/UTRAN "MCC"
E UTRAN "MNC" maps to GERAN/UTRAN "MNC"
E UTRAN "MME Group ID" maps to GERAN/UTRAN "LAC"
E UTRAN "MME Code" maps to GERAN/UTRAN "RAC" and is also copied into the 8 most significant bits of the NRI field within the P TMSI;

"P-TMSI" includes the mapped NRI
P TMSI shall be of 32 bits length where the two topmost bits are reserved and always set to 11.

E UTRAN "M-TMSI" maps as follows:
6 bits of the E UTRAN "M-TMSI" starting at bit 29 and down to bit 24 are mapped into bit 29 and down to bit 24 of the GERAN/UTRAN "P TMSI";
16 bits of the E UTRAN "M-TMSI" starting at bit 15 and down to bit 0 are mapped into bit 15 and down to bit 0 of the GERAN/UTRAN "P TMSI";
and the remaining 8 bits of the E UTRAN "M-TMSI" are mapped into the 8 MBS bits of the "P-TMSI signature" field.

Abbreviations Summary:
GUTI - Globally Unique Temporary UE Identity
GUMMEI - Globally Unique MME Identifier
MMEGI - MME Group ID
MMEC - MME Code
S-TMSI = SAE Temporary Mobile Subscriber Identity
M-TMSI = MME Temporary Mobile Subscriber Identity

Reference: 3GPP TS 23.003: Technical Specification Group Core Network and Terminals; Numbering, addressing and identification (Release 8) - Section 2.8

Home e-NodeB Architecture in Release 8

The Architecture of Home e-NodeB's (popularly known as Femtocells) is as shown above.

The E-UTRAN architecture may deploy a Home eNB Gateway (HeNB GW) to allow the S1 interface between the HeNB and the EPC to scale to support a large number of HeNBs. The HeNB GW serves as a concentrator for the C-Plane, specifically the S1-MME interface. The S1-U interface from the HeNB may be terminated at the HeNB GW, or a direct logical U-Plane connection between HeNB and S-GW may be used.

At present there is no support X2 connectivity of HeNBs.

The S1 interface is defined as the interface:

• Between the HeNB GW and the Core Network,
• Between the HeNB and the HeNB GW,
• Between the HeNB and the Core Network,
• Between the eNB and the Core Network.

The HeNB GW appears to the MME as an eNB. The HeNB GW appears to the HeNB as an MME. The S1 interface between the HeNB and the EPC is the same whether the HeNB is connected to the EPC via a HeNB GW or not.

The HeNB GW shall connect to the EPC in a way that inbound and outbound mobility to cells served by the HeNB GW shall not necessarily require inter MME handovers.

The functions supported by the HeNB shall be the same as those supported by an eNB (with the possible exception of NNSF - NAS Node Selection Function) and the procedures run between a HeNB and the EPC shall be the same as those between an eNB and the EPC.

The HeNB hosts the same functions as an eNB, with the following additional specifications in case of connection to the HeNB GW:

• Discovery of a suitable Serving HeNB GW
• A HeNB shall only connect to a single HeNB GW at one time, namely no S1 Flex function shall be used at the HeNB in case of connection to the HeNB GW.
• If the HeNB is connected to a HeNB GW, it will not simultaneously connect to another HeNB GW, or another MME.
• The TAC and PLMN ID used by the HeNB shall also be supported by the HeNB GW.
• When the HeNB connects to a HeNB GW, selection of an MME at UE attachment is hosted by the HeNB GW instead of the HeNB;
• HeNBs may be deployed without network planning. A HeNB may be moved from one geographical area to another and therefore it may need to connect to different HeNB GWs depending on its location.

The HeNB GW hosts the following functions:

• Relaying UE-associated S1 application part messages between the MME serving the UE and the HeNB serving the UE;
• Terminating non-UE associated S1 application part procedures towards the HeNB and towards the MME. Note that when a HeNB GW is deployed, non-UE associated procedures shall be run between HeNBs and the HeNB GW and between the HeNB GW and the MME.
• Optionally terminating S1-U interface with the HeNB and with the SGW.
• Supporting TAC and PLMN ID used by the HeNB

In addition the MME hosts the following functions:

• Access control for UEs that are members of Closed Subscriber Groups (CSG).

Mechanisms for filtering of paging messages, in order to avoid paging message distribution to HeNBs belonging to CSGs where the UE is not registered, is FFS.

Source: 3GPP TS 36.300 - E-UTRA and E-UTRAN Overall description; Stage 2 (Release 8)

HSPA+ to become more widely available in 2009

According to 3G Americas press release, 100 million new connections were added last year. On a worldwide basis, GSM totals 3.5 billion of the nearly 4 billion mobile subscriptions or 89% share of market at the end of December 2008. With 278 UMTS-HSPA networks in service in 121 countries, there are 290 million UMTS-HSPA subscriptions as of the end of 2008 compared to 186 million a year earlier—more than 100 million new 3G connections. UMTS-HSPA subscriptions are expected to more than double in 2009, according to Informa’s forecasts, and reach 455 million connections by the end of this year.

A survey last year by GSA showed that over 1000 HSPA devices have already been launched. Remember HSPA device could be HSDPA device only or HSDPA and HSUPA device. According to Dell'Oro group, Worldwide total mobile infrastructure market revenues grew 5% in 2008, driven by the nearly doubling and quadrupling of revenues of the WCDMA and WiMAX markets, respectively.

The focus is now moving towards HSPA+ (Release 7). HSPA+ is already becoming everyones favourite as it now has the potential to compete with LTE. The HSPA+ data rates will soon be able to rival that of LTE. No new spectrum will be required and enhancements will now allow multiple bands to be used at the same time thereby reducing the need to move to LTE for gaining higher data rates by use of higher bandwidth.

O2 Germany is planning to upgrade its network to HSPA+ by mid 2009. Vodafone also plans to upgrade its network to HSPA+ when more devices are available. Hong Kong operator CSLNWM is working with China's ZTE to upgrade their network to SDR based HSPA+ network that could easily be upgraded to LTE. Australia's Telstra has already announced at the Mobile World Congress in Barcelona that it is the first in the world to offer mobile broadband service with peak rates of 21 Mbps made possible through HSPA+ technology.

On the devices front Huawei has E182E HSPA+ slide USB stick supporting 21.6Mbps DL and 5.76Mbps in UL. Novatel surprisingly has the same specs for its MC996D modem. Qualcomm meanwhile has released a range of new HSPA+ capable chipsets. The MSM8260 supports 3GPP Release 7 HSPA+ for data rates of up to 28 Mbps. The MSM8660 adds support for 3GPP/3GPP2 multimode, and the MSM8270 adds support for Release 8 dual-carrier HSPA+ for even higher data rates of up to 42 Mbps. All three products offer full backward compatibility to previous generation networks and are pin-, software- and functionally-compatible.

Its just a matter of time before we will all be able to experience the HSPA+ speeds on our mobiles and mobile connected Laptops.

Dual-Cell HSPA in Release 8 and beyond

Some interesting developments are ongoing in the 3GPP standardisation from Release-8 onwards. You must be aware that the current bandwidth in UMTS/HSPA is 5 MHz. Since most of the operators generally won bigger chunk of spectrum of contiguous 5MHz band, they can actually combine these chunks to create a larger spectrum and hence increase data rates.

In Release 8 in downlink, it is possible to increase data rates using either a combination of MIMO and 64QAM or dual-cell HSDPA for operation on two 5MHz carriers with 64QAM, data rates reach up to 42Mbps.

In deployments where multiple downlink carriers are available, the new multicarrier operation offers an attractive way of increasing coverage for high bit rates. Rel-8 introduces dual-carrier operation in the downlink on adjacent carriers. This technique doubles the peak rate from 21Mbps to 42Mbps without the use of MIMO – it doubles the rate for users with typical bursty traffic; therefore, it also doubles the average user throughput, which translates into a substantial increase in cell capacity.

You may remember that I mentioned earlier that the operators are not too keen on going for MIMO for non-LTE technology. This is because they will have to upgrade their hardware and the antennas which could increase their cost significantly for a technology that is not going to be around for long.

Another thing to note before it becomes too confusing is that there are two terms for 'DC' being used right now. One of them is 'Dual Carrier' and other is 'Dual Cell'. In Release 8, the term being used is Dual-Cell for HSDPA which is also known as DC-HSDPA. The Technical specification to follow is 3GPP, TR 25.825 “Dual-Cell HSDPA operation” V1.0.0, May 2008.

The Dual-Cell assumes that both the 5MHz bands are contiguous. If they are not then the better term to refer for DC is Dual-Carrier.

A dual-carrier user can be scheduled in the primary serving cell as well as in a secondary serving cell over two parallel HS-DSCH transport channels. All non-HSDPA-related channels reside in the primary serving cell, and all physical layer procedures are essentially based on the primary serving cell. Either carrier can be configured to function as the primary serving cell for a particular user. As a consequence, the dual-carrier feature also facilitates an efficient load balancing between carriers in one sector. As with MIMO, the two transport channels perform hybrid automatic repeat request (HARQ) retransmissions, coding and modulation independently. A difference compared to MIMO is that the two transport blocks can be transmitted on their respective carriers using a different number of channelization codes. In terms of complexity, adding a dual-carrier receiver to UEs is roughly comparable to adding a MIMO receiver. Because the two 5MHz carriers are adjacent, they can be received using a single 10MHz radio receiver, which is already be available if the UE is LTE-capable.

Following the introduction in Release 8 of dual-carrier operation in the downlink, 3GPP is now discussing operation on multiple 5MHz carriers. Multiband operation of multiple carriers allows a single user to simultaneously aggregate and use the spectrum distributed over different bands. This gives operators greater fl exibility when using available spectrum. Increasing the number of carriers that UEs receive from two to four doubles the peak rate and achievable user throughput. For bursty traffic, this translates into substantially greater capacity, either as a larger number of users at a given data rate, or as a higher data rate for a given number of users. To substantially boost spectral effi ciency, 3GPP is studying the combination of dual-carrier operation and MIMO with 64QAM in the downlink, thereby doubling the peak data rate to 84Mbps. Similarly, they are studying the combination of MIMO, 64QAM and up to four downlink carriers to support peak data rates of more than 100Mbps. The support for UE reception on two frequency bands is an enabler to DC-HSDPA for operators who do not have adjacent 5MHz carriers available in one band, and is therefore of key importance for the further evolution of multi carrier HSPA.

As a consequence of increased data rates in downlink, the uplink data rates need to be improved too. From the aggregation of multiple FDD downlink carriers, the paired FDD uplink carriers can be utilized for improved uplink transmissions. 3GPP studies the usage of two adjacent 5MHz carriers for dual carrier uplink transmissions (DC-HSUPA) supporting data rates of up to 23Mbps. A further benefit of utilizing two uplink carriers is the possibility to support more efficient load balancing in the uplink direction.

In summary, uplink multicarrier operation increases availability as well as coverage of high data rates in the uplink.

In Conclusion, Rel-8 defines improvements in HSPA to achieve higher rates through dual carrier or combined 64QAM+MIMO operation. With the Rel-8 specification nearing completion (targeted for March 2009), planning is already under way in 3GPP for Rel-9 and Rel-10. Further multi-carrier and MIMO options are being explored for HSPA in Rel-9 and Rel-10

If you want to explore this topic further see:

• Nomor research White Paper – Dual Cell HSDPA and its Future Evolution.
• WirelessMoves - Dual Carrier HSDPA - The Push Beyond 5 MHz
• Ericsson - Continued HSPA Evolution of mobile broadband

LTE UE Modes of Operation

From 3GPP TS 24.301, section 4.3:

UE mode of operation

A UE attached for EPS services may operate in one of the following operation modes:

- PS mode of operation: the UE registers only to EPS services;

- CS/PS mode 1 of operation: the UE is CS fallback capable and configured to use CS fallback, and non-EPS services are preferred. The UE registers to both EPS and non-EPS services; and

- CS/PS mode 2 of operation: the UE is CS fallback capable and configured to use CS fallback, and EPS services are preferred. The UE registers to both EPS and non-EPS services.

3GPP Earthquake and Tsunami Warning service (ETWS)

Earthquake and Tsunami Warning Service: is a service that delivers Earthquake and Tsunami Warning Notifications provided by Warning Notification Providers to the UEs which have the capability of receiving Warning Notifications within Notification Areas through the 3GPP network.

Earthquake and Tsunami Warning System: is a subsystem of Public Warning System that delivers Warning Notifications specific to Earthquake and Tsunami provided by Warning Notification Providers to the UEs which have the capability of receiving Warning Notifications within Notification Areas through the 3GPP network.

Earthquake and Tsunami Warning service is provided to users by PLMN operators. Warning Notification Providers produce Warning Notification to PLMN operator when an event occurs e.g. an Earthquake. PLMN operators distribute Warning Notifications to users by utilizing ETWS.

The ETWS consists of the PLMN that is capable to deliver Warning Notification and the UEs that are capable to receive Warning Notification. A Warning Notification Provider is able to send Warning Notification to the users in Notification Area by activating ETWS. Warning Notification is classified into two types depending on the purpose and urgency of the notification.

The first type of Notification is called Primary Notification. This type of notification delivers the most important information of the threat that is approaching to users (e.g. the imminent occurrence of Earthquake or Tsunami). The notification shall be delivered to the users as soon as possible.

The second type of Notification is called Secondary Notification. This type of notification delivers additional information, such as instructions on what to do / where to get help as long as the emergency lasts.

More Information at 3GPP TS 22.168: Earthquake and Tsunami Warning System (ETWS) requirements; Stage 1.

You may also find interesting this FAQ for Cell Broadcast (CB) in Public Warning.

Femtocell 3GPP Specifications

Now with Release 8 frozen, if you are Femtocell follower then there are couple of specs that you can read:

3GPP TR 25.820 - 3G Home NodeB Study Item Technical Report: Contains study of items from RAN#2, RAN#3 and RAN#4 point of view.

3GPP TS TS 22.220 - Service Requirements for Home NodeBs and Home eNodeBs: It lists different requirements as the title suggests. You can see some more info on this at Martin's blog.

Over the next few months since the Femtocell race is heating up, you would find these documents being updated with lots of details and probably stage 2 and stage 3 documents detailing some implementation details, etc. Will keep you informed.

LTE functionality frozen as part of Release 8

According to 3GPP website: 3GPP has approved the functional freeze of LTE as part of Release 8.

There is significant commitment from operators to deploy this technology, and this landmark achievement will allow them to realize their early deployment plans.

But the 3GPP decided to give more time to the work on SAE -– a.k.a. evolved packet core (EPC) –- because the specs weren't complete enough. The standards body has drawn up a list of "exceptions" that will have until March 2009 to be finalized in order to be included in Release 8.

"There are a number of pieces of work which we thought should be included but weren't quite ready," says Scrase. "[There are] quite a number of parts for SAE, the work [on which] still lags behind LTE work. We have a high level of confidence that the items will be completed by March, otherwise we wouldn't have included them on the list."

Scrase says that it is common to extend deadlines in this way and that the 3GPP allowed a similar extension for Release 7.

The decisions about LTE and SAE took place at a 3GPP meeting in Athens last week, where the group definitively agreed on what is contained in Release 8 and what's not, according to Scrase. The group also agreed on what should be included in Release 9, which is scheduled to be frozen in December 2009.

And there is more to Release 8 than LTE and SAE. For example, some of the specifications for femtocells -- or "Home Node B" in 3GPP terminology -- are included in the release.

LTE Roll out updates from the 4th LTE World Summit in London

As I mentioned in an earlier post, I got the opportunity to attend and meet with the industry experts in the 4th LTE world summit. There were some very interesting discussions and debates and some announcements about the rollout of LTE. Here is a quick summary of the announcements and news. I am sure to have missed some and will expand on some of the topics in later posts.

Karri Mikkonen, Director, Corporate Strategy, TeliaSonera in his presentation said that TeliaSonera to be an early LTE adopter with rollout planned Mid 2010. They have already bought licenses in Sweden, Norway, Finland, Denmark, Baltics. According to them LTE enables very convenient mobile data usage scenarios, and is one tool to win battle in mobile data, among others.

Bill Huang, General Manager, China Mobile Research Institute gave a very interesting perspective on mobiles in China which I will expand in a later post. According to his presentation, China Mobile will be deploying TDD based LTE (TD-LTE) option probably around 400Mhz spectrum. Trails will start by Mid 2009 and pre-commercial launch will happen around end of 2009. By Q2, 2010 there will be large scale commercial trials involving around 15,000 base stations.

Remi Thomas, Director of NGMN project and head of Network Strategy, France Telecom, France said FT plans to introduce HSPA+ and opt for 'wait and see' approach for LTE. The earliest they want to even think about LTE is after 2010 and if practical the rollout may occur in 2012. Even with HSPA+ they will opt for all the software changes only and not go for any hardware changes. So we wont see MIMO anytime soon with HSPA+ according to them. They also have plans to rollout LTE Femtocells when available to check the technology and iron out the problems with LTE technology.

Erik Ekudden, Vice President, Group Function Technology, Ericsson, Sweden in his presentation said that E\\\ will be commercially releasing equipment in 2009. Terminal HW including support FDD and TDD modeof LTE. For FDD, initial support will be for IMT core band of 2.1GHz and also IMT extension band of 2.6GHz and US 700MHz spectrum. For TDD the initial support will be for IMT extension center gap in 2.6GHz spectrum and 2.3 TDD band in 2.3GHz band.

In a question answer session, Dr Howard Benn, Director of Cellular Standards, Motorola Mobile Devices mentioned that Motorola already has a working LTE UE but not in Form factor (probably development board). He did not expand on the details.

Nick (Norikazu) Yamasaki, Manager Standards Strategy section, Emerging Technologies and Spectrum Division, KDDI Corp. in his presentation said that KDDI is a CDMA2000 operator but since with UMB nearly dead (my words) they have decided to eveolve to LTE. LTE deployment willbe started around 2012 but will co-exist with the CDMA 2000 network which they will support for another 10 years. Right now they have EV-DO Rev.A but they may also opt for Rev.B

One of the big problems that was discussed many times in the conference was that Release 8 LTE standards have no solution for the normal CS voice call. There are some hacks around it but voice part will only be solved in time for Release 9. This could delay decisions by some operators to roll out LTE networks untill after Release 9. I will write a post on this later.

LTE, IMS and Voice calls!

Picked this up from Martin's Blog. One of the things that has been left undefined are the end user applications. Unlike GSM and 3G+ where AMR RAB's has been defined for CS voice calls, there is no provision in LTE. In fact we know that CS domain is completely absent and only IP based PS domain is present. It has been assumed that IMS will be de-facto present along with LTE and the architecture rightly defines so but there is nothing stopping LTE being deployed without IMS. The following is from Martin's Blog:

LTE requires the IP Multimedia Subsystem (IMS) for voice calls. So what will happen to LTE if IMS doesn't take off? I know, many in the industry believe even asking such a question is close to heresy but who can promisse today that IMS will be a success?

The trouble with IMS and to some extent with mobile VoIP is not that it's a young technology, standardization has been going on for many years and books about it are going into their third edition. However, there are still no IMS systems out there today that have come out of the trial phase, and I have yet to see a mobile device with an IMS client which is nicely integrated and simply works. Also, the IMS standard is getting more complicated by the day which doesn't make life easier. Another main issue with VoIP and consequently IMS is power consumption. I use VoIP over Wifi a lot on my Nokia N95 and can nicely observe how the phone slightly heats up during a long phone call. Also the non-IMS but SIP compliant Nokia VoIP client in the phone, which by the way is nicely integrated, sends keep alive messages to the SIP server in the network several times a minute. This is necessary mainly due to Network Address Translation (NAT). While this doesn't require a lot of power over Wifi, power consumption skyrockets as soon as I configure VoIP for use over 3G. I can almost watch the power level of the battery drop as the network now constantly keeps a communication channel open to the device. So there are two problems here: VoIP calls cause a much higher processor load during a call, i.e. the VoIP talk time is much shorter than the 2G or 3G talk time and the standby time is significantly reduced. Add to that the missing handover capability to 2G and 3G networks (yes, I know there is VCC in theory) and you have a prefect package for a very bad user experience.

So the big question is if all of these things can be fixed, say over the next 5 years!? I have my doubts... If not, then LTE has a big problem. Will network operators accept running GSM or HSPA alongside LTE until the problems are fixed? The choice is this and accepting that LTE is for Internet access and some niche VoIP applications on devices such as notebooks or to decide sticking to HSPA(+) until things are fixed.

In case LTE is deployed and LTE - IMS devices are not ready it's likely that a device can't be attached to several radio networks simultaneously. So how do you inform a device attached to LTE about an incoming voice call? It looks like the people in standards bodies are looking at different solutions:

• Send a paging message for an incoming circuit switched voice call via LTE to the device. You can do this on the IP layer or on the radio network signalling layer. The device them switches radio technologies and accepts the call.
• Some people have started thinking about extending LTE with a circuit switching emulation.

This could be handled on the lower layers of the protocol stack and the software on top would not notice if the call uses GSM, UMTS or LTE. This one is easier said than done because I don't think this concept will fly without a seamless handover to a 2G or 3G network. If such a solution ever gets into mobile phones, it would make life for IMS even harder. Who would need it then?

Are there any other initiatives I have missed so far to fix the LTE voice issue?

Dean Bubley in his Disruptive Wireless Blog has interesting analysis on this topic as well:

My view is that operators should either work with Skype, Truphone, fring et al – or compete head-to-head with them using their own pre-standard mobile VoIP implementations. I still believe this is a good route to VoIPo3G, especially for operators that are already moving to VoIP in their fixed networks, or which are early deployers of IMS or other IP-NGN architectures. Blocking VoIP it not a viable option in competitive markets - as evidenced by the increasing trend towards openness that's been seen in recent weeks.

But interestingly, another ‘flavour’ of mobile VoIPo3G is now emerging as an alternative for mobile operators – Circuit Switched Voice over HSPA, as an early specification within 3GPP’s Release 8 generation of standards. This was just starting to evolve seriously when I published the report in November, and is mentioned in the comments on this post of mine. And it now seems to be moving fast. In the last week, two of the largest ‘'movers and shakers' in mobile technology - from both handset and network sides - have talked up this approach to me unprompted. And I’m in agreement that it’s undoubtedly going to be important.

Basically, CS voice over HSPA takes the ordinary mobile circuit voice service, using ordinary diallers on the phone, and circuit core switches in the network... and tunnels it over an underlying IP bearer. So the application isn't VoIP, but ordinary circuit telephony, but the wireless transport (down in the guts of the phone) is IP.

In other words, it's "Mobile Circuit Telephony over IP"

In fact, we've all heard this concept before. It is an almost direct HSPA equivalent of UMA’s voice over WiFi. In both cases, there are benefits for operator voice calls, derived from the nature of the radio IP bearer: cost in WiFi’s case as it’s unlicenced spectrum, and the efficiencies of new packet transmission techniques in HSUPA and beyond. And in both cases, it’s not necessary for the operator to have already deployed IMS, VCC and so forth – they can reuse their existing core networks, and get away with less messing-around at the handset application layer. [I’m not sure yet whether the IP tunnel uses a similar IPsec approach to UMA, and could use a similar gateway, or if it’s entirely new]. The downside is that this isn’t a next-gen IP voice service in terms of application capability – it’s voice 1.0 transported over network 3.5.

There are also various reasons why I'm more positive on CS over HSPA than I am about WiFi-UMA.

It's a matter of semantics whether you treat CS Voice over HSPA and UMA as 'true' wireless VoIP. Both are using classic circuit signalling, rather than SIP or proprietary protocols like Skype. Neither are as easy to use as "full VoIP" as the basis of innovative applications like voice mashups.

The interesting thing to me is that the industry is starting to polarise into different points of view on this issue. Ericsson remains a staunch MMTel advocate, driven by its desire to push IMS as the main future application layer. But other major players seem to be edging towards a CS over HS worldview, albeit with a hedge around naked-SIP VoIP.

So… taken together, the various types of VoIPo3G are going to be:

• Over-the-top independent VoIP (Skype, Truphone, IP-PBX etc) with a dedicated client on the handset or PC
• CS voice over HSPA, using the ordinary circuit voice app plus some lower-level IP ‘plumbing’.
• IMS MMTel – needing a full IMS client on the device
• Other IMS or standards-based voice apps like PoC or perhaps a standalone SIP VoIP server plugged into the IMS application layer
• Standalone operator softswitch-based VoIP connecting to a (probably) SIP client on the handset.
• Partnerships or mashups of the above.

Messy and diverse, in other words. And all of these have different use cases, different pro’s and con’s, different requirements in terms of user behaviour, cost and so on.

But the bottom line is that with the addition of CS Voice over HSPA, my top-level VoIPo3G predictions are still looking feasible, although some of the fancier web- or application-based VoIP capabilities will be trickier to exploit by the operators choosing that approach.

I have to admit that I havent looked into this area at all and cannot comment on which direction things will move. One thing that I can definitely say from my experience is that the initial movers, if successful, will set the direction for others to follow and may be eventual winners.