1.

Traffic reason Handover parameters(TRHO)

TRHO - trhoTargetLevel - TRHO target level

With this parameter you define the minimum signal level when a traffic reason
handover is allowed to an adjacent cell.

MML range: -109...-47 dBm and N (not in use)

Recommended value is -85dBm.

AUT - amhUpperLoadThreshold -AMH upper load threshold

This Parameter defines the upper threshold for load of the Base station .This
parameter triggers, BSC Controlled traffic reason handover. In other words, the
Traffic reason handover will get triggered in the Congested (Source) cell, when
the load of this source cell goes above set value in the AUT (say source cell
loaded more than 80%, triggrs TRHO).

Range: 0...100 % and N

Recommended Value is 80%

AML - amhMaxLoadOfTgtCell -AMH Max Load Of Target Cell

This Parameter defines maximum traffic load in the adjacent cell that is allowed
to be the target cell for Traffic reason handover. In other words, when the Traffic
reason handover get triggered in the Congested (Source) cell with AUT 80, the
target cell where the traffic should be distributed should not be loaded more than
60.

Range: 0...100 %

Recommended Value is 60%

TGT - amhTrhoGuardTime -TRHO Guard Time

This Parameter defines the guard time after a BSC-controlled or an MSC-
controlled TRHO, during which a handover back to the original cell is not
allowed. In other words the MS will not be directed back to the original heavy
loadad cell until the time set by TGT is attained.If TGT set to 20 sec, then the
handover from target back to source will happen after 20 sec only.

0...120 sec



Recommended value is 20sec.

ATPM - amhTrhoPbgtMargin - AMH TRHO pbgt margin

With this parameter you define the power budget margin used in Advance
Multilayer Handling when the load of the cell exceeds the value defined with the
AMH Upper Load Threshold (AUT).

Range is -24...24dBm

Recommended value is -6 dBm.


Also confirm that TRHO is on at BSC level also.You can check it through ZWOS
MML command output.Parameter is AMH_Usage which needs to be activated.
Channel Element (CE) is the required baseband processing capacity and hardware for one Speech RAB
(AMR 12.2 kbps) connection
The definition of Channel Elements as the capacity resources in WCDMA radio base stations is not
standardized by 3GPP, which implies differences in expressing Base Station capacity by different vendors.
Ericssons definition of a Channel Element is linked to Dedicated Channel (DCH) resources of the RBS, i.e.
only to the resources required for user data handling for the different RAB types. This definition includes
both dedicated data channels and dedicated signaling channels. Processing capacity required for common
signaling channels and certain radio network functionality is NOT included in the definition of a Channel
Element .

To work with modern wireless networks such as UMTS and LTE, it is essential that the
telecom professional has full understanding of its basic concepts, such as those that control
the call establishment and maintenance, whether it is voice (CS) or data (PS).

In this scenario, RAB and RRC are two of the most important concepts because they are
responsible for all the negotiation involved in those calls.


In addition to RAB and RRC, we still have some other terms directly involved in context, as
RB, SRB, TRB, among others. These terms are also important concepts, since without them
RAB and RRC could not exist.
So lets try to understand today - the simplest possible way - what is the RRC and RAB role
in the calls of these mobile networks in practice. As it become necessary, we will also talk
about other concepts.
Note: All telecomHall articles are originally written in Portuguese. Following we translate to
English and Spanish. As our time is short, maybe you find some typos (sometimes we just
use the automatic translator, with only a final and 'quick' review). We apologize and we
have an understanding of our effort. If you want to contribute translating / correcting of
these languages, or even creating and publishing your tutorials, please contact us: contact.

Introduction
To start, we can divide a call into two parts: the signaling (or control) and data (or
information). Already ahead of key concepts, we can understand the RRC as responsible for
the control, and the RAB as responsible for the information part.
As mentioned, other auxiliary concepts are involved in calls, but our goal today is to learn
the most basic concepts - RRC and RAB, allowing us to evolve in our learning later.
Oddly enough, even professionals who already work with UMTS-WCDMA and LTE networks
have trouble to fully understand the concepts of RRC and RAB. And without this initial
understanding, hardly they can evolve with clarity and efficiency in their daily work.
Without further introduction, let's go straight to the point and then try to understand once
and for all these so important concepts.

Analogy
As always, and as usual the telecomHall, let's make an analogy that helps us to understand
the functioning of the RRC and RAB in practice.
Let's start imagining the following scenario: two people are cut off by a cliff. On the left
side, a person (1) want to buy some things that are for sale in a store (2) or deposit on the
right side. In the right side, in addition to the deposit, we also have a seller (3), which will
help the buyer to contact (negotiable) with the deposit.
As additional or auxiliary objects (4), we have some iron bars with different sizes, and some
cars - some like train wagon, others like remote control cars.
In short, we have the situation outlined in the image below.


And so, how this situation can be solved?
Let's continue with a possible solution: the buyer on the left write his request in a note, tie
on a small stone that he found on the floor, and send (1) it to the seller on the other side.
So, the stone carry the information or initial request.


The seller receives the request, but she need to send it to the deposit, in order for the
shopping to be sent. She sends the request on a remote control car (1), which run a
previously demarcated path to the deposit.


Some time later, the deposit response arrives to seller (1), which then checks to see
whether she will be able to send the data or not.


So that we can proceed with our call, let's consider a positive response. That is, what the
buyer is willing, or the 'resources' are available.
Seller realizes that to fulfill the request, and be able to send the purchases, she will need to
build a 'path' (1) between the two ends of the cliff, so the wagons could carry over with the
orders/receipts and purchases. Then, the seller uses some of its iron bars and creates a link
between the two sides.


Once established all the way between those involved, requests can be sent from both sides
as well as the purchases or any other information can be transferred by different paths and
wagons/cars!

If you managed to understand how the above problem was solved, congratulations, you just
understand how the most common form of UMTS-WCDMA and LTE communication happens!
Although analogies are not perfect, it help us a lot to understand the complex functioning of
these networks, especially in relation to new concepts such as RRC and RAB, but also a very
often used, the 'bearer' so much that it's worth talking a little bit about it.

What is Bearer?
If we search the word 'bearer' in the dictionary, we'll find something like trasnporter, or
carrier. In a simple way: one who carries or conveys something from some point to another
point. In a restaurant, we can compare the 'bearer' to a waiter.


But from the telecommunications point of view, 'bearer' is best understood as a 'pipe' that
connects two or more points in a communication system, through which the data flows.


Technically speaking, it is a channel that carries Voice or Data, a logical connection between
different points (nodes) that ensures that the packets that are traveling have the same QoS
attributes. Explaining better: for each 'bearer' we have several associated parameters, such
as the maximum delay and packet loss limit and these attributes that make sure each
packet going in the same channel have the same QoS attributes.

General Flowchart - RRC, RAB and Others
Now that we know what is bearer, let's go back to the analogy presented earlier, but now
bringing it to the real, more technical side.
All that we'll talk can be summarized in a single figure, having all the concepts seen today,
and that will be detailed from now on.
Note: If you manage to understand the concepts that will be explained in the figure below,
you will be with a great base for both WCDMA and LTE networks. This is because, in order
to facilitate we use WCDMA nomenclatures, but the principle is pretty much the same in
LTE. Just do the equivalent replaces, like NodeB for eNB.


On that ficticious scenario, the seller is the UTRAN, responsible for creating and maintaining
the communication between the UE (buyer) and CN (deposit) so that the QoS requirements
of each are met.

UTRAN: UMTS Terrestrial Radio Access Network

o
NodeB
o
RNC

UE: User Equipment

CN: Core Network

o
MSC: for switched voice services
o
SGSN: for packet-switched services
The cliff is the Uu Interface between the UE and the UTRAN, and the road through the
remote control car goes until the deposit is the Iu Interface, between the UTRAN and CN.
Sending requests and receipts is part of signaling, or the RRC. The shipment of purchases is
the data part, or the RAB. In our scenario, the RRC are the Rails, and RAB is the full service
of sending data between the UE and the CN.

RRC: Radio Resource Control

RAB: Radio Access Bearer

Note: the RRC is in Layer 3 - control plane, while the RAB occurs between the UE and CN, in
the user plane.
The railcars are the RBs, and convey the information in the radio path. These wagons define
what type of thing will be transported, and in what quantity. Similarly, the RBs define what
type of data will in the RRC, which can be Data or Signaling. When the QoS attributes
change, then the Rbs associated with that RRC connection need to be reconfigured.
The remote control cars are the Iu bearer, and carry information on Iu Interface (between
the UTRAN and the CN), either CS or PS.

RB: Radio Bearer

Iu bearer: Iu Bearer Interface

Note: RAB is the combination of RB and Iu bearer.
As examples of RAB for some services and different rates we have:


The Conversational RAB and the Interactive RAB can be used together, and in this case we
have a case of MultiRAB.
The RB is a layer 2 connection between the UE and the RNC, and can be used for Signalling
and control User Data. When it is used for Signalling or Control Messages is called SRB. And
when it is used for user data is called TRB.

SRB: Signalling Radio Bearer (Control Plane)

TRB: Traffic Radio Bearer (User Plane)

Note: in an optimized network, we can find much of the traffic being handled by HSPA
bearers, even MultiRAB. This option frees resources from CE (Channel Elements), relieving
the load on R99 (that can only use these resources). However, it should be done with
caution, because if improperly configured it can degrade the Performance Indicators with
Blockage (Congestion) and Failures.
As you've probably noticed, we're talking about several new technical terms, but these
terms are what you'll find for example when reading UMTS or LTE call flowcharts. But if you
can understand at least in part the concepts presented today, everything will be much
easier.
Let us then take a look again on our figure, and continue our analogy.


As we saw, in telecom we work with the concept of layers. And this way of seeing the
network brings us many advantages, mainly because we were able to 'wrap' physical
access. In this way, any modification or replacement can be made with less complexity.
We don't need to tell you how much the radio path is complex, continuously changing,
right? This structure using beares ensures this simplification: the RNC and CN bother with
QoS requirements in the path between them (Iu Interface); and only the RNC have to worry
about meeting the complex radio path QoS.
Sure, but why we have two types of carriers - wagons and remote control cars? The answer
to this is in the very characteristic of the two existing paths. Being the Iu a more robust
interface, and also because we have major changes in RABs during connections, it is normal
that these bearers are also different for the paths. it's like using a 4x4 pickup truck to climb
a mountain, and a race car to an asphalt race.


Regardless the carriers, with the RAB the elements of the CN has the impression of a
physical path to the UE, so don't need to be worrying about the complex aspects of radio
communication.
For example, a UE can have 3 RABs between he and the RNC, and these RABs may be
changing, as in the case of soft handovers, while the RNC has only 1 Iu bearer for this
connection.
From the point of view of the carriers, the main task of the UTRAN is managing these
services on these interfaces. She controls the Uu interface, and along with the CN, controls
the provision of services in the Iu interface.
Remember that in a communication between the UE and the CN, several other elements are
involved, mainly to negotiate QoS requirements between both parties. These requirements
are mapped in the RABs, that are visible to both (UE and CN), where the UTRAN is
responsible for creating and maintaining these RABs so that all of this is served in all
aspects.
A little bit more details...

A RRC connection exists when an UE performs the call establishment procedure, and get
resources from the UTRAN. When a RRC connection is established, the UE will also get some
SRBs. (If for some reason the initial request is not accepted, the UE can make a new
request after some time).
Since the SRB was established between the UE and the CN, the RNC checks a series of
information such as the UE identity, what is the reason for the request and whether the UE
is able to handle the requested service.
The RNC that maps the requested RABs into RBs, to transfer between the UE and the
UTRAN. In addition it is also check the attributes of the RABs: if they can be met by the
available resources, and even whether to activate or reset radio channels (reconfiguration of
lower layers services ) based on the number of Signaling Connections and RABs to be
transferred.
This way, it creates the impression that there is a physical path between the UE and the CN.
Remembering again that no matter how many signaling and RABs connections there are
between the ue and the CN - there is only a single RRC connection used by the RNC to
control and transfer between the UE and the UTRAN.
Now that we have seen a lot about RRC and RAB, let's learn only a few more concepts today
after all, we already have enough information presented. Let's talk about the AS and NAS.

AS Access Stratum is a group of specific protocols of access network

NAS NON Access Stratum: so, are the other protocols, or those that are not access network
At this point of view, the AS provides the RAB to the NAS, or information transfer service.
The UE and CN need to communicate (events/messages) with each other to perform several
procedures with many purposes. And the 'language' of this conversation between them is
called protocols.
The protocols are then responsible for allowing this conversation between the UE and CN,
and cause the CN do not worry about the method of access (be it GSM/GPRS, UTRAN, LTE).
In our case the RNC acts as a protocol - between the UTRAN and CN.
According to what we learned today, the RAB is carried:

Between the UE and the UTRAN: within the RRC connection. The RRC Protocol is responsible for
negotiating the (logical) channels of Uu and IuB interfaces, and for the establishment of signaling
dedicated channels as SRBs and RBs among these interfaces.

Between the RNC and the CN: after being negotiated and mapped, in the RANAP protocol
connection, through Iu interface (CS/PS).
o
RANAP: Radio Access Network Application Part
As we have seen above, the RNC maps requested RABs into RBs using current radio
network resources information, and controls the services of lower layers. To optimize the
use of these resources, as well as the network band and physical resource sharing between
different entities, the UTRAN can also perform the function of CN messages distribution.
For this, the RRC Protocol transparently transfers messages from CN to the access network
through a direct transfer procedure. When this occurs, a specific indicator of CN is inserted
in these messages, and the entities with the distribution function in RNC use this same
indicator for direct messages to the appropriate CN, and vice versa.
But now it started to get more complex, and we have already reached our goal today, which
was to learn the basics of RRC and RAB.
Everything we just talked about above can be seen again in the same figure below, the
same from the beginning of the explanations.


RRC and RAB in GSM?
Okay, we understand how RRC and RAB works in UMTS-WCDMA and LTE networks. But in
GSM, does we have these concepts as well?
At first, the answer is NO. However, with what we learned today, we can make a
comparison with some GSM 'equivalent' parameters.
We can compare the SDCCH phase and TCH phase of a GSM call with RRC and RAB in
UMTS.
RRC is the Radio Resource Control that works as Control Plane in Layer 3. Is used primarily
for Signaling in UMTS. Then we can compare with the signaling in GSM, as the Immediate
Assignment process for SDCCH resource allocation.
RAB is the radio access 'transporter' that works as the User Plane to provide data for the
services requested by the user. Then we can compare with the user part in GSM, as the TCH
Assignment.
For each service requested by the user we have only 1 RAB. For example, if the requested
service is a Voice Call (CS-AMR), then 1 CS RAB will be generated and provided to the user.
The same is true for PS.
So our equivalence table would be:
UMTS / LTE GSM
Control RRC Connection Immediate Assignment
User RAB Assignment (RNC-CN) Assignment (BSC-MSC)


RRC Connection and RAB example
To complete for today, let's see (always in simplified form) a simple RRC connection and
RAB.
Whenever the UE needs the UTRAN resources, he asks. So that these resources are
allocated, it establishes a RRC connection with some SRBs.
In this case, a RAB connection is created to enable the transfer of user data. We remind you
that the RAB consists of RB + Iu bearer. The RAB is created by CN, with a specific QoS
request.
For a single UE, there may be multiple RAB for NAS service (CS or PS).
But let's just stick to the initial procedure, that is, how is performed the 'RRC Setup'
procedure, from the UE's request.
The following figure shows this more straightforward.




The RRC has always 3 steps:
1. The UE requests a new connection in the Uplink (RRC CONNECTION REQUEST);
2. With sufficient resources available, the 'RRC Downlink CONNECTION SETUP' message is sent,
including the reason, along with the SRB configuration; (Note: otherwise, if the RRC connection
cannot be established, the message sent is 'RRC CONNECTION SETUP REJECT').
3. If all goes well, the UE sends the message in the Uplink: RRC CONNECTION SETUP COMPLETE.
And after this, the MEASUREMENT CONTROL message are being sent in the Downlink, for
the communication continuity.
After the RRC connection is established, the UTRAN makes the checks between the CN and
the UE, for example the authentication and security operations.
And so, the CN informs the RAB to UTRAN in accordance with requirements of the service
requested by the UE. As we have seen, RAB occurs after the RRC, and without a RRC
connection no RAB may be established.

Conclusion
We have seen today a simplified explanation that covers a number of concepts involved in
the communication of the most modern existing mobile networks, primarily related to RRC
and RAB.
With this conceptual base, we will continue to evolve in the next tutorials with examples
that make the assimilation of these complex concepts in a task far less exhaustive than
normal.
What is Ec/Io (and Eb/No)?
- April 2011 +

S M T W T F S
27 28 29 30 31 1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
1 2 3 4 5 6 7

Statistics

Entries (24)
Categories

Course (24)
Related Posts

Analyzing Coverage with Propagation Delay - PD and Timing Advance - TA (GSM-WCDMA-LTE)

What is RRC and RAB?

What is Retransmission, ARQ and HARQ?

IP Packet switching in Telecom - Part 4

IP Packet switching in Telecom - Part 3

IP Packet switching in Telecom - Part 2

IP Packet switching in Telecom - Part 1

Goodbye IPv4... Hello IPv6!

What is Antenna Electrical and Mechanical Tilt (and How to use it)?

What is MIMO?

How to Run a RF Site Survey (Tips and Best Practices)

What is Cellular Field Test Mode?

What is Antenna?

OSI 7 Layers Model

What is RF Drive Test (Testing)?

Archives

June, 2013 (1)

May, 2013 (1)

June, 2012 (1)

March, 2012 (1)

February, 2012 (2)

January, 2012 (1)

November, 2011 (1)

October, 2011 (1)

September, 2011 (1)

June, 2011 (1)

April, 2011 (2)

March, 2011 (3)

February, 2011 (5)

January, 2011 (1)

December, 2010 (2)

Posted by leopedrini Tuesday, April 12, 2011 10:52:00 AM Categories: Course
Previous Post << >> Next Post
Rate this Content


0 Votes
If someone asks you "Which Signal Level for good call quality: -80 dbm or -90 dBm?"
Beware, if you respond quickly, you might end up missing. This is because the correct
answer is ... it depends! The Signal Strength is a very important and essential measure for
any technology (GSM, CDMA, UMTS, LTE, etc.). However, it is not the only one: let's talk a
little today about another magnitude, equally important: the Signal Noise Ratio.


Although this ratio is of fundamental importance to any cellular system, is not well
understood by many professionals. On the opposite side, professionals with a good
understanding of this ratio are able for example, to correctly assess the RF links, and also to
perform more extensive optimizations, obtaining the best possible performance of the
system.
So, let's see a little about it?

Eb and No
To begin, we define the basic concepts of Eb and No. They are basic for any digital
communication system, and generally we talk about it when we deal with Bit Error Rate and
also Modulation techniques.
Simply put:

Eb: Bit Energy.

o
It represents the amount of energy per bit.

No: Noise Spectral Density.

o
Unit: Watts/Hz (or mWatts/Hz)
Which brings us to the classic definition of Eb/No:

Eb/No: Bit Energy on the Spectral Noise Density.

o
Unit: dB
It did not help much, does it?
Do not worry. Indeed, only with the theoretical definition is still very difficult to see how this
ratio is used, or how it can be measured.
But okay, let's walk a little further.

Okay, so how is Eb/No measured?
To understand how this ratio can be measured, let's imagine a simple digital communication
system.


The ratio Eb/No is measured at the receiver, and serves to indicate how strong the signal is.
Depending on the modulation technique used (BPSK, QPSK, etc.) we have different curves
for Bit Error Rate x Eb/No.
These curves are used as follows: for a certain RF signal, which is the bit errors rate that I
have? Is this bit error rate acceptable for my system?
Whereas the gain that digital has, then we can set a minimum criterion of signal to noise
ratio, in order to have each service (Voice/Data) operating acceptably.


In other words, we can theoretically determine how the performance would be for the digital
link.
Note: it is worth remembering here that this is a very complex subject. As always, we try to
introduce to you the most simplified possible through the use of examples and simple
concepts. Okay?
For example, a concept that could be explored here - since we are talking about digital
communication system - is the Noise Figure. But we do not want to repeat here all the
theory explained in the University. Nor was it to have mentioned the noise figure here, but
as we talked about it, just understand as a noise level that every receiver has, and that it is
due to the process of amplification and processing of signal.
Concepts like this, and other even more complex, can be studied, if you wish. But now, let's
continue with our signal to noise ratio.

Eb/No -> Ec/Io
The concept of Eb/No applies to any digital communication system. But today we are talking
specifically to Ec/Io, which is a measure of evaluation and decisions of CDMA and UMTS.
Note: all the technology uses signal-interference ratio. For example, in GSM, we use C/I.
As we are speaking of codes, it becomes easier to understand the concepts by observing a
simplified diagram of Spread Spectrum Modulation.
In red, in transmitter have a narrowband signal with data or voice modulated. This signal is
spread and transmitted. And spreads through the middle (air). In the receiver, the signal is
despread - using the same sequence that was spread - and thus recovering the base
narrowband signal.

To proceed, we must know some more definitions. However, this point is quite delicate, as
we enter a conceptual area where we have differences between authors, differences in
translations/countries, where differences in technologies are applied, etc..
Let's try to define in a generic way, and only the main.

No: Spectral Density of Noise;

o
Noise generated by the RF components of the system, the air, among others.

Io: Interference is the Broadband; Interfering co-channel, including yourself setor.

E: is the signal (average) energy - do not confuse it with the sinal (average) power.

b, c, s. ..: Energy are the power points in time, therefore related to the measure or 'length' of the
time (the average power is independent of time ).
o
Hence it comes Eb, Ec and Es, respectively relating to Bit Chip and Symbol in different
times.
Note: With these concepts, several formulas can be derived with different numerators and
denominators. For example, Es = Eb * k, where k = number of bits per symbol. In QPSK
modulation, where k = 2, Es = 2 * Eb. And the derivations of formulas can reach far more
complex equations, such as the definitions of capacity of an AWGN channel, and further
deductions for equivalences (Ec/No, Eb/Nt, etc. ...). Again, it is not our purpose here today.
We only mention a few concepts, related.
Then come back to the practical level - noting that theoretical approaches can be done more
easily later, after the basics are understood.
So let's keep today in ratios most common: Eb/No and Ec/Io.
As we defined Eb/No is the Average Energy of a bit signal, on the Spectral Density of
Noise. It is primarily a parameter related to the manufacturer for different bearers (based
on the channel model). But it can also vary with the environment (urban, rural, suburban),
speed, diversity, use of power control, application type, etc..
And now we can begin to define Ec/Io, one of the most important systems in CDMA and
UMTS.
Note: An important observation is that often when we refer to Ec/Io, we are actually
referring to Ec/(Io + No). What happens is that for practical purposes, we only have Ec/Io,
because the interference is much stronger and the noise can be neglected. Otherwise: for
CDMA interference is like a noise, then both can be considered the same thing.
Okay, let's stop with the issues and concepts, and talk a little about the values of these
indicators and their use in practice.

Eb/No Positive and Ec/Io Negative?
In terms of values, and talking logarithmicly, if any ratio is less than 1, then the value is
negative. If greater than 1, positive.
We have Ec/Io in the air, which is spread across the spectrum: then we have negative value
to the ratio of energy on the total noise (the energy is lower than the Total Interference). It
is measured at the input of receiver (NodeB, UE, etc).
Regarding Eb/No, it is in the baseband after despreading and decoded only for one user -
then we have a positive amount of energy over the total noise. It is measured at the output
of receiver (NodeB, UE, etc).

Why should we use Ec/Io?
A more natural question would be: why we can not simply use the Signal Strength
measured by the mobile as a guide for operations such as handover?
The answer is simple: the measured signal level corresponds to the Total RF power - All
cells that the mobile sees.
So we need another quick and simple measure that allows us to evaluate the contribution of
each sector individually.
We used to measure the pilot channel signal of each sector to assess the quality: if the level
of the pilot is good, then also are good levels for the traffic channels for our call in this
sector. Likewise, if the pilot channel is degraded, so will the other channels (including
traffic) be, and it is best to avoid using the traffic channels in this sector.
UMTS and CDMA systems, we have a pilot channel, some other control channels such as
paging, and traffic channels.
The Ec/Io varies with several factors, such as the Traffic Load and and RF Scenario.
Of course, the Ec/Io is the final composition of all these factors simultaneously (Composite
Ec/Io), but it's easier to understand talking about each one separately.

Change in Ec/Io according to the Sector Traffic Load
Each sector transmits a certain power. Suppose in our example we have a pilot channel
power setting of 2 W, and a power of other control channels also fixed at 2 W.
To make it easier to understand, we calculate the Ec/Io (pilot channel power to total power)
of this sector in a situation where we have no busy traffic channel (0 W).


Thus we have:
Ec = 2 W
Io = 0 + 2 + 2 = 4 W
Ec/Io = (2/4) = 0.5 = -3 dB
Now assume that several traffic channels are busy (eg use 6 W for traffic channels). This is
a situation of traffic load, we'll see how is Ec/Io.


Ec = 2 W
Io = 2 + 2 + 6 = 10 W
Ec/Io = (2/10) = 0.2 = -7 dB
Conclusion: As the traffic load in the sector increases, the Ec/Io worsens.

Change in Ec/Io according to the scenario RF
According to the RF scenario - a single server sector, some or many servers sectors - we
can also take various measures to Ec/Io.
Considering first a situation without external interference, with only one server sector
(dominant), the ratio Ec/Io is about the same initially transmitted.


Ec/Io = (2/8) = 0.25 = -6 dB
Whereas a signal coming from this sector in the mobile at level of -90 dBm (Io = -90 dBm),
we have Ec = -90 dBm + (- 6 db) = -96 dBm.

Let us now consider another situation. Instead of one, we have five sectors signal arriving at
the mobile (for simplicity, all with the same level of -90 dBm).


Now have Io = -83 dBm (which is the sum of five signals of -90 dBm). And the power of our
pilot channel remains the same (Ec = -96 dBm).
Thus: Ec/Io = -96 - (-83) = -13 dB
Conclusion: As many more sectors serves the mobile, the Ec/Io worsens.

This situation where we have many overlapping sectors, and with the same level of signal is
known as Pilot Pollution - the mobile sees them all at once - each acting as interferer to
each other.
The solution in such cases is to eliminate unwanted signals, by setting power parameters or
physical adjustments (tilt, azimuth), leaving just dominant signals which should exist at this
problematic place.

Okay, and what are typical values?
We have seen that for CDMA and UMTS systems, the measurement of Ec/Io which is very
important in the analysis, especially in handover decisions.
And now also understand the measure Ec/Io as the ratio of 'good' energy over 'bad' energy,
or 'cleaness' of signal.
But what are the practical values?
The value of Ec/Io fluctuates (varies), as well as any wireless signal. If the value starts to
get too low, you start to have dropped calls, or can not connect. But what then is a good
range of Ec/Io for a sign?
In practical terms, values of Ec/Io for a good evaluation of the network (in terms of this
indicator) are shown in the diagram below.

A composite Ec/Io ~ - 10 db is a reasonable value to consider as good.
Note: See we are talking about negative values, and considering them 'good'. In other
words, we are saying that energy is below the Noise (and still have a good situation).
This is a characteristic of the system itself, and Ec/Io 'most negative' or 'less negative' is
going to allow assessment of the communication.
In situations where Ec/Io is very low (high negative number), and the signal level too (also
high negative number), first we need to worry in enhancing the weak signal.
Another typical situation: if the measured Ec/Io is very low, even if you have a good signal
level, you can not connect, or the call will drop constantly.
I hope you've managed to understand how the Ec/Io is important for CDMA and UMTS.
Note, however, that this matter is very complex, and supplementary reading - books and
internet - can further help you become an expert on the subject.
Anyway, the content displayed serves as an excellent reference, especially if you're not
familiar with the concept of signal over noise for CDMA and UMTS.

And the Signal to Noise Ratio for other technologies?
The ratio Ec/Io is the most commonly used to assess the condition of energy over
interference, but applies only in technologies that use codes (Ec).
But the concepts understood here to CDMA and UMTS are very similar - apply - for any
technology, eg GSM, where we use the C/I.
Anyway, this is a topic for another tutorial, we saw today Ec/Io.

Conclusion
Today we had a brief introduction on the Ec/Io ratio, a measurement for decisions in CDMA
and UMTS, and used togheter with the measured Signal Strength.
We have seen that it represents the ratio of signal energy within the duration of a chip of
the pilot channel, on the Spectral Density of Noise + Interference.
This is a very important measure, which somehow ignores the overall strength of the signal,
and focuses on how best to evaluate the pilot channel signal is desired, in relation to noise
that interferes with it.
Returning to our original question: A strong signal level does not necessarily indicate an
strong Ec/Io: it depends on the level of interference.




We hope that you have enjoyed, and we count on your participation, which can be for
example suggesting new topics, or sharing our site with your friends. If possible, leave also
your comments just below.
What is Retransmission, ARQ and HARQ?
- June 2012 +

S M T W T F S
27 28 29 30 31 1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
1 2 3 4 5 6 7

Statistics

Entries (24)
Categories

Course (24)
Related Posts

Analyzing Coverage with Propagation Delay - PD and Timing Advance - TA (GSM-WCDMA-LTE)

What is RRC and RAB?

IP Packet switching in Telecom - Part 4

IP Packet switching in Telecom - Part 3

IP Packet switching in Telecom - Part 2

IP Packet switching in Telecom - Part 1

Goodbye IPv4... Hello IPv6!

What is Antenna Electrical and Mechanical Tilt (and How to use it)?

What is MIMO?

How to Run a RF Site Survey (Tips and Best Practices)

What is Ec/Io (and Eb/No)?

What is Cellular Field Test Mode?

What is Antenna?

OSI 7 Layers Model

What is RF Drive Test (Testing)?

Archives

June, 2013 (1)

May, 2013 (1)

June, 2012 (1)

March, 2012 (1)

February, 2012 (2)

January, 2012 (1)

November, 2011 (1)

October, 2011 (1)

September, 2011 (1)

June, 2011 (1)

April, 2011 (2)

March, 2011 (3)

February, 2011 (5)

January, 2011 (1)

December, 2010 (2)

Posted by leopedrini Friday, June 22, 2012 11:12:00 AM Categories: Course
Previous Post << >> Next Post
Rate this Content


2 Votes
It's very important to use solutions that improve the efficiency of the adopted model in any
data communication system. If the transmission is 'Wireless', this need is even greater.
In this scenario we have techniques that basically checks, or verify if the information sent
by the transmitter correctly arrived in the receiver. In the following example, we have a
packet being sent from the transmitter to the receiver.


If the information arrived properly (complete), the receiver is ready to receive (and process)
new data. If the information arrived with some problem, corrupted, the receiver must
request that the transmitter sent the packet again (retransmission).


Let's understand a little more about these concepts increasingly used (and required) in the
current systems?


Note: All telecomHall articles are originally written in Portuguese. Following we translate to
English and Spanish. As our time is short, maybe you find some typos (sometimes we just
use the automatic translator, with only a final and 'quick' review). We apologize and we
have an understanding of our effort. If you want to contribute translating / correcting of
these languages, or even creating and publishing your tutorials, please contact us: contact.

Error Checking and Correction
We start talking about errors. Errors are possible, and mainly due to the transmission link.
In fact, we can even 'expect' errors when it comes to Wireless Data Transmission.
If we have errors, we need to take some action. In our case, we can divide it into two steps:
error checking and error correction.
Error checking is required to allow the receiver to verify that the information that arrived is
correct or not.
One of the most common methods of error checking is the CRC, or 'Cyclic Redundancy
Check', where bits (CRC) are added to a group of information bits. The CRC bits are
generated based on the contents of the information bits. If an error happens with the
information bits, the CRC bits are used to verify and help recover the degraded information.
The level of protection provided is determined by the ratio: number of CRC bits by the
number of information bits. Above a certain error level, the process is eliminated. CRC
protection is used practically in all existing Voice and Data applications.
The following diagram shows a simplified demonstration of how the CRC is used.


And the CRC is directly connected to the Error Correction methods. There are various ways
of Foward Error Correction (FEC), but the main idea is, given a level of quality in the link,
try to get the lowest number of required retransmissions.
Minimizing the number of retransmissions we ended up having a more efficient data flow
result, including - mainly - the 'Throughput'.
In simplified way: the CRC lets you know if a package arrived 'OK' or 'NOT OK'. Every
packet that is sent has a CRC, or a 'Signature'. As an analogy, it's like when we send a
letter to someone, and in the end we sign: 'My Full Name'. When the other person receives
this letter (information), he checks the signature: 'My Wrong'. In this case, he tells the
Messenger: 'I don't know 'My Wrong', this information has some problems. Please ask
sender to send it again!'.
I.e. I do CRC checks. If the CRC is 'wrong', the information is 'wrong'. If the CRC is 'correct',
probably the information is 'correct'.

Retransmissions
Retransmissions are then: send information again (repeat) to the receiver, after it make
such a request. The receiver requests that the information be retransmitted whenever it
cannot decode the packet, or the result of decoding has been an error. That is, after
checking that the information reached the receiver is not 'OK', we should request it to be
retransmitted.


Of course, when we have a good link (SNR), without interference or problems that may
affect data integrity, we have virtually no need for retransmissions.
In practice, in real World, this is very difficult to happen, because the links can face the
most different adversities. Thus, an efficient mechanism to enable and manage the
retransmission is essential.
We consider such a mechanism as efficient when it allow data communication in a link meet
quality requirements that the service demands (QoS).
Voice for example, is a service where retransmission does not apply. If a piece of
information is lost, and is retransmitted, the conversation becomes intelligible.
On the other hand, data services practically rely on retransmission, since most have - or
allows - a certain tolerance to delays some more, some less. With the exception only for
'Real Time' services.
But it is also important to take into account that the greater the number of needed
retransmissions, lower the data transmission rate that is effectively reached: If the
information have to be retransmitted several times, it will take long for the receiver to
obtain the complete - final - information.

ARQ
Till now we talked in a generic way about data retransmissions, error checking and
correction. Let's now see some real and practical schemes.
The simplest way (or more common) control using what we described above is known as
ARQ, or 'Automatic Repeat Request'.
In ARQ, when we have a 'bad' package, the system simply discards it, and asks for a
retransmission (of the same package). And for this, it sends a feedback message to the
transmitter.


These feedback messages are messages that the receiver uses to inform whether the
transmission was successful or not: 'ACKnowledgement' (ACK) and 'Non-ACKnowledgement'
(NACK). These messages are transmitted from the receiver to the transmitter, and
respectively informs a good (ACK) or bad (NACK) reception of the previous packages.
If in the new retransmission the packet keep arriving with errors, the system requests a
new retransmission (still for this same package). That is, sends another 'NACK' message.


The data packets that are not properly decoded are discarded. The data packets or
retransmissions are separately decoded. That is, every time a packet that arrives is bad, it
is discarded, and it is requested that this same package be retransmitted.
But see that if there were no retransmissions, the performance of the data flow would be
much better. In the example below, compared with the previous, we transmit more
information - 3 times in the same time interval.


Unfortunately we don't have much to do about the link conditions. Or better, we are able to
improve the links performance, for example with configuration parameters optimization, but
we'll always be subject to face adverse conditions. In this case, our only way out is to try to
minimize retransmissions.
And that's where arise other techniques or more 'enhanced' schemes for retransmission.
The main one is HARQ.

Hybrid ARQ (HARQ)
The HARQ is the use of conventional ARQ along with an Error Correction technique called
'Soft Combining', which no longer discards the received bad data (with error).
With the 'Soft Combining' data packets that are not properly decoded are not discarded
anymore. The received signal is stored in a 'buffer', and will be combined with next
retransmission.
That is, two or more packets received, each one with insufficient SNR to allow individual
decoding can be combined in such a way that the total signal can be decoded!
The following image explains this procedure. The transmitter sends a package [1]. The
package [1] arrives, and is 'OK'. If the package [1] is 'OK' then the receiver sends an 'ACK'.


The transmission continues, and is sent a package [2]. The package [2] arrives, but let's
consider now that it arrives with errors. If the package [2] arrives with errors, the receiver
sends a 'NACK'.


Only now this package [2] (bad) is not thrown away, as it is done in conventional ARQ. Now
it is stored in a 'buffer'.


Continuing, the transmitter send another package [2.1] that also (let's consider) arrives
with errors.


We have then in a buffer: bad package [2], and another package [2.1] which is also bad.
Does by adding (combining) these two packages ([2] + [2.1]) we have the complete
information?
Yes. So we send an 'ACK'.


But if the combination of these two packages still does not give us the complete
information, the process must continue - and another 'NACK' is sent.


And there we have another retransmission. Now the transmitter sends a third package
[2.2].
Let's consider that now it is 'OK', and the receiver sends an 'ACK'.


Here we can see the following: along with the received package [2.2], the receiver also has
packages [2] and [2.1], that have not been dropped and are stored in the buffer.
In our example, we see that the package arrived 2 times 'wrong'. And what is the limit of
these retransmissions? Up to 4. IE, we can have up to 4 retransmission in each process.
This is the maximum number supported by 'buffer'.

Different HARQ Schemes
Going back a little in the case of Conventional ARQ, whenever we send a package and it
arrives with problems, it is discarded.
Taking the above example, when we send the package [2], and it arrives with errors, it is
discarded. And this same package [2] is sent again.
What happens is that we no longer have the concept of 'package version' - [2.1], [2.2], etc.
We do not have the 'redundancy' version, or the gain we get in HARQ processing.
To understand this, we need to know that information is divided as follows:
[Information + Redundancy + Redundancy]
When we transmit the packet [2] we are transmitting this:
[Information + Redundancy + Redundancy]
When retransmit the same package [2] we are retransmiting it again:
[Information + Redundancy + Redundancy]

But when we use HARQ, and retransmit packet [2.1] or [2.2], we have the possibility of:

Or retransmit that same information again;

Or retransmit only the redundancy.

And then, if we retransmit less information (only redundancy), we spend less energy, and
that will run much faster. With this we have a gain!
That is, we work with different 'versions of redundancy', that allows us to have a gain in the
retransmission. This is called 'Redundancy Version', or what version of redundancy.
The redundancy version, or HARQ scheme with 'Soft Combining' can be 'Chase Combination'
or 'Incremental Redundancy'.


HARQ Chase Combination

Chase Combination: when we combine the same information (the retransmission is an
identical copy of the original packet).
We transmit an information, which arrived wrong, and we need to do a retransmission. We
retransmit the same information - and there we don't have much gain.


HARQ Incremental Redundancy

Incremental Redundancy: where we retransmit only the portion that we didn't
transmitted before. Thus we retransmit less information. Less information means fewer bits,
less energy. And this gives a gain!
Redundancy bits are retransmitted gradually to the receiver, until an ACK is received.
With this, we adapt to changes in the condition of the link. The first retransmission can, for
example, contain or not bits of redundancy. If necessary, a small number of these bits is
retransmitted. And so on.

Finishing for today: what are the 2 steps of HARQ? Why it gives me a Gain?

First because from wrong packets 1 and 2 we can get a correct one, since we do not discard
erroneous packets anymore.

Second because we can - also in retransmission - send less information, and streamline the process.
The use of HARQ with 'Soft Combining' increases the received Eb/Io effective value for each
retransmission, and therefore also increases the likelihood of correct retransmissions
decoding, in comparison to conventional ARQ.
We send a package, and it arrives with errors: we keep this package. Receive the
retransmission and then we add or combine both.

HARQ Processes (Case Study)
What we have seen so far clarifies the concepts involved. In practice, in retransmission, this
type of Protocol is called 'Stop And Wait' (there are other kinds of similar protocols).
What would be: send the information and stop. Wait for the response to send other
information. Send, wait for response. Send, wait for response ...


No! Not so in practice. In practice, we work with a number of 'processes', which may vary
for example from 4, 6 or 8. The following image illustrates this more clearly.


Other types of HARQ
New schemes are constantly being developed and used, as the type III HARQ, which uses
self-decodable packages.
danikd
2010-08-12, 03:31 AM
Is it possible to have freq. hopping BCCH ? In most cases i've seen is that hopping is only deployed in TCH ?
what are the complications associated with a hopping BCCH ?

You should be pretty clear with you question. Many terms that you are using misleading.

Just to clarify:
1. BCCH - is a common name for timeslot 0 on the first frequency carrier in GSM cell. BCCH timeslot
contains multiplex of few different logical channels for DL (FCH, SCH, BCH, PCH, AGCH, sometimes SDCCH/4
or SDCCH/3+CBCH) and RACH on UL.
2. BCCH - is a common name for frequency carrier on which BCCH timeslot is transmitted.
3. BCCH TRX is TRX, which transmits BCCH timeslot
4. TCH - is a timeslot for handling TCH (traffic channel)
5. TCH - a common name for frequency carrier which does not contain BCCH timeslot.
6. TCH TRX is a TRX which does not contain BCCH timeslot

Now close to your question:
The following restrictions applied for frequency hopping in GSM
1. BCCH timeslot should be transmitted on the fixed frequency for specific cell.
2. BCCH frequency should transmit a constant full power 100% even when some timeslots have no traffic to
serve.
3. Based on 1. and 2. from above BCCH TRX/Frequency/Timeslot can not hopp i.e. change frequency!!!

There are two major hopping schemes for hopping implementation in GSM base station:
Synthesizer (RF) and BaseBand.
Just to remind you - the mobile station has no idea what hopping type is used at base station since, hopping
is a change of TX/RX frequency according to predefined sequence every frame.

Synthesizer hopping implemented in the TRX part by changing TX/RX frequency every frame, while all
connections (SDCCH/TCH/PDCH) are remaining on their TRXs and timeslots within the TRXs.
As you may see from SY hopping definition, the frequency change affecting all timeslots on specific TRX.
This fact restricts utilization of SY hopping to TCH TRXs only.

Baseband hopping (BB) implemented on baseband processor level before RF part of the base station. The
baseband processor implements switching every frame between specific connection (SDCCH/TCH/PDCH) and
specific TRX, while each TRX frequency remains the same all the time.
BB hopping allows to involve into the hopping timeslots from 1 to 7 on BCCH TRX.

Hope this helps....if you need more, just ask more specific questions.

Enjoy

Optim
2010-08-16, 09:19 PM
Thanks danikd, I have add thanks and reputation:)
Means we can have hopping in BCCH Trx but not in BCCH time slot (TS=0)?
Best Regards.

danikd
2010-08-16, 10:50 PM
Thanks danikd, I have add thanks and reputation:)
Means we can have hopping in BCCH Trx but not in BCCH time slot (TS=0)?
Best Regards.

Yes, you are right. Use Baseband hopping for such implementation.

There are few things that you should pay attention while dealing with GSM hopping:

Cavity tunable combiners can not be used for SY (Synthesizer) Hopping.
SY hopping can be used only with hybrid combiners.

The hopping gain has its maximum at 8 frequencies (so - hopping list (MAL) longer than 8 frequencies is
useless) this due to GSM interleaver which works over 8 frames.

The typical value for hopping with best possible reuse when you'll use 3-5 frequencies in the MAL.
Once you have more than 3 TRXs per sector, then Baseband hopping become preferable over SY hopping.
For 2 TRXs sector BB is also preferable over SY due to possibility to put almost all voice traffic in hopping
even over 2 frequencies (it is still better than no hopping on BCCH TRX).

Not all vendors are supporting BB hopping in case of GPRS.
More than that once EDGE implemented, then BB hopping required that all TRXs within the cell will be EDGE
capable.

Optim
2010-08-16, 10:58 PM
Thanks:) Kindly can you explain in which cases I have to use SFH or BBH?
In my knowledge we use BBH when we have less frequencies and less traffic! because in case of high cell
configuration there is no enough of frequencies so we prefer to use SFH...plz correct me if I'm wrong:)

dacoder
2010-08-17, 12:51 AM
thanks danikd for the explanation... but I didn't understand the RF and BB hopping part. I got lost especially
in this part "... while all connections (SDCCH/TCH/PDCH) are remaining on their TRXs and timeslots within
the TRXs." Could you please explain it in more detail?

danikd
2010-08-17, 08:34 AM
thanks danikd for the explanation... but I didn't understand the RF and BB hopping part. I got lost especially
in this part "... while all connections (SDCCH/TCH/PDCH) are remaining on their TRXs and timeslots within
the TRXs." Could you please explain it in more detail?

It is pretty easy:

SY Hopping

Each connection (speech for example) assigned to specific TRX on specific timeslots (just for clarification TS
on TRX called also Physical channel). Now the Frequency hopping performed by RF Synthesized in TRX by
changing transmit/receive frequency every TDMA frame. In other words Physical channel always the same
during the conversation. As result from MS point of view - every frame reception/transmission performed on
different frequency.

BB Hopping:

TRX always transmitting the same frequency (it is a stable part), while every TDMA frame BTS processor
switching connection from one TRX to another...in cyclic order (typically) i.e. Frame1 - TS2 on TRX1,
Frame2 - TS2 on TRX2, Frame3 - TS2 on TRX3.....FrameX - TS2 on TRX1.....and etc.
In other words, TRX frequency always the same, but no permanent allocation of Physical channel per
conversation.
As result from MS point of view - every frame reception/transmission performed on different frequency.

Just like this.

Optim
2010-08-17, 10:45 AM
Thanks dankid, just other question: if I have network with most of cells with configuration 2trx by cell and
intersite distance is 500m and total frequencies is 22 frequencies..is better to use SFH or BBH? Thanks

danikd
2010-08-18, 09:00 PM
Thanks dankid, just other question: if I have network with most of cells with configuration 2trx by cell and
intersite distance is 500m and total frequencies is 22 frequencies..is better to use SFH or BBH? Thanks

My personal experience telling me:

If you have good automatic frequency optimization tool, which is based on mobile measurements reports
data, then optimize your frequency allocation and go for baseband hopping.

Do not forget, that 22 ARFCNs is a pretty small amount, hope your Cell Plan (Antenna pattern, Tilt) adjusted
with respect to the frequency band available.