- lower band gives better radio propagation which is more critical for power-limited mobiles
- higher band means more power, so BTS uses this. Also, if mobile uses higher band, then there will be more interference.
Showing posts with label UMTS Interview Questions - Part 1. Show all posts
Showing posts with label UMTS Interview Questions - Part 1. Show all posts
Tuesday, December 14, 2010
Why cells are hexagonal while practically, they are circles?
A honeycomb of hexagons completely tiles an area, indicating complete coverage at the expense of distorting the shape of the cells. Circular tilings either overlap or leave gaps. A hexagon is to be taken as indicating a circular cell where the circle has the same center as the hexagon and a circumference passing through its vertices. The call of a mobile user passing through a grid of circular cells needs to be handed off each time the user leaves one cell and enters another. This has to be done by passing through the area where the cells overlap. At this point, the mobile phone is in the coverage area of two cells, the one it is about to leave and the one it is entering. In this way, the overlapping areas can indicate that the need for a hand-off is imminent, and the cell that is the target for the hand-off.
What is the difference between Load testing and Performace Testing?
The concept and exercise of Load testing is after the performance testing.
Performance testing is something where we find the response time of the appication, look out the Bootlenecks & Tune it. This testing includes in different layers Like Application Layer, Network Layer, Database Layer & OS Layer. After fixing the defects from the Above layers then comes an exercise to perform a Load Testing.
Load testing is done once if the functional and Performance testing is up and done to check the minumum and maximum load the Application can handle.
Performance testing is something where we find the response time of the appication, look out the Bootlenecks & Tune it. This testing includes in different layers Like Application Layer, Network Layer, Database Layer & OS Layer. After fixing the defects from the Above layers then comes an exercise to perform a Load Testing.
Load testing is done once if the functional and Performance testing is up and done to check the minumum and maximum load the Application can handle.
What is verification? validation?
Verification typically involves reviews and meetings to evaluate documents, plans, code,
requirements, and specifications. This can be done with checklists, issues lists, walk-through,
and inspection meetings.
Validation typically involves actual testing and takes place after verifications are completed.
The term 'IV & V' refers to Independent Verification and Validation.
requirements, and specifications. This can be done with checklists, issues lists, walk-through,
and inspection meetings.
Validation typically involves actual testing and takes place after verifications are completed.
The term 'IV & V' refers to Independent Verification and Validation.
Describe About Yourself
- "Describe yourself!", This question is almost invariably asked in the majority of interviews, and just as invariably answered dismally!. What does one say and why do we always seem so flustered by the question?. Because we have always been taught by our parents and respected elders not to boast or talk about ourselves.
With a childhood full of such repressive advice, its not surprising that the majority of us begin the answer with a stammer and a blush, almost instantly changing from flash to foolish and ruining our chances of employment.
So what do we say? Frankly, just answer the question as it comes. Most disconcerted candidates dread this question and begin with a silly "Basically, my name is ...". Why don't we realize that our CV is there right in front of the interviewer, and he knows this already.
By repeating the stuff that fills our CV, we just demonstrate that we are an 'in-the-box' kind of person, with little if any skill in innovation and presentation.
Actually, a question of this kind is an ideal way to plug in everything we want to say about ourselves that we had leave out of the CV. If you have attended a premier institution, say that the institution taught you much more than the degree it awarded o, mention people who influenced o, talk about the books you like reading, your hobbies and your other interests.
Talk about your strengths; perhaps mention an instance when you used your conflict resolution skills or selling skills or whatever. But make certain that it does not sound like blowing your trumpet. Mention these instances as learning.
Tall about your weaknesses, but make sure that they are 'positive' weaknesses. For instance you could say that that you sometimes pay more attention to detail than is warranted. You can openly confess a tendency to be impatient with team members who cannot carry their own weight, or who cannot contribute sufficiently.
But first, think today what you want to say and practice. Remember, if you hesitate about yourself, your interviewers will doubt whether you fit their bill of requirements. After all, if you don't know about you, who does?
With a childhood full of such repressive advice, its not surprising that the majority of us begin the answer with a stammer and a blush, almost instantly changing from flash to foolish and ruining our chances of employment.
So what do we say? Frankly, just answer the question as it comes. Most disconcerted candidates dread this question and begin with a silly "Basically, my name is ...". Why don't we realize that our CV is there right in front of the interviewer, and he knows this already.
By repeating the stuff that fills our CV, we just demonstrate that we are an 'in-the-box' kind of person, with little if any skill in innovation and presentation.
Actually, a question of this kind is an ideal way to plug in everything we want to say about ourselves that we had leave out of the CV. If you have attended a premier institution, say that the institution taught you much more than the degree it awarded o, mention people who influenced o, talk about the books you like reading, your hobbies and your other interests.
Talk about your strengths; perhaps mention an instance when you used your conflict resolution skills or selling skills or whatever. But make certain that it does not sound like blowing your trumpet. Mention these instances as learning.
Tall about your weaknesses, but make sure that they are 'positive' weaknesses. For instance you could say that that you sometimes pay more attention to detail than is warranted. You can openly confess a tendency to be impatient with team members who cannot carry their own weight, or who cannot contribute sufficiently.
But first, think today what you want to say and practice. Remember, if you hesitate about yourself, your interviewers will doubt whether you fit their bill of requirements. After all, if you don't know about you, who does?
Types of Testing
Q. What kinds of testing should be considered?
A. Black box testing - not based on any knowledge of internal design or code.
Tests are based on requirements and functionality.
White box testing - based on knowledge of the internal logic of an application's code.
Tests are based on coverage of code statements, branches, paths, conditions.
Unit testing - the most 'micro' scale of testing; to test particular functions or code modules.
Typically done by the programmer and not by testers, as it requires detailed knowledge of the
internal program design and code. Not always easily done unless the application has a well-designed
architecture with tight code; may require developing test driver modules or test harnesses.
Incremental integration testing - continuous testing of an application as new functionality is added;
requires that various aspects of an application's functionality be independent enough to work separately
before all parts of the program are completed, or that test drivers be developed as needed; done by
programmers or by testers.
Integration testing - testing of combined parts of an application to determine if they function together
correctly. The 'parts' can be code modules, individual applications, client and server applications on a
network, etc. This type of testing is especially relevant to client/server and distributed systems.
Functional testing - black-box type testing geared to functional requirements of an application; this type
of testing should be done by testers. This doesn't mean that the programmers shouldn't check that their
code works before releasing it (which of course applies to any stage of testing.)
System testing - black-box type testing that is based on overall requirements specifications; covers all
combined parts of a system.
End-to-end testing - similar to system testing; the 'macro' end of the test scale; involves testing of
a complete application environment in a situation that mimics real-world use, such as interacting with
a database, using network communications, or interacting with other hardware, applications, or systems
if appropriate.
Sanity testing - typically an initial testing effort to determine if a new software version is performing
well enough to accept it for a major testing effort. For example, if the new software is crashing systems
every 5 minutes, bogging down systems to a crawl, or destroying databases, the software may not be in a
'sane' enough condition to warrant further testing in its current state.
Regression testing - re-testing after fixes or modifications of the software or its environment.
It can be difficult to determine how much re-testing is needed, especially near the end of the
development cycle. Automated testing tools can be especially useful for this type of testing.
Acceptance testing - final testing based on specifications of the end-user or customer, or based on use
by end-users/customers over some limited period of time.
Load testing - testing an application under heavy loads, such as testing of a web site under a range of
loads to determine at what point the system's response time degrades or fails.
Stress testing - term often used interchangeably with 'load' and 'performance' testing. Also used to
describe such tests as system functional testing while under unusually heavy loads, heavy repetition
of certain actions or inputs, input of large numerical values, large complex queries to a database system, etc.
Performance testing - term often used interchangeably with 'stress' and 'load' testing. Ideally 'performance'
testing (and any other 'type' of testing) is defined in requirements documentation or QA or Test Plans.
Usability testing - testing for 'user-friendliness'. Clearly this is subjective, and will depend on the
targeted end-user or customer. User interviews, surveys, video recording of user sessions, and other
techniques can be used. Programmers and testers are usually not appropriate as usability testers.
Install/uninstall testing - testing of full, partial, or upgrade install/uninstall processes.
Recovery testing - testing how well a system recovers from crashes, hardware failures, or other
catastrophic problems.
Security testing - testing how well the system protects against unauthorized internal or external access,
willful damage, etc; may require sophisticated testing techniques.
Compatibility testing - testing how well software performs in a particular hardware/software/operating
system/network/etc. environment.
Exploratory testing - often taken to mean a creative, informal software test that is not based on formal
test plans or test cases; testers may be learning the software as they test it.
Ad-hoc testing - similar to exploratory testing, but often taken to mean that the testers have significant
understanding of the software before testing it.
User acceptance testing - determining if software is satisfactory to an end-user or customer.
Comparison testing - comparing software weaknesses and strengths to competing products.
Alpha testing - testing of an application when development is nearing completion; minor design changes
may still be made as a result of such testing. Typically done by end-users or others, not by programmers
or testers.
Beta testing - testing when development and testing are essentially completed and final bugs and problems
need to be found before final release. Typically done by end-users or others, not by programmers or testers.
Mutation testing - a method for determining if a set of test data or test cases is useful, by deliberately
introducing various code changes ('bugs') and retesting with the original test data/cases to determine if
the 'bugs' are detected. Proper implementation requires large computational resources.
A. Black box testing - not based on any knowledge of internal design or code.
Tests are based on requirements and functionality.
White box testing - based on knowledge of the internal logic of an application's code.
Tests are based on coverage of code statements, branches, paths, conditions.
Unit testing - the most 'micro' scale of testing; to test particular functions or code modules.
Typically done by the programmer and not by testers, as it requires detailed knowledge of the
internal program design and code. Not always easily done unless the application has a well-designed
architecture with tight code; may require developing test driver modules or test harnesses.
Incremental integration testing - continuous testing of an application as new functionality is added;
requires that various aspects of an application's functionality be independent enough to work separately
before all parts of the program are completed, or that test drivers be developed as needed; done by
programmers or by testers.
Integration testing - testing of combined parts of an application to determine if they function together
correctly. The 'parts' can be code modules, individual applications, client and server applications on a
network, etc. This type of testing is especially relevant to client/server and distributed systems.
Functional testing - black-box type testing geared to functional requirements of an application; this type
of testing should be done by testers. This doesn't mean that the programmers shouldn't check that their
code works before releasing it (which of course applies to any stage of testing.)
System testing - black-box type testing that is based on overall requirements specifications; covers all
combined parts of a system.
End-to-end testing - similar to system testing; the 'macro' end of the test scale; involves testing of
a complete application environment in a situation that mimics real-world use, such as interacting with
a database, using network communications, or interacting with other hardware, applications, or systems
if appropriate.
Sanity testing - typically an initial testing effort to determine if a new software version is performing
well enough to accept it for a major testing effort. For example, if the new software is crashing systems
every 5 minutes, bogging down systems to a crawl, or destroying databases, the software may not be in a
'sane' enough condition to warrant further testing in its current state.
Regression testing - re-testing after fixes or modifications of the software or its environment.
It can be difficult to determine how much re-testing is needed, especially near the end of the
development cycle. Automated testing tools can be especially useful for this type of testing.
Acceptance testing - final testing based on specifications of the end-user or customer, or based on use
by end-users/customers over some limited period of time.
Load testing - testing an application under heavy loads, such as testing of a web site under a range of
loads to determine at what point the system's response time degrades or fails.
Stress testing - term often used interchangeably with 'load' and 'performance' testing. Also used to
describe such tests as system functional testing while under unusually heavy loads, heavy repetition
of certain actions or inputs, input of large numerical values, large complex queries to a database system, etc.
Performance testing - term often used interchangeably with 'stress' and 'load' testing. Ideally 'performance'
testing (and any other 'type' of testing) is defined in requirements documentation or QA or Test Plans.
Usability testing - testing for 'user-friendliness'. Clearly this is subjective, and will depend on the
targeted end-user or customer. User interviews, surveys, video recording of user sessions, and other
techniques can be used. Programmers and testers are usually not appropriate as usability testers.
Install/uninstall testing - testing of full, partial, or upgrade install/uninstall processes.
Recovery testing - testing how well a system recovers from crashes, hardware failures, or other
catastrophic problems.
Security testing - testing how well the system protects against unauthorized internal or external access,
willful damage, etc; may require sophisticated testing techniques.
Compatibility testing - testing how well software performs in a particular hardware/software/operating
system/network/etc. environment.
Exploratory testing - often taken to mean a creative, informal software test that is not based on formal
test plans or test cases; testers may be learning the software as they test it.
Ad-hoc testing - similar to exploratory testing, but often taken to mean that the testers have significant
understanding of the software before testing it.
User acceptance testing - determining if software is satisfactory to an end-user or customer.
Comparison testing - comparing software weaknesses and strengths to competing products.
Alpha testing - testing of an application when development is nearing completion; minor design changes
may still be made as a result of such testing. Typically done by end-users or others, not by programmers
or testers.
Beta testing - testing when development and testing are essentially completed and final bugs and problems
need to be found before final release. Typically done by end-users or others, not by programmers or testers.
Mutation testing - a method for determining if a set of test data or test cases is useful, by deliberately
introducing various code changes ('bugs') and retesting with the original test data/cases to determine if
the 'bugs' are detected. Proper implementation requires large computational resources.
Friday, August 21, 2009
Code Allocation in UMTS
Code Allocation:
Channelization codes, also called Spreading codes, satisfy two purpose: first, to spread the signal energy evenly over the bandwidth below the noise level ; and second, to separate the transmissions from a single source. These are based on the Orthogonal Variable Spreading Factor (OVSF) technique. Orthogonal codes are the codes that have the property that any two codes in the family, except for those that are connected to it and to the right, when multiplied together bitwise and the results of these multiplication are summed, the result is zero. That is, in mathematical way, codes in the family correlated completely with themselves and have zero crosscorrelation with any of the other codes. However, the zero crosscorrelation property of orthogonal codes works only if the codes are time aligned.
In Uplink, channelization codes are used to distinguish data and control channels from the same UE.
In Downlink, channelization codes are used to distinguish signals for different channels and users within a cell.
Scrambling codes, also called PN scrambling codes, are used to separate users and different base stations. They are used on top of spreading and it does not change the signal bandwidth. Also, scrambling codes are found to have better crosscorrelation property as compared to channelization codes even when codes are not time aligned. PN sequence or Pseudorandom number sequence is a sequence of numbers, algorithmically generated, that are distributed evenly throughout the number space but with no discernible pattern to their distribution.
In Uplink, scrambling codes are used to distinguish UE terminals.
In Downlink, scrambling codes are used to distinguish different cells.
ImportantInformation:
- Each signal is spread with the spreading code, i.e. channelization code x scrambling code
- Uplink codes are not cell specific. Channelization Code is picked by mobile and Scrambling code assigned by RNC. They can be decoded anywhere
- Downlink code is cell specific and UE must decode each of them individually
In Downlink, channelization codes are used to distinguish signals for different channels and users within a cell.
Scrambling codes, also called PN scrambling codes, are used to separate users and different base stations. They are used on top of spreading and it does not change the signal bandwidth. Also, scrambling codes are found to have better crosscorrelation property as compared to channelization codes even when codes are not time aligned. PN sequence or Pseudorandom number sequence is a sequence of numbers, algorithmically generated, that are distributed evenly throughout the number space but with no discernible pattern to their distribution.
In Uplink, scrambling codes are used to distinguish UE terminals.
In Downlink, scrambling codes are used to distinguish different cells.
ImportantInformation:
- Each signal is spread with the spreading code, i.e. channelization code x scrambling code
- Uplink codes are not cell specific. Channelization Code is picked by mobile and Scrambling code assigned by RNC. They can be decoded anywhere
- Downlink code is cell specific and UE must decode each of them individually
Wednesday, August 19, 2009
Power Control in UMTS
Power control is necessary to keep the transmitted signal power level under control so as to minimize the interference and keep the quality of signal to a desired level. The main functions are:
1. Closed-loop power control
· Outer-loop power control
- Uplink outer-loop power control
- Downlink outer-loop power control
· Inner-loop power control
- Uplink inner-loop power control
- Downlink inner-loop power control
2. Open-loop power control
· Uplink open-loop power control
· Downlink open-loop power control
Closed-loop power control is the power control mechanism used in UMTS to solve near-far problem, minimize interference and to keep the signal quality to optimum level. Closed-loop power control is used in uplink (UL) as well as downlink (DL). However, the motive in both the cases are different. In uplink, signals from different UEs reach NodeB with different power strength, thus causing the stronger signal blocking the weaker one, resulting in near-far effect. In downlink, there is no near-far effect, but the UEs near the cell-edge or in high interference region may need extra power to overcome the increased other cell interference and weak signal due to Rayleigh fading.
Closed-loop power control can be divided into outer-loop and inner-loop power control. In case of uplink, the RNC manages the outer-loop and Node B manages the inner-loop and for downlink, UE manages the outer-loop and Node B manages the inner-loop.
Inner-loop power control (also called fast closed-loop power control), operates at 1500 times per sec (1.5 kHz) [From where did this value of 1.5 kHz come from? Answer: A UMTS 10 ms frame consists of 15 TPC commands. This results in a power control frequency of 1500 Hz (15/10ms)] and relies on the feedback information from the opposite end of the link (or channel) to maintain the signal to interference (noise) ratio to a target level set by the outer-loop power control. The transmission power is increased or decreased by a certain fixed step size depending on whether the received SIR is below or above the target SIR. Precise power control can lead to optimum use of bandwidth resulting in increase cell capacity.
The UL inner-loop power control lets the UE adjust its output power in accordance with one or more TPC commands received in the downlink direction. Remember the increase and decrease in power is limited by upper and lower bounds as defined in 3GPP TS 25.101. The upper bound, i.e. UE maximum output power, is set depending on the Power class of UE. This can also be set below the maximum capability of the UE through signaling when the link is established. The lower bound, i.e. UE minimum output power defined as the mean power in one timeslot (TS), and shall be less than -50 dB.
The DL inner-loop power control is used to control the transmission power of downlink channels at Node B as per the TPC commands received from UE. However, in some situations Node B may ignore the increase/decrease these TPC commands. For example, in case of congestion (high load scenario), the Node B can ignore the TPC commands from UE.
Outer-loop power control is used to set the target quality value for inner-loop power control, i.e it adjusts the target SIR in Node B which is used during inner-loop power control. Now the question is why do we need to adjust the target SIR? Outer-loop power control tries to keep the quality of a connection to desired value. Too high quality will waste the resources.
Open-loop power control is used to set the initial power of UE (in random access) and downlink channels. The TPC commands used in inner-loop power control are relative, so it needs a starting point and this is defined by open-loop power control. Also, this is useful in setting the power level in case of common shared channels, where it is difficult to send each UE the necessary TPC commands. In case of uplink, UE and broadcasted cell/system parameters are used to set initial access power on RACH. And in case of downlink, the measurement report of UE is used to set the initial power of downlink channels.
The open loop power control tolerance is ±9dB under normal conditions and ±12dB under extreme conditions.
[References: TS 25.214, TS 25.215, Section 7.2.4.8 of TS 25.401]
Friday, August 14, 2009
Wednesday, July 29, 2009
Why Open-loop power control mechanism does not solve "near-far problem"?
The Open-loop power control mechanism, used in CDMA based systems, requires the transmitiing entity (mobile station) to monitor the received signal strength and channel interference in the downlink and adjust its transmission power accordingly. Now uplink and downlink signals use different frequencies and there is large frequency separation of uplink and downlink bands in UMTS FDD mode (uplink frequency band is 1885–2025 MHz and downlink frequency band is 2110–2200 MHz). As such, uplink and downlink fast fading (on different frequency carriers) are not correlated. The downlink signal may suffer from different sets of diffractions and reflections that uplink signal may not encounter, thereby not giving a correct result. This is the reason that "open-loop power control" can not be used to solve "near-far problem". Usually this mechanism gives correct result only on average. Therefore open loop power control is used mainly to provide initial power setting for the initial access of system (RACH).
The open loop power control tolerance is ±9dB under normal conditions and ±12dB under extreme conditions.
Reference: 3GPP TS 25.101.
The open loop power control tolerance is ±9dB under normal conditions and ±12dB under extreme conditions.
Reference: 3GPP TS 25.101.
Monday, July 27, 2009
What is near-far problem?
Consider that there are 2 mobile stations (MS) transmitting at equal powers, but one is nearer to the base station (BS) compared to the other. The BS will receive more power from the nearer MS and this makes the farther MS difficult to understand. As we know, the signal of one MS is the noise for another MS and vice-versa. So the Signal-to-noise ratio (SNR) for the farther MS is much lower. If the nearer MS transmits a signal that is orders of magnitude higher than the farther MS then the SNR for farther MS may be below detectability threshold and it would seem that the farther MS is not at all transmitting. This situation is called "near-far problem" and is less pronounced in GSM than CDMA-based systems as the MS transmit at different frequencies and timeslots in case of GSM.
To overcome this problem, a power control mechanism is used so as closer MSs are commanded to use less power so that the SNR for all MSs at the BS is roughly the same.
To overcome this problem, a power control mechanism is used so as closer MSs are commanded to use less power so that the SNR for all MSs at the BS is roughly the same.
Subscribe to:
Posts (Atom)
View Pankaj Kumar's profile