Temporary Identities in LTE/SAE - 2: RNTI's

Last year I covered some information on temporary identities but never got a chance to continue on it. Here is one on RNTI's

RNTI or Radio Network Temporary Identifier(s) are used primarily by eNB Physical Layer for scrambling the coded bits in each of the code words to be transmitted on the physical channel. This scrambling process in PHY happens before modulation. There is a sequence followed for scrambling, calculation of which depends on the RNTI(UE specific for channels like PDSCH,PUSCH) and cell specific (for broadcast channels like PBCH). Details could be found in [2].

The following table lists different kinds of RNTI's:

Lets look at some of these in slightly more detail:

P-RNTI (Paging RNTI): To receive paging messages from E-UTRAN, UEs in idle mode monitor the PDCCH channel for P-RNTI value used to indicate paging. If the terminal detects a group identity used for paging (the P-RNTI) when it wakes up, it will process the corresponding downlink paging message transmitted on the PCH.

SI-RNTI (System Information RNTI): The presence of system information on DL-SCH in a subframe is indicated by the transmission of a corresponding PDCCH marked with a special System Information RNTI (SI-RNTI). Similar to the PDCCH providing the scheduling assignment for ‘ normal ’ DL-SCH transmission, this PDCCH also indicates the transport format and physical resource (set of resource blocks) used for the system-information transmission.

M-RNTI (MBMS RNTI): Used in Rel-9 for MCCH Information change notification.

RA-RNTI (Random Access RNTI): The RA-RNTI is used on the PDCCH when Random Access Response (RAR) messages are transmitted. It unambiguously identifies which time-frequency resource was utilized by the UE to transmit the Random Access preamble. If multiple UEs had collided by selecting the same signature in the same preamble time-frequency resource, they would each receive the RAR.

C-RNTI (Cell RNTI): The C-RNTI to be used by a given UE while it is in a particular cell. C-RNTI allocation and details are too complex to explain in the blog so please refer to Nomor newsletter here.

TC-RNTI: When the UE does not have allocated C-RNTI then Temporaru C-RNTI is used. A temporary identity, the TC-RNTI, used for further communication between the terminal and the network. If the communication is successful then TC-RNTI is promoted eventually to C-RNTI in the case of UE not having a C-RNTI.

SPS-C-RNTI (Semi-Persistent Scheduling C-RNTI): For the configuration or reconfiguration of a persistent schedule, RRC signalling indicates the resource allocation interval at which the radio resources are periodically assigned. Specific transmission resource allocations in the frequency domain, and transmission attributes such as the modulation and coding scheme, are signalled using the PDCCH. The actual transmission timing of the PDCCH messages is used as the reference timing to which the resource allocation interval applies. When the PDCCH is used to configure or reconfigure a persistent schedule, it is necessary to distinguish the scheduling messages which apply to a persistent schedule from those used for dynamic scheduling. For this purpose, a special identity is used, known as the Semi-Persistent Scheduling C-RNTI (SPS-C-RNTI), which for each UE is different from C-RNTI used for dynamic scheduling messages. - Source: LTE, The UMTS Long Term Evolution: From Theory to Practice By Stefania Sesia, Issam Toufik, Matthew Baker

TPC-PUCCH-RNTI (Transmit Power Control-Physical Uplink Control Channel-RNTI) and TPC-PUSCH-RNTI (Transmit Power Control-Physical Uplink Shared Channel-RNTI): The power-control message is directed to a group of terminals using an RNTI specific for that group. Each terminal can be allocated two power-control RNTIs, one for PUCCH power control and the other for PUSCH power control. Although the power control RNTIs are common to a group of terminals, each terminal is informed through RRC signaling which bit(s) in the DCI message it should follow.

The following table lists the values that are assigned to different RNTI's in MAC:



[1] 3GPP TS 36.321 - Evolved Universal Terrestrial Radio Access (E-UTRA) Medium Access Control (MAC) protocol specification
[2] 3GPP TS 36.211 - Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Channels and Modulation

Takehiro Nakamura on LTE Radio Aspects

In summary:

Release 8 - Minor change requests to it based on March 2009 freeze;
Release 9 - an enhanced version of Release 8 and additional features;
Release 10 (LTE-Advanced) - proposed as an IMT-Advanced and is expected to be approved by December 2010; major differences between LTE and LTE-Advanced

Via: LTE Portal

Technologies and Standards for TD-SCDMA Evolutions to IMT-Advanced

Picture Source: http://www.itu.int/dms_pub/itu-t/oth/21/05/T21050000010003PDFE.pdf

This is a summary of a paper from IEEE Communications Magazine, Dec 2009 issue titled "Technologies and Standards for TD-SCDMA Evolutions to IMT-Advanced" by Mugen Peng and Wenbo Wang of Beijing University of Posts and Telecommunications with my own comments and understanding.

As I have blogged about in the past that China Mobile has launched TD-SCDMA network in China and the main focus to to iron out the basic problems before moving onto the evolved TD-SCDMA network. Couple of device manufacturers have already started working on the TD-HSPA devices. Couple of months back, 3G Americas published a whitepaper giving overview and emphasising the advantages of TDD flavour of LTE as compared to FDD. The next milestone is the IMT-Advanced that is under discussion at the moment and China has already proposed TD-LTE-Advanced which would be compatible with the TD-SCDMA technology.

For anyone who does not know the difference between TDD, FDD and TD-SCDMA please see this blog.

The TD-SCDMA technology has been standardised quite a while back but the rollout has been slow. The commercial TD-SCDMA network was rolled out in 2009 and more and more device manufacturers are getting interested in the technology. This could be due to the fact that China Mobile has a customer base of over 500 million subscribers. As of July 2009 over 100 device manufacturers were working on TD-SCDMA technology.

The big problem with TD-SCDMA (as in the case of R99 3G) is that the practical data rate is 350kbps max. This can definitely not provide a broadband experience. To increase the data rates there are two different approaches. First is the Short Term Evolution (STE) and the other is Long Term Evolution (LTE).

The first phase of evolution as can be seen in the picture above is the TD-STE. This consists of single carrier and multi-carrier TD-HSDPA/TD-HSUPA (TD-HSPA), TD-MBMS and TD-HSPA+.

The LTE part is known as TD-LTE. There is a definite evolution path specified from TD-SCDMA to TD-LTE and hence TD-LTE is widely supported by the TD-SCDMA technology device manufacturers and operators. The target of TD-LTE is to enhance the capabilities of coverage, service provision, and mobility support of TD-SCDMA. To save investment and make full use of the network infrastructure available, the design of TD-LTE takes into account the features of TD-SCDMA, and keeps TD-LTE backward compatible with TD-SCDMA and TD-STE systems to ensure smooth migration.

The final phase of evolution is the 4G technology or IMT-Advanced and the TD-SCDMA candidate for TD-LTE+ is TD-LTE-Advanced. Some mature techniques related to the TD-SCDMA characteristics, such as beamforming (BF), dynamic channel allocation, and uplink synchronization, will be creatively incorporated in the TD-LTE+ system.

Some academic proposals were also made like the one available here on the future evolution of TD-SCDMA but they lacked the industry requirements and are just useful for theoretical research.

The standards of TD-SCDMA and its evolution systems are supervised by 3GPP in Europe and by CCSA (Chinese Cellular Standards Association) in China. In March 2001 3GPP fulfilled TD-SCDMA low chip rate (LCR) standardization in Release 4 (R4). The improved R4 and Release 5 (R5) specifications have added some promising functions including HSDPA, synchronization procedures, terminal location (angle of arrival [AOA]-aided location), and so on.

When the industry standardizations supervised by CCSA are focusing on the integration of R4 and R5, the N-frequency TD-SCDMA and the extension of HSDPA from single- to multicarrier are presented. Meanwhile, some networking techniques, such as N-frequency, polarized smart antenna, and a new networking configuration with baseband unit plus remote radio unit (BBU+RRU), are present in the commercial application of TD-SCDMA.

TD-SCDMA STE

For the first evolution phase of TD-SCDMA, three alternative solutions are considered. The first one is compatible with WCDMA STE, which is based on HSDPA/HSUPA technology. The second is to provide MBMS service via the compatible multicast broadcast single-frequency network (MBSFN) technique or the new union time-slot network (UTN) technique. The last is HSPA+ to achieve similar performance as LTE.

On a single carrier, TD-HSDPA can reach a peak rate of 2.8 Mb/s for each carrier when the

ratio of upstream and downstream time slots is 1:5. The theoretical peak transmission rate of a three-carrier HSDPA system with 16-quadrature amplitude modulation (QAM) is up to 8.4 Mb/s.

Single-carrier TD-HSUPA can achieve different throughput rates if the configurations and parameters are varied, including the number of occupied time slots, the modulation, and the transport block size in bytes. Considering the complexity of a terminal with several carriers in TD-HSUPA, multicarrier is configured in the Node B, while only one carrier is employed in the terminal.

In Rel-7 based TD-HSPA+, In order to match the performance of orthogonal frequency-division multiple access (OFDMA)-based TD-LTE systems, some advanced techniques are utilized, such as multiple-input multiple-output (MIMO), polarized BF, higher modulation and coding schemes (64-QAM is available), adaptive fast scheduling, multicarrier techniques, and so on. Theoretically, 64-QAM can improve performance by a factor of 1.5 compared to the current 16-QAM; for single-carrier the peak rate reaches 4.2 Mb/s, and three-carrier up to 12.6 Mb/s.

For the MIMO technique, double transmit antenna array (D-TxAA), based on the pre-coding method at the transmitter, has been employed in frequency-division duplex (FDD)-HSPA+ systems, while selective per antenna rate control (S-PARC), motivated by the Shannon capacity limit for an open loop MIMO link, has been applied in TD-HSPA+ systems.

TD-SCDMA LTE

The TD-SCDMA LTE program was kicked off in November 2004, and the LTE demand report was approved in June 2005. The LTE specified for TD_SCDMA evolution is named TD-LTE.

LTE systems are supposed to work in both FDD and TDD modes. LTE TDD and FDD modes have been greatly harmonized in the sense that both modes share the same underlying framework, including radio access schemes OFDMA in downlink and SC-FDMA in uplink, basic subframe formats, configuration protocols, and so on.

TD-LTE trials have already started last year with some positive results.

TD-SCDMA LTE+

IMT-Advanced can be regarded as a B3G/4G standard, and the current TD-SCDMA standard migrating to IMT-Advanced can be regarded as a thorough revolution. TD-LTE advanced (TD-LTE+) is a good match with the TD-SCDMA revolution to IMT-Advanced.

It is predicted that the future TD-SCDMA revolution technology will support data rates up to approximately 100 Mb/s for high mobility and up to approximately 1 Gb/s for low mobility such as nomadic/local wireless access.

Recently, some advanced techniques have been presented for TD-LTE+ in China, ranging from the system architecture to the radio processing techniques, such as multi-user (MU)-BF, wireless relaying, and carrier aggregation (CA).

For MU-BF see the paper proposed by Huawei, CHina Mobile and CATT here (http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_55b/Docs/R1-090133.zip).

For Wireless Relaying see the ZTE paper here (http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_56b/Docs/R1-091423.zip).

To achieve higher performance and target peak data rates, LTE+ systems should support bandwidth greater than 20 MHz (e.g., up to 100 MHz). Consequently, the requirements for TD-LTE+ include support for larger transmission bandwidths than in TD-LTE. Moreover, there should be backward compatibility so that a TD-LTE user can work in TD-LTE+ networks. CA is a concept that can provide bandwidth scalability while maintaining backward compatibility with TD-LTE through any of the constituent carriers, where multiple component carriers are aggregated to the desired TD-LTE+ system bandwidth. A TD-LTE R8 terminal can receive one of these component carriers, while an TD-LTE+ terminal can simultaneously access multiple component carriers. Compared to other approaches, CA does not require extensive changes to the TD-LTE physical layer structure and simplifies reuse of existing implementations. For more on Carrier Aggregation see CATT, LGE and Motorola paper here (http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_56b/Docs/R1-091655.zip).

Finally, there are some interesting developments happening in the TD-SCDMA market with bigger players getting interested. Once a critical mass is reached in the number of subscribers as well as the manufacturers I wouldnt be surprised if this technology is exported beyond the Chinese borders. With clear and defined evolution path this could be a win-win situation for everyone.

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.