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.
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) connectionThe 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.Ericsson’s 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 NodeBo RNC
UE: User Equipment CN: Core Network
o MSC: for switched voice serviceso 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.
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)?
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.
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.
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)?
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.
danikd2010-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 timeslot4. 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
Optim2010-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.
danikd2010-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.
Optim2010-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:)
dacoder2010-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?
danikd2010-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.
Optim2010-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
danikd2010-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.
