Monday, 22 November 2010

Carrier aggregation deployment scenarios for Release-10 LTE-A

One of the important aspects to consider is that carrier aggregation should allow aggregation of not only the existing bands, but also bands that are introduced in future, e.g., 3.5 GHz band, etc. While existing bands already have certain deployments, new deployments can be considered for new bands that are introduced. Since introduction of new bands is done in a release independent fashion, considerations for such future bands are essential already in Rel-10. When higher frequencies such as 3.5 GHz are considered, path loss can be significant (e.g., 4-10 dB difference in link budget) when compared to 2 GHz. Hence, the most efficient deployment may not be to stick with the traditional macro-overlaying approach. Carrier aggregation should allow more flexible use of such new bands, since coverage and mobility can be ascertained by the existing band deployments, e.g., 2 GHz.

Picture below shows some of the potential deployment scenarios for carrier aggregation. Note that the scenarios listed are non-exhaustive. For example, other scenarios using repeaters and femto cells may be considered. Also note that F2 > F1.




Scenario 1
* F1 and F2 cells are co-located and overlaid, providing nearly the same coverage
* Both layers provide sufficient coverage and mobility can be supported on both layers.
* Likely scenario when F1 and F2 are of the same band, e.g., 2 GHz, 800 MHz, etc.
* It is expected that aggregation is possible between overlaid F1 and F2 cells.

Scenario 2
* F1 and F2 cells are co-located and overlaid, but F2 has smaller coverage due to larger path loss
* Only F1 provides sufficient coverage and F2 is used to provide throughput. Mobility is performed based on F1 coverage.
* Likely scenario when F1 and F2 are of different bands, e.g., F1 = {800 MHz, 2 GHz} and F2 = {3.5 GHz}, etc.
* It is expected that aggregation is possible between overlaid F1 and F2 cells.

Scenario 3
* F1 and F2 cells are co-located but F2 antennas are directed to the cell boundaries of F1 so that cell edge throughput is increased
* F1 provides sufficient coverage but F2 potentially has holes, e.g., due to larger path loss. Mobility is based on F1 coverage.
* Likely scenario when F1 and F2 are of different bands, e.g., F1 = {800 MHz, 2 GHz} and F2 = {3.5 GHz}, etc.
* It is expected that F1 and F2 cells of the same eNB can be aggregated where coverage overlap.

Scenario 4
* F1 provides macro coverage and on F2 Remote Radio Heads (RRHs) are used to provide throughput at hot spots
* Mobility is performed based on F1 coverage.
* Likely scenario when F1 and F2 are of different bands, e.g., F1 = {800 MHz, 2 GHz} and F2 = {3.5 GHz}, etc.
* It is expected that F2 RRE cells can be aggregated with the underlying F1 macro cells.

Scenario 5
* Similar to scenario #2, but frequency selective repeaters are deployed so that coverage is extended for one of the carrier frequencies

Scenarios supported in Rel-10 time frame
* For DL, all scenarios are supported in Rel-10
* For UL, scenario 4 and 5 are not supported in Rel-10

Source: R2-100531 CA deployment scenario NTT DOCOMO

Friday, 19 November 2010

CA (Carrier Aggregation) Scenarios in LTE-Advanced

CA (Carrier Aggregation) may be used in three different spectrum scenarios as follows.

Intraband Contiguous CA — This is where a contiguous bandwidth wider than 20 MHz is used for CA. Although this may be a less likely scenario given frequency allocations today, it can be common when new spectrum bands like 3.5 GHz are allocated in the future in various parts of the world. The spacing between center frequencies of contiguously aggregated CCs (Component Carriers) is a multiple of 300 kHz to be compatible with the 100 kHz frequency raster of Release 8/9 and preserving orthogonality of the subcarriers with 15 kHz spacing.

Intraband Non-Contiguous CA — This is where multiple CCs belonging to the same band are used in a non-contiguous manner. This scenario can be expected in countries where spectrum allocation is non-contiguous within a single band, when the middle carriers are loaded with other users, or when network sharing is considered.

Interband Non-Contiguous CA — This is where multiple CCs belonging to different bands (e.g., 2 GHz and 800 MHz are aggregated). With this type of aggregation, mobility robustness can potentially be improved by exploiting different radio propagation characteristics of different bands. This form of CA may also require additional complexity in the radio frequency (RF) front-end of UE. In LTE Release 10, for the UL the focus is on intraband CA, due to difficulties in defining RF requirements for simultaneous transmission on multiple CCs with large frequency separation, considering realistic device linearity. For the DL, however, both intra and interband cases are considered in Release 10, while specific RF requirements are being developed.

Text Source: Carrier Aggregation Framework in 3GPP LTE-Advanced - Mikio Iwamura et al. in IEEE Communications Magazine August 2010

Picture Source: http://www.catr.cn/tecm/dxwjs/201006/t20100610_1143968.htm

Monday, 15 November 2010

HTML5 for Mobile Devices

I had been recently talking to some developers about the programming and App development on mobiles and quite a few people are of the opinion that HTML5 may help the mobile Apps go to the next level.

The biggest problem HTML5 is supposed to solve is write once run anywhere applicatons. Most of the programs will have the same look and feel if they are run on a PC or mobile and between different devices.

Ofcourse not everything is perfect. There are yet many API's that need to be implemented in for HTML5 like the 3D and Mic API's, etc. Another problem is that a lot of phones are not yet supporting HTML5 and some of them that are supporting, not supporting it completely. This will have to be solved asap.

The following is a recent presentation from Ericsson on HTML5 that gives a good idea on why it is a good idea.
Another interesting place to look for some HTML5 stuff is Patrick Chanezon's html5 Bookmarks

Thursday, 11 November 2010

UEInformationRequest/UEInformationResponse - New RRC messages in Release-9

As is obvious from the title, The UE information procedure is used by E-UTRAN to request the UE to report information [1].

There are two different scenarios for the Network to send the UEInformationRequest message to the UE. One is to find out the number of RACH preambles it needed for the random access procedure and the other is to get the measurement information when a Radio Link Failure (RLF) occurred.

[2] also provides the following detail:

The network may poll for the UE report after a successful random access procedure (UEInformationRequest) and the UE responds with the number of preambles sent by MAC for the last successfully completed random access procedure and whether contention is detected by MAC for at least one of the transmitted preambles for the last successfully completed random access procedure (UEInformationResponse).

Source:

[1] 3GPP TS 36.331 V9.3.0: Radio Resource Control (RRC); Protocol specification - Section 5.6.5

[2] 3GPP TR 36.902 V9.2.0: Self-configuring and self-optimizing network (SON) use cases and solutions

Wednesday, 10 November 2010

Proximity Indication - New RRC Uplink Message in Rel-9

The inbound handover from a Macro eNB to an HeNB (a.k.a. Femtocell) is not supported in Release 8. Before making a handover decision to a HeNB, the Macro eNB needs to acquire UE measurement information related to the so-called target CSG cell. Nevertheless, UEs cannot continuously make measurements and read the system information of lots of CSG cells in cases of large scale HeNB deployments.

In order to allow the UE to make those measurements efficiently, a newly defined proximity report can be configured within the RRC Reconfiguration message. This proximity report will allow the UE to send a so-called “proximity indication” to the source eNB in the uplink whenever it is entering or leaving the proximity of one or more cells with CSG IDs that the UEs has in its CSG Whitelist.

A UE that is able to determine that it is near its CSG cell can thus inform the network to take the necessary actions for handover preparation. The detection of proximity is based on an autonomous search function.

The source eNB, upon receiving the proximity indication, might ask the UE to perform measurements of the CSG cell, to read the System Information (SI) or, in case it already has all required information, it might already start the handover procedure. PCI (Physical Cell Identification) confusion is resolved in Release 9. The eNB will ask the UE to report the global cell identity. As usual the UE reporting is using the RRC measurement procedures. The ovell procedure is illustrated in Figure below.

In summary five basic steps can be identified:
1. Proximity configuration/reporting
2. HO measurement configuration/reporting
3. Resolution of PCI confusion by requesting and reporting System Information
4. Access Control in the network
5. HO execution

Since the CSG search can be very slow there are no strict requirements on the inbound handover performance, which can range from one to several 10’s of seconds.

Since the proximity information is based on UE signaling, the network might be receiving a lot of proximity indications, increasing the network load. Therefore, it was agreed to limit proximity indications a UE can send within a certain time frame. A timer, called the prohibit proximity timer, was introduced.

Source: