Showing posts with label Release 9. Show all posts
Showing posts with label Release 9. Show all posts

Wednesday 7 October 2009

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.


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 ( 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 ( 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).


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”


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.


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).


[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 -(
[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.

Friday 7 August 2009

Multi-Standards Radio Base Station (MSR-BS) in 3GPP Release 9

I wrote about Future Mobile Terminals earlier which will probably be Multiservice, Multinetwork and Multimode. A similar approach would be needed for the network side. 3GPP is working on Release-9 feature of Multi-Standard Radio (MSR-BS). The 3GPP Spec 37.900 is not yet available but a draft should be available soon.

Research and Markets have already released a report arguing about the benefits of MSR-BS. Last year Ericsson released the RBS 6000 series products that has MSR support. Huawei and Nokia Siemens Networks are also working on similar products under different guises. Martin has blogged about this topic as well earlier in case you want to refer to.

According to Research and Markets report the terms used for this technology is Multi-Standard Radio Base Station (MSR-BTS/MSR-BS), Multi-Mode Radio Base Station (MMR-BTS/MMR-BS) and Multi-Radio Access Technology (Multi-RAT). The name in standards usually is MSR-BS.

So what is MSR-BS? The 3GPP definition is: Base Station characterized by the ability of its receiver and transmitter to process two or more carriers in common active RF components simultaneously in a declared RF bandwidth, where at least one carrier is of a different RAT than the other carrier(s).

In very simple terms, a single Base Station will be able to simultaneously transmit different radio access technologies from a single unit. So a unit may be for example transmitting GSM, WCDMA 2100 and LTE 2600 simultaneously.

The number of technologies supported by a BTS will be an implementation choice. With technology maturing it wont be surprising to have upto 4-5 different technologies in a MSR-BS in the next five years.

The advantage the mobile operator will have will not only be monetary but there will be possibility of space saving. But as the old english proverb says, they will be "putting their eggs in a single basket". If one unit stops working then the coverage in the area goes down. There may not be an option to fallback on different technology.

The way this MSR-BS are implemented will be definitely based on Software Defined Radios (SDR). The advantage with SDR will be that in different parts there is a slight frequency variation for different technologies like GSM-850 is specific to USA whereas the rest of the world uses GSM-900. These small variations will easily be customisable with these MSR-BS and optimisations wont be too far off.

Different Band Categories have been defined for different scenarios. For example Band Category 1 involves deplyment where GSM wont be present. Only LTE and WCDMA is present there. Band Category 2 involves frequency bands where GSM, EDGE, WCDMA and LTE may be present. Band Category 3 is designed with TDD and TD-SCDMA in mind.

More information as and when available

Thursday 23 July 2009

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.

Monday 20 July 2009

eMBMS: evolved Multimedia Broadcast Multicast Control

I spent a lot of time working on MBMS but operators decided not to roll out the technology. It was killed in its infancy. Earlier I blogged that MBMS wont be present in Release 8 but now there is interest in some quarters about MBMS being present in Release 9.

As I have mentioned earlier, the main advantage of MBMS over other TV technologies is that no additional infrastructure is required, the same technology and spectrum is used as for the 3G/LTE case and user interaction is possible thereby involving participation.

At the moment, I was only able to see eMBMS information in 3GPP TS 36.300 but I am sure more is on way soon. Section 15 of 36.300 is dedicated to eMBMS information.

In E-UTRAN, MBMS can be provided with single frequency network mode of operation (MBSFN) only on a frequency layer shared with non-MBMS services (set of cells supporting both unicast and MBMS transmissions i.e. set of "Unicast/MBMS mixed cells").

MBMS reception is possible for UEs in RRC_CONNECTED or RRC_IDLE states. Whenever receiving MBMS services, a user shall be notified of an incoming call, and originating calls shall be possible. ROHC is not supported for MBMS.

So where does it fit in the overall architecture?

Multi-cell/multicast Coordination Entity (MCE): The MCE is a logical entity – this does not preclude the possibility that it may be part of another network element – whose functions are the allocation of the radio resources used by all eNBs in the MBSFN area for multi-cell MBMS transmissions using MBSFN operation. Besides allocation of the time/ frequency radio resources this also includes deciding the further details of the radio configuration e.g. the modulation and coding scheme. The MCE is involved in MBMS Session Control Signalling. The MCE does not perform UE - MCE signalling. When the MCE is part of another network element, an eNB is served by a single MCE.

E-MBMS Gateway (MBMS GW): The MBMS GW is a logical entity – this does not preclude the possibility that it may be part of another network element – that is present between the BMSC and eNBs whose principal functions is the sending/broadcasting of MBMS packets to each eNB transmitting the service. The MBMS GW uses IP Multicast as the means of forwarding MBMS user data to the eNB. The MBMS GW performs MBMS Session Control Signalling (Session start/stop) towards the E-UTRAN via MME.

“M3” Interface: MCE – MME: An Application Part is defined for this interface between MME and MCE. This application part allows for MBMS Session Control Signalling on E-RAB level (i.e. does not convey radio configuration data). The procedures comprise e.g. MBMS Session Start and Stop. SCTP is used as signalling transport i.e. Point-to-Point signalling is applied.

“M2” Interface: MCE – eNB: An Application Part is defined for this interface, which conveys at least radio configuration data for the multi-cell transmission mode eNBs and Session Control Signalling. SCTP is used as signalling transport i.e. Point-to-Point signalling is applied.

“M1” Interface: MBMS GW – eNB: This interface is a pure user plane interface. Consequently no Control Plane Application Part is defined for this interface. IP Multicast is used for point-to-multipoint delivery of user packets.

It is not precluded that M3 interface can be terminated in eNBs. In this case MCE is considered as being part of eNB. However, M2 should keep existing between the MCE and the corresponding eNBs. This is depicted in Figure above which depicts two envisaged deployment alternatives. In the scenario depicted on the left MCE is deployed in a separate node. In the scenario on the right MCE is part of the eNBs.

It will be possible to have an MBMS Dedicated cell or a MBMS/Unicast mixed cell. For transmission, it will be possible to have a Single-cell transmission or Multi-cell transmission. Multi-cell transmission where the safe information is sent synchronously over multiple cells will have an advantage of receivers being able to combine information from Multiple cells and also to roam in the area of transmission seamlessly.

More information when detailed specs are available.

Sunday 31 May 2009

CS Services over EPS study in Release 9

One of the Release-9 items is "Study on Circuit Switched (CS) domain services over evolved Packet Switched (EPS) access" which is described in 3GPP TR 23.879.

Martin Sauter has already done some analysis on this topic so I would advice anyone interested to read it on his blog here.

Wednesday 27 May 2009

Service Specific Access Control (SSAC) in 3GPP Release 9

In an emergency situation, like Earthquake or Tsunami, degradation of quality of service may be experienced. Degradation in service availability and performance can be accepted in such situations, but mechanisms are desirable to minimize such degradation and maximize the efficiency of the remaining resources.

When Domain Specific Access Control (DSAC) mechanism was introduced for UMTS, the original motivation was to enable PS service continuation during congestion in CS Nodes in the case of major disaster like an Earthquake or a Tsunami.

In fact, the use case of DSAC in real UMTS deployment situation has been to apply access control separately on different types of services, such as voice and other packet-switched services.

For example, people’s psychological behaviour is to make a voice call in emergency situations and it is not likely to change. Hence, a mechanism will be needed to separately restrict voice calls and other services.

As EPS is a PS-Domain only system, DSAC access control does not apply.

The SSAC Technical Report (see Reference) identifies specific features useful when the network is subjected to decreased capacity and functionality. Considering the characteristics of voice and non-voice calls in EPS, requirements of the SSAC could be to restrict the voice calls and non-voice calls separately.

For a normal paid service there are QoS requirements. The provider can choose to shut down the service if the requirements cannot be met. In an emergency situation the most important thing is to keep communication channels uninterrupted, therefore the provider should preferably allow for a best effort (degradation of) service in preference to shutting the service down. During an emergency situation there should be a possibility for the service provider also to grant services, give extended credit to subscribers with accounts running empty. Under some circumstances (e.g. the terrorist attack in London on the 7 of July in 2005), overload access control may be invoked giving access only to authorities or a predefined set of users. It is up to national authorities to define and implement such schemes.

Reference: 3GPP TR 22.986 - Study on Service Specific Access Control

Tuesday 26 May 2009

Public Warning System (PWS) in Release-9

Public Warning System (PWS) is generalization of Earthquake and Tsunami Warning System (ETWS). The requirements for PWS has been defined in 3GPP Release 9 in 3GPP TS 22.268. 3GPP TR 22.968 details the Study for requirements for a Public Warning System (PWS) service.

The following list gives the high level general requirements for Warning Notification delivery:

- PWS shall be able to broadcast Warning Notifications to multiple users simultaneously with no acknowledgement required.
- Warning Notifications shall be broadcast to a Notification Area which is based on the geographical information as specified by the Warning Notification Provider.
- PWS capable UEs (PWS-UE) in idle mode shall be capable of receiving broadcasted Warning Notifications.
- PWS shall only be required to broadcast Warning Notifications in languages as prescribed by regulatory requirements.
- Warning Notifications are processed by PWS on a first in, first out basis, subject to regulatory requirements.
- Reception and presentation of Warning Notifications to the user shall not pre-empt an active voice or data session.
- Warning Notifications shall be limited to those emergencies where life or property is at imminent risk, and some responsive action should be taken.

Commercial Mobile Alert System (CMAS) is Public Warning System (PWS) that delivers Warning Notifications provided by Warning Notification Providers to CMAS capable PWS-UEs. CMAS defines three different classes of Warning Notifications (Presidential, Imminent Threat and Child Abduction Emergency). The CMAS functionality does not require modifications to the 3GPP-defined cell broadcast functionality.

Monday 25 May 2009

3GPP Release-9 Features updated

From a presentation by Stephen Hayes in LTE World Summit:

•Services Alignment and Migration
•Registration in Densely-populated area (RED)
•End-User Identity
•Customized Ringing Signal
•Public Warning System
•Enhancements to Multimedia Priority Service
•Support of Personal Area Networks and Enhancements to Personal Network Management
•Multi-Media Telephony Service enhancements
•User Data Convergence
•Enhanced Home NodeB/ eNodeB
•Protection against Unsolicited Communication for IMS (PUCI)
•IMS Services Centralization and Continuity
•Enhancements of IMS Customized Alerting Tone (CAT) Service
•Service Specific Access Control in EPS
•Support for IMS Emergency Calls over GPRS and EPS
•LCS for LTE and EPS
•MBMS support in EPS
•Access Network Discovery and Selection Enhancements
•GTP-based S8 chaining
•Multiple PDN to the Same APN for PMIP-based Interfaces (Stage 2)
•Multi Access PDN Connectivity (Stage 2)
•Access Security Enhancements
•GBA Push enhancements
•IMS Media Plane Security (Stage 2)
•Timed Graphics•Managing MTSI Media Adaptation
•PSS and MBMS extensions
•Improved Video Support for PSS and MBMS
•IMS based PSS and MBMS User Service extensions
•Various OAM&P Improvements
•Value-Added Services for Short Message Service
•Definition of 3GPP UICC services over the new high-speed interface
•CS-IBCF and CS-TrGWdefinition in 3GPP specifications
•IMS –Interconnection Border Control Function (IBCF) –Transition Gateway (TrGW); Ix Interface; Stage 3
•IMS Application Level Gateway Control Function (ALGCF) –IMS Access Media Gateway (IMA-MGW); IqInterface; Stage 2 and Stage 3
•Rel-9 Improvements of the Radio Interface
•Rel-9 RAN improvements
•LTE improvements
•Self-Organizing Networks (SON)
•Voice services over Adaptive Multi-user channels on One Slot
•Local Call Local Switch
•Study on enhanced voice service requirements for the EPS
•Study on advanced requirements for IP interconnect
•Study on Service Specific Access Control in EPS
•Study on Unauthenticated PS Emergency Calls
•Study on Personal Broadcast Service
•Study on LCS support in SAE for non-3GPP accesses
•Study on CS Domain Services over EPS access
•Study on Extended Support of IMS Emergency Calls
•Study on System enhancements for the use of IMS services in local breakout and optimal routing of media
•Study on Intra Domain Connection of RAN Nodes to Multiple CN Nodes
•Study on IMS Evolution
•Study on enhancements to IMS border functions for IMS Interconnection of services
•Study on Multi Access PDN connectivity and IP flow Mobility
•Study on Service Continuity for Emergency Voice Calls
•Study on Protection against SMS and MMS spam
•Study on Remote management of USIM application on M2M Equipment
•Study on UTRAN key management enhancements
•Study on Surround Sound codec extension for PSS and MBMS
•Study on System Maintenance over Itf-N
•Study on Self-Organizing Networks (SON) related OAM interfaces for Home NodeB
•Study on Self-healing of Self-Organizing Networks (SON)
•Study on Service Oriented Architecture (SOA) for IRP
•Study on RcReference Point Functionalities and Message Flows
•Study on Telecommunication Management; Energy Savings Management(ESM)
•Study on Evaluation of the inclusion of Path Loss Based Technology in the UTRAN
•Study on LTE-Advanced
•Study on 1.28 McpsTDD Home NodeB
•Study on E-UTRAN Mobility Evaluation and Enhancement
•Study on Measurement of Radiated Performance for MIMO and multi-antenna reception for HSPA and LTE terminals
•Study on Minimization of drive-tests in Next Generation Networks
•Study on Enhanced Interference Management for HNBs

Friday 27 February 2009

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:

Friday 21 November 2008

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.