network sharing

Driver:

The operators are facing unprecedented challenges in particular during these recession days.

- decreased in voice revenues

- maintaining profit

The solution would naturally be on two aspects:

- generating new revenue by introducing new services, such as mobile broadband, mobile TV, SDP (iTunes, Nokia OVI store), etc

- cost reduction

RAN sharing is one solution leading to cost reduction, other options such as complete network outsourcing,

network O&M outsourcing are also worth considering, depends on operators' specific situation.

Solution:

Site sharing installs two or more operators' network equipments (mostly RAN) on the same site/tower. This is the simplest way, no much requirement to eNB (as eNB are still seperate). Backhaul traffic aggregation plays the most important role in cost saving in this case.

Real RAN sharing shares the same eNB with two or more operators. This requires some specific features within eNB to enable the sharing.

- multi- PLMN-id broadcast. The eNB can be configured to broadcast more than one set of PLMN-ids and more than one set of SIBs - as if two networks co-exist.

- VLAN. eNB needs to support VLAN so that each operator use one or more VLANs

- multiple IP address. The eNB should be addressed by different IP address on different operator's network

- resource allocation/balancing. The eNB should support configuration that its resource (HW, radio, etc) can be divided between the operators so that the system is not overwhelmed by a single operator's traffic.

- independent QoS management. However, the eNB should treat each operators traffic independently so that each operator has its own scheduling, RRM, QoS managment policy.

Architecture

Two types of RAN sharing architecture is defined.

- The first is called GWCN, where both GW and RAN are shared

- The second is called MOCN, where eNB connects to different MME/GW from each operator.

Most likely the second option will be more popular.

RSRP and RSRQ

The RSRP is comparable to the CPICH RSCP measurement in WCDMA. This

measurement of the signal strength of an LTE cell helps to rank between the different

cells as input for handover and cell reselection decisions. The RSRP is the average of

the power of all resource elements which carry cell-specific reference signals over the

entire bandwidth. It can therefore only be measured in the OFDM symbols carrying

reference symbols.

The RSRQ measurement provides additional information when RSRP is not sufficient

to make a reliable handover or cell reselection decision. RSRQ is the ratio between the

RSRP and the Received Signal Strength Indicator (RSSI), and depending on the

measurement bandwidth, means the number of resource blocks. RSSI is the total

received wideband power including all interference and thermal noise. As RSRQ

combines signal strength as well as interference level, this measurement value

provides additional help for mobility decisions.

How does CP removes ISI

We may all know that OFDM use CP to remove ISI. But how many of us know why and how? Below is a post on a BBS which is a typical question from who is new to OFDM/LTE.

"My question is assume the 2 maultipaths received at the receiver as below with CP prefixed to Symbols on both paths:

|--CP--|--symbol data--| ---> path 1
|-td-|--CP--|--symbol data--| ----> path 2 with delay td

|------------------| integration duration (Ts - symbol dur)
|-----| this is the part of the output still gets corrupted due to ISI, since CP is the part of the OFDM symbol it will be a non zero value.

So I am wondering how CP removes the ISI."

A very good answer can be found from book "LTE - The UMTS LONG TERM EVOLUTION, from theory to practice", chapter 5. Below is some excerpt with simplication to help easy understanding.

At a very high level, received signal through dispersive channel (frequency selective) can be represented below:
r(t) = x(t) * h(t) + z(t)
Assuming the channel delay is smaller than G, in a discrete way, the received signal is:
Rcp = A * h + Z

A =
xk[N-G] xk-1[N-1] xk-1[N-2] ... xk-1[N-G+1]
xk[N-G+1] xk[N-G] xk-1[N-1] ... xk-1[N-G+2]
. . . .
. . . .
. . . .
xk[N-2] xk[N-3] ... ... xk[N-G] xk-1[N-1]
xk[N-1] xk[N-2] ... ... xk[N-G+2] xk[N-G+1]
xk[0] xk[N-1] ... ... xk[N-G+2] xk[N-G+1]
. . . .
. . . .
. . . .
xk[N-1] xk[N-2] ... ... xk[N-G+1] xk[N-G]

Please note the red colored part is due to Inter-symbol interference. By discarding the first G samples of the received symbol, the inter-symbol interference can be easily discarded. And removed some part of intra-symbol interference as well (not very acturate here, but see below).
Only the blue part is not remained, we call it A'.

Now we extend A' to B. This doesn't change the output if adding a few zeros to the channel vertor h, which is now h'.

B =
xk[0] xk[N-1] ... ... xk[N-G+1] xk[N-G] ... xk[1]
xk[1] xk[0] ... ... xk[N-G+2] xk[N-G+1] ... xk[2]
. . . .
. . . .
. . . .
xk[N-1] xk[N-2] ... ... xk[N-G] xk[N-G-1] ... xk[0]

The beauty of matrix B (you must have realized!) is that it is circulant. It can be represented as B = FHXF

After Fourier transform, the output is
F(B*h') = F(FHXF*h) = F(FHXF) F(h) = X H

R = X H + Z

A convolution now transformed to multiply operation.

Getting back to the question posted at the begining of this article, the anwer to that question is:
- Inter symbol interference is easily discarded by insertion of CP at transmitter and removal of CP at receiver
- Intra symbol interference (which is actually the original question) is not removed BUT surpressed in a way where frequency selective channel is converted into a transmission over N parallel flat-fading channels in the frequency domain.

LTE Rel-10 : eICIC in detail

In my last post, some of the key techniques in LTE-A is summarized. Now I'd like to look into the detail of eICIC, which is currently a very active topic in 3GPP.

An index of latest eICIC studies within 3GPP can be found in R1-104238, which listed a set of references. In particular, I found the R1-103822 from NSN has a very good summary.

In general, there are two scenarios (except relay) need consideration:

A) Macro + Pico case

In this case, the UE is free to camp on a Macro or Pico cell which offers the best RSRP. It was concluded that co-channel deployment of macro + pico cases works without any explicit interference management mechanism. There is no need for introducing any new specifications (such as resources partitioning in time or frequency domain).

B) Macro + CSG Femto case

In this case, it is observed that so called macro-cell coverage holes can be experienced by macro-UEs being close to CSG HeNBs. This is because although the HeNB offers better signal quality, but UEs are not allowed to connect due to HeNB's close-access mode. This issue is primarily observed in the downlink. There are a few candidate solutions:

1. Apply power control for the HeNBs (reducing the Tx power for some HeNB)
2. Introducing resource partitioning between Macro eNBs and CSG HeNBs
3. Relaxing the CSG contraint, so Macro-UEs get temporily access to HeNB.

There are many variants for the 1st option. One simple example is to have HeNB measure its RSRP towards the strongest co-channel deployed macro-eNB, and reduce its Tx power accordingly. Others are more complex, may require signalling between different network elements.

For the 2nd option, i.e. resource partitioning, there are mainly two types. One is to partition the resources on frequency domain, e.g. certain carriers/sub-carriers are only reserved to Macro-eNB, the other is to partition the resources on time domain, for e.g. shift the HeNB's downlink frames by at least 3 OFDM symbols to avoid HeNB's CCH overlapping with MeNB's CCH. The time domain solution requires synchronization between Macro eNB and HeNB, which could be a challenge.

I am not sure if the 3rd option had been discussed in 3GPP (as I am not a 3GPP delegate).

by July 2010, the RAN WG1 #61bis meeting has concluded (which nothing concluded actually) on Macro-Femto case:

· Consider power control and time domain solution as baseline solutions

· Frequency domain solution is not precluded

LTA-Advanced related technologies

3GPP release 10 is to introduce some LTE-A features. LTE-A can archieve >1Gbps data rate by 4-by-4 MIMO, on ~70MHz system bandwidth.

The spectrum efficiency for LTE Rel-8 satisfies IMT-Advanced requirements in the downlink, however, in the uplink, SE needs to double to satisfy IMT-Advanced requirements.

LTE-A related Rel-10 work items:

• Carrier Aggregation (CA)
• Enhanced downlink multiple antenna transmission
• Uplink multiple antenna transmission
• Relay
• Enhanced ICIC for non-CA deployments of Heterogeneous networks (eICIC)

1) Carrier Aggregation (CA)
Entire system BW up to 100MHz, composed of component carriers
Each component carrier can be configured in a backward compatible way
Support both contiguous and non-contiguous spectrum


2) Enhanced downlink multiple antenna transmission
Up to 8 layers transmission, increased from 4 layers in Rel-8/9
Additional RS signal specified
MU-MIMO (max 4 layers, 2 per user)
Dynamic switching between SU and MU-MIMO


3) Uplink multiple antenna transmission
UL transmit diversity for PUCCH
SU-MIMO up to 4-streams

4) Relay
For places where wired backhaul is not avialable or very expensive
"type 1" - inband relay, RN (Relay Node) appears to be a Rel-8/9 eNB.
"type 1a" - outband relay, backhaul use a different frequency from access link

5) eICIC
For Micro-Pico scenario,
DL - No Problem for control channel, reuse Rel8/9 ICIC for data channel
UL - Reuse ICIC for data channel, reuse power control in Rel8/9

For Micro-Femto scenario,
Consider power control and time domain solution as baseline solutions.
At least one common TDD and FDD solution whenever possible

HeNB mobility - cont.

My last post on 8th september did not give a clear picture of HeNB mobilties and its enhancement. Therefore I am here posting another update hopefully gives a better touch on this topic.

Background:

Based on below table (from R3-101932, NTT Docomo), a large number of inbound/outbound handover occurs. Hence, LTE network should be able to support the high frequency of mobility as shown in this table.

Table1: The number of handover between Pico NB* and macro NBs in UMTS network

Deployment place		Peak of congestion time	Outbound handover [/hour]	Inbound handover [/hour]
1	Subway	6PM	5505	4549
2	High-rise building	5PM	1810	881
3	Office building	0PM (noon)	2753	507

In UMTS, RNC takes charge of handover procedures but on LTE (Rel-9), S1 handover is used for inbound/outbound mobility therefore MME has to be invovled in every single handover. The load to CN will be considerable high. In order to minimize the load to CN, optimized HeNB mobility seems to be very desirable.

Back in September 2009, 3GPP Rel-9 introduced in-bound mobility to HeNB either from another HeNB or from a macro eNB (via S1 handover). For Rel-10, HeNB mobilty enhancement is proposed to support:

- Enhanced HeNB to HeNB mobility (mainly for enterprise environments)

- Enhanced eNB to HeNB mobility (and vice versa).

The solutions

Initially two solutions as HeNB mobility optimization has been proposed.

Solution 1) HeNB to support X2 interface

Advantages:

- May work for legacy eNBs

– potentially only need an OAM configuration change to indicate that the HeNB is eligible for X2.

- Does not require a HeNB GW to be deployed to enable the enhancements.

- Works for both HeNB to HeNB mobility enhancements and eNB to HeNB mobility enhancements

- Most optimal routing and improvement of HO latency for enterprise HeNBs as the signalling remain in the enterprise network and does not need to be routed through operator nodes

Disadvantages:

- Requires X2 support for HeNBs, i.e., does not work for legacy HeNBs.

- Large IOT effort due to many HeNB vendors

Solution 2) To terminate the S1 handover signaling at the HeNB GW

Advantages:

- Works for legacy HeNBs since only the HeNB GW needs to change

Disadvantages:

- Does not support enhanced eNB to HeNB mobility and vice versa

- For enterprise, the packets still need to be routed through the HeNB GW located near the core network so this will offload the HO signalling from the MME but not necessarily improve mobility performance from the UE perspective since the latency will be about the same

- Requires the HeNB GW to be deployed and both HeNBs to be using the same HeNB GW

X2 Gateway

A variant to above solutions is the X2 gateway based solution, in which a handover between HeNB and (H)eNBs will involve the HeN

B

GW but instead of doing a S1 handover terminating at HeNB GW, X2 interface between HeNB GWs is supported, therefore it is a X2 handover but without direct X2 connection between the two handover nodes.

The advantage of this solution to solution 1):

- no need for IOT on X2 between various HeNBs

- eNB doesn't need to support many X2 connections

The advantage of this solution to solution 2):

- support enhanced

eNB to HeNB mobility and vice versa

- the handover HeNBs are not necessarily connect to the same HeNB GW

However, this solutions still need a gateway, the latency issue (if HeNB is close the ePC) and the architecture issue (a HeGW node is not mandatory in Rel-9) still exists.

Ref: 3GPP R3-101932, R3-101559, R3-102179, R3-102113

PDCCH - how UEs are scheduled

The book "LTE - from Theory to Practice" provided a very good summary of scheduling process from Control Channel point of view. Here is some of the excerpt:

"A typical seqeuence of steps carried out by eNodeB could be envisaged as follows:

1. Determine which UEs should be granted resources in the uplink, based on information such as channel quality measurements, scheduling requests and buffer status reports. Also decide on which resources should be granted.

2. Determine which UEs should be scheduled for packet transmission in the downlink, based on information such as channel quality indicator reports, and in the case of MIMO, rank indication and perferred precoding matrix

3. Indentify common control channel messages which are requred (e.g. power control commands using DCI format 3)

4. For each message decide on the PDCCH format (i.e. 1,2,4,8 CCEs), and any power offset to be apllied, in order to reach the intended UE(s) which sufficient reliability, while minimizing PDCCH overhead.

5. Determine how much PDCCH resource (in terms of CCEs) will be required, how many OFDM symbols would be needed for these PDCCHs and therefore what should be signalled on PCFICH.

6. Map each PDCCH to a CCE location within the appropriate search space.

7. If any PDCCHs cannot be mapped to a CCE location because all locations in the relevant search space have allready been assigned, either:
- continue to next step (step 9) accepting that one or more PDCCHs will not be transmitted, and now all DL-SCH and/or UL-SCH resources will be used, will a likely loss in throughput.
- allocate one more OFDM symbol to support the required PDCCHs and possibly revisit step 1 and/or 2 and change UE selection and resource allocation (e.g. to fully use uplink and downlink resources)

8) allocation the necessary resources to PCFICH and PHICH

9) Allocate resources to PDCCHs

10) Check that total power level per OFDM symbol does not exceed maximum allowed, and ajust if necessary

11) Transmit downlink control channels"


A few notes to help understanding the above description:

- CCE denotes Control Channel Elements, each CCE is nine REGs, where each REG is four physical resource elements

- LTE has four PDCCH formats (0-3), which has 1,2,4,8 CCEs respectively. The total number of bits can be transmitted over PDCCH for each format is 72, 144, 288, 576 respectively.
note: 1 CCE = 9 REGs = 4REs/REG * 9 REG = 36REs * 2bit/symbol = 72 bits

- the PDCCH can occupy the first 1, 2 or 3 OFDM symbols in a subframe, extending over the entire system bandwidth.

- PCFICH carriers control format indicator (CFI) which indicates the number of OFDM symbols (1,2 or 3) used for control channels. In principle the UE could deduce the value of CFI without PCFICH, for example by multiple attemps to decode the control channels assuming each possible number of symbols, but this would result in significant processing load.

- PHICH carriers HARQ ACK/NACK, it is modulated by BPSK, can be mapped onto 1, 2 or 3 OFDM symbols (and CFI needs to be set correspondingly).