- 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.
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.
What is Erlang?
1. Erlang:
$ dimensionless quantity
$ continuous use of one circuit for one hour.
$ Types of Erlang traffic model:
i. Erlang B
This is the most commonly used traffic model, and is used to work out how many lines are
required if the traffic figure (in Erlangs) during the busiest hour is known. The model
assumes that all blocked calls are immediately cleared.
NOTE: Blocked Calls - call which are not successful due to busy traffic (busy signal)
ii. Extended Erlang B
This model is similar to Erlang B, but takes into account that a percentage of calls are
immediately represented to the system if they encounter blocking (a busy signal). The retry
percentage can be specified.
iii. Erlang C
This model assumes that all blocked calls stay in the system until they can be handled.
This model can be applied to the design of call center staffing arrangements where, if calls
cannot be immediately answered, they enter a queue.
2. Holding Time
3. Blocking Rate
$ The probability of blocking calls out of a specified no.
4. CAPS
$ Call Attempts per second
$ CAPS = Erlangs/Holding Time
5. BHCA
$ Busy Hour Call Attempts
$ BHCA = CAPS * 3600
============
= ERLANG B =
============
1. The Erlang B traffic model is used by telephone system designers to estimate the number of lines
required for PSTN connections (CO trunks) or private wire connections. The three variables involved
are Busy Hour Traffic (BHT), Blocking and Lines:
a. Busy Hour Traffic (in Erlangs) is the number of hours of call traffic there are during the
busiest hour of operation of a telephone system.
b. Blocking is the failure of calls due to an insufficient number of lines being available.
E.g. 0.03 mean 3 calls blocked per 100 calls attempted.
c. Lines is the number of lines in a trunk group.
2. If you know two of the figures, you can work out the third as follows:
a. Click on the Unknown radio button representing the unknown variable.
b. Enter the 2 known figures into their edit boxes.
c. Press Calc and the third figure will be calculated and displayed in the remaining edit box.
3. For example, if from your call logger, you know that the Busy Hour Traffic is 10 Erlangs, and you
want to know how many lines are required in this trunk group if you are prepared to tolerate 2 calls
being blocked in every 100 calls attempted then:
a. Press the Lines Unknown radio button (this is selected by default).
b. Enter 10 in the BHT edit box.
c. Enter 0.02 in the Blocking edit box.
d. When you press the Calc button, 17 will be displayed in the Lines edit box indicating that 17 lines would be required in this trunk group.
$ dimensionless quantity
$ continuous use of one circuit for one hour.
$ Types of Erlang traffic model:
i. Erlang B
This is the most commonly used traffic model, and is used to work out how many lines are
required if the traffic figure (in Erlangs) during the busiest hour is known. The model
assumes that all blocked calls are immediately cleared.
NOTE: Blocked Calls - call which are not successful due to busy traffic (busy signal)
ii. Extended Erlang B
This model is similar to Erlang B, but takes into account that a percentage of calls are
immediately represented to the system if they encounter blocking (a busy signal). The retry
percentage can be specified.
iii. Erlang C
This model assumes that all blocked calls stay in the system until they can be handled.
This model can be applied to the design of call center staffing arrangements where, if calls
cannot be immediately answered, they enter a queue.
2. Holding Time
3. Blocking Rate
$ The probability of blocking calls out of a specified no.
4. CAPS
$ Call Attempts per second
$ CAPS = Erlangs/Holding Time
5. BHCA
$ Busy Hour Call Attempts
$ BHCA = CAPS * 3600
============
= ERLANG B =
============
1. The Erlang B traffic model is used by telephone system designers to estimate the number of lines
required for PSTN connections (CO trunks) or private wire connections. The three variables involved
are Busy Hour Traffic (BHT), Blocking and Lines:
a. Busy Hour Traffic (in Erlangs) is the number of hours of call traffic there are during the
busiest hour of operation of a telephone system.
b. Blocking is the failure of calls due to an insufficient number of lines being available.
E.g. 0.03 mean 3 calls blocked per 100 calls attempted.
c. Lines is the number of lines in a trunk group.
2. If you know two of the figures, you can work out the third as follows:
a. Click on the Unknown radio button representing the unknown variable.
b. Enter the 2 known figures into their edit boxes.
c. Press Calc and the third figure will be calculated and displayed in the remaining edit box.
3. For example, if from your call logger, you know that the Busy Hour Traffic is 10 Erlangs, and you
want to know how many lines are required in this trunk group if you are prepared to tolerate 2 calls
being blocked in every 100 calls attempted then:
a. Press the Lines Unknown radio button (this is selected by default).
b. Enter 10 in the BHT edit box.
c. Enter 0.02 in the Blocking edit box.
d. When you press the Calc button, 17 will be displayed in the Lines edit box indicating that 17 lines would be required in this trunk group.
Subscribe to:
Posts (Atom)
View Pankaj Kumar's profile