LTE HeNB mobility

3GPP is actively working for solutions on HeNB related mobility.There are many proposals to enhance the HeNBs or HeNB-eNB mobilities. X2 based mobility between eNBs/HeNBs and HeNBs is being defined in the following cases:Between an eNB and an open access cell HeNB Between two open access cell HeNBs Between two closed HeNBs only if they have the same CSG IDBelow is a selection of some of the proposals, with my personal comments.

X2 interface between HeNB GW
It is proposed that X2 interface between HeNB GW should be supported, in order to support handover between two different areas (for e.g. shopping mall A to B).
My comment: handover between two different HeNB GW will be a very rare case, don't see why there is a need to support such interface. This is probably drived by HNB/HeNB GW manufactures.

eNB to HeNB handover

Since macro eNBs are not designed to handle many SCTP connections, therefore allowing direct connection between the eNB and HeNB will require upgrade the macro nodes in order to support large number of SCTP connections. The second issue relates to the NRTO table management by the macro eNBs. Also, require large IOT effort due to the existence of many HeNB vendors. Therefore, it is proposed that X2-Gateway based indirect interface is suggested to RAN3 for the eNB to HeNB mobility enhancement.

My comment: Don't understand why a handout from eNB would increase eNB's SCTP connections?

HeNB to HeNB mobility enhancement

It is proposed Direct X2 interface is acceptable for the HeNB to HeNB mobility enhancement.
My comment: This seems to be the correct direction.

The evolution of wireless technology - an analogy to human society

For anyone looking for anything serious, please walk away.

In David Tse's famous book, it often says the best communication system exploits the dimension of freedom the most. Inspired by this, I came across a seemingly interesting idea, which concludes there is much synergy between the evolution of wireless technology and the evolution of human society.

GSM is kinda like Socialism. Less freedom, less efficient, but highly practical. Each user get a constant quota (a timeslot, 200kHz), as if people get quota on food and other living essentials in China 30 years ago.

CDMA (if without power control) is like Capitalism. Resources are shared but contended. Whoever has the highest "power" will get better service and may block others. With proper power control (Government intervention or Law), it can be more efficient than GSM. But essentially, each user is still an interference to the others, such as in capitalism people/companies are born to compete each other within a set of rules(law).

OFDMA, you may have already known the answer, is no doubt Communism. People are no longer interfering each other (orthogonal). It is also much more efficient than GSM. Resources (RBs) are assigned to the person who can make best use of them (frequency selective scheduling). And, there are plenty bandwidth (20MHz and more :-) )

Have a nice weekend (if it is yet finished for you) and a lovely start of the coming week.

CSN.1 and ASN.1

CSN.2and ASN.1 are commonly used in wireless specifications. Although their acronyms are similar, CSN.1 is substantially different from ASN.1.

ASN.1 defines an abstract data structure: in other words, an ASN.1 specification tells you, for example, that we have a structure with some fields in it, or a union, an array and so on. In ASN.1 we describe our data structure as we do when we are declaring C structs.

When we need to actually send the data over the network, we follow the encoding rules we have chosen. These encoding rules, like BER o PER, tell us that a structure is always coded in a given way, an integer is always coded in another way and so on. Therefore any ASN.1 tools can easily generate a C data structure and some C code able to take a BER or PER coded binary stream and decode it into that C structure.

CSN.1, instead, defines at bit-level the encoded stream. A CSN.1 definition says, for example, that we expect a 1 followed by 8 more bits or a 0 followed by 4 bits and another 0:

<> ::= 1 | 0 0;

Most of the CSN.1 tools read the CSN.1 specification file and produce a CSN.1 parser; this parser, once compiled, reads the encoded binary stream and when it recognize some valid elements in it invokes a user defined callback function.

In other words, it generates code that will say to you: hey, I found the 1 followed by the 8 bits you were expecting: the 8 bits are 11001001; do whatever you like.

Reference:http://csn1.info

Why soft handover no longer exist in LTE?

This morning I came across this question in my mind while driving to the office. The reason seems to be obvious, since there is no longer a RNC in E-UTRAN, data streams from two active sets can't be combined unless ePC plays a part (or one eNB serves as SRNC), which is clearly undesirable. However, this topic worth to be looked into a little detail.

The root cause of having soft-handover in CDMA systems is that, in CDMA, each channel is an interference to other channels, therefore transmit power control is key to maximize system capacity. Especially at cell edge, a high transmission power could block other UEs from accessing the network. Here is where soft-handover can play its part. It allows transmission on different links therefore adds Rx diversity gain. During soft-handover, two NodeBs transmit/receive the same date stream on different physical channels. The data from different active set will be combined at UE (downlink) or at RNC (uplink). As such, the bit stream can be decoded much more reliably than if only one NodeB were transmitting/receiving. In other words, without soft-handover, to achieve the same SINR, higher power is required from a NodeB or from UE, which is undesirable.

In LTE, due to the orthogonal on both downlink and uplink within a cell, power control is not as important as in 3G. Therefore, soft-handover can be dropped from the system design without having much penalty to the system performance. This reduces network architecture complexity.

To support soft-handover, Iur is mandatory in case of different NodeBs involved in the soft handover are not controlled by the same RNC. In this case, the SRNC will be responsible to combine the data flow and DRNC only controls the NodeB involved in the soft-handover. The cost of having an Iur interface is significant especially if operators have multi-vendors RNC. 3GPP removed RNC node from E-UTRAN therefore simplified the architecture. There is however a X2 interface, which is similar to Iur but not the same. X2 can be used to forward packets in case of a handover simply for lossless mobility. But unlike an Iur interface, which have to support much more complex signalling, the X2 is a lot simpler.

I shall compare X2 with Iur with detail sometime later.

Interference rejection combining - Rx diversity series (2）

As mentioned earlier, while using Rx diversity, multiple received signals need to be combined in order to maximize the Rx signal's quality.

The combination is just a matter of choosing different weight to each receiving taps.

Selective combining (SC) assigns weight 1 to the strongest signal, assign weight 0 to all the others;

Equal gain combining (EGC) assigns all signal the same weight, i.e. the decoded signal is the sum of all signals after phase adjustion;

Maximum ratio combining (MRC) assigns weight according to each Rx signal's SINR, i.e. the signals are equalized based on each channel before being summed up. The output SNR is, therefore, the sum of the SNR at each element.

The MRC technique assumed that the fading signal at each element is independent of the signal at other elements. Interference rejection combining (IRC) on the other hand, not only estimate each channel independently, but also calculates the Covariance matrix. After knowing the coherence between each channel, interference from other channels can be removed.

one good website on this topic:

http://www.dsplog.com/

TTI Bundling

TTI bundling is a feature mainly used for extending VoIP (or other real-time traffic) uplink cell edge coverage. If a UE is at cell edge, due to its limited available transmit power, it can't transmit on many RBs, otherwise the power per RB would be too low to achieve a successful tranmission. In this case, TTI bundling can be activated (via RRC signalling). The benefits of TTI bundling are:

- uplink resources over multiple TTIs can be granted via a single grant;

- There is only one HARQ feedback message per bundle

- Less RLC/MAC overhead because RLC SDUs are not segmented

TTI boundling take the RLC SDU, make several redundancy versions corresponding to the entire RLC SDU and then transmit them over several (2,3 or 4) consecutive TTIs. Only when the last redundancy version of the transport block is received by eNB, the HARQ feedback is sent. This is similar to IR in HARQ, but transmit before receiving the HARQ NACK.

Unlike TTI boundling, HARQ re-transmission could also improve the probability of successful reception. However, re-tranmission means overhead (HARQ ACK/NACK) and more importantly, a significant delay (8ms on per re-transmission). Therefore, TTI boundling is more desirable especially for real-time applications.

RLC layer could also segment the RLC SDU into smaller RLC PDUs, which can be transmitted via lower MCS, therefore also help to achieve successful transmission on the uplink. However, RLC segmentation has a few drawbacks, including more RLC/MAC header overhead, more control signalling (resource grant and HARQ), and possibly a VoIP packet loss due to HARQ feedback error (note RLC is UM here).

For details please refer to:

"LTE coverage improvement by TTI bundling" Riikka Susitaival, Michael Meyer,

Ericsson Research

LIPA and SIPTO

I guess LIPA and SIPTO are hot topics nowadays. But what exactly are they referring to? How do these solutions provide value to customer/mobile operator?

LIPA is the abbrievation of "LOCAL IP ACCESS"

SIPTO is the abbrievation of "Selected IP Traffic Offload"

Both LIPA and SIPTO divert certain IP traffic (local residential/enterprise access for LIPA, some selected IP traffic for SIPTO) from operator's EPC P-GW. Control plane is not affected, MM, SM messages still terminates at EPC.

Solution 1)

To support LIPA/SIPTO, below network elements changes are required:

A new element called "Local PDN Gateway", i.e. L-GW is introduced. The L-GW is part of the access network, and it is responsible for:

- Filtering packets based on predefined policy

- UE IP address assignment;

- Direct tunnelling between L-GW and RAN in connected mode;

When a UE is camped on a cell, it can be signalled by NAS signalling or by AS SIBs that LIPA/SIPTO can be supported, or the UE could detect the cell belongs to a pre-defined list of cells. if LIPA/SIPTO is supported, the UE could potentially initiate another LIPA/SIPTO PDN connection.

The LIPA connection establishment is no much different with traditional connection establishment, apart from that a pre-defined APN is used (or received from NAS signalling), then at the PDP activation, S-GW will establish a tunnel with L-GW instead of P-GW.

Solution 2)

A OPM (Offload Processing Module) is collocated with eNB, which has NAT and routing functions. The UE establishes a LIPA enabled connection by using standard signalling procedures. The same PDN connection is used for both traffic to public network and traffic to local home/enterprise network. The OPM decides if an uplink traffic should be routed to S-GW or to the collcated NAT function. This is transparent to UE.

Because downlink packet is now addressing to OPM rather than directly addressing to UE. when the OPM (eNB) receives downlink packet, it needs to send MME a paging indication if the UE is in idle model, then the UE can be paged and downlink packet can be transferred after UE has established connection with network.

Solution 3)

There are many other candidate solutions, for details please refer to 3GPP TR 23.829.