The above Dilbert strip is a reality for a lot of us, everyday. There are many bugs in each product and we only have a limited amount of time and resources that can be dedicated to fixing bugs. The '5 stages of bug fixing' was presented in one of the Cambridge Wireless events not long ago. I am not sure if allowed to mention by whom, so here it is anonymously.
The five stages of Bug Fixing
If you think about it from the Tester's point of view, this is what he prays for everyday. See the old post here.
Some months back R&S held a technical forum where there were many interesting talks and presentations. They have now uploaded video of all these presentations that can be viewed on their website (no embedding allowed).
 gives the requirements related to the above KPI's. Take for instance Accessibility,  defines the requirements as follows:
Business level requirements: If an end user cannot access a service it is hard to charge for the service. Also, if it happens often that an end-user cannot access the provided service, the end-user might change wireless subscription provider, i.e. loss of income for the network operator. Hence, to have a good accessibility of the services is important from a business point of view. This measurement assists the network operator with information about the accessibility provided to their customers.
Specification level requirements: The accessibility of an end-user application covers a wider area than just the E-UTRAN part. Hence it is important to realize that a KPI for this in E-UTRAN shall be limited to the parts that E-UTRAN has control of, i.e. the E-UTRAN KPI shall be defined so that it indicates the E-UTRAN contribution to the end-user impact, NOT attempt to take responsibility of the whole end-to-end part of service accessibility.
The service provided by E-UTRAN for this KPI shall be E-RAB. It shall be possible to measure the accessibility of E-RABs in E-UTRAN. Accessibility measurement should be available as a success rate for the attempts.
As for defining an attempt, it shall be considered an attempt first when the eNodeB can be certain that is a request for an E-RAB. As for defining a success, it shall be considered a success when the eNodeB have completed its task to setup resources and the result of the E-RAB establishment can be informed to the requester of the E-RAB. The KPI shall be available per QoS group.
Use case description: In providing end-user services to wireless end-users, the first step is to get access to the wireless service. First after access to the service has been performed, the service can be used. If an accessibility measurement is not considered OK, then the network operator can investigate which steps that are required to improve the accessibility towards their customers. This measurement should be used for observing the impact of E-UTRAN on end-users service accessibility.
From the above, we can create certain tests to test the Accessibility KPI. Example cases as follows:
1. RRC Connection Setup for Registration success rates
2. RRC Connection Setup for Services success rates
3. Initial E-RAB Setup Success rates
4. Successive E-RAB Setup Success rates
5. Call (VoIP) setup success rates
 3GPP TS 32.450: Key Performance Indicators (KPI) for Evolved Universal Terrestrial Radio Access Network (E-UTRAN): Definitions
 3GPP TS 32.451: Key Performance Indicators (KPI) for Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Requirements
More example of KPI's is available from this document:
@Peter_Whale: really stimulating 2 days. Head full of insights. Now the fun of connecting the dots; finding the takeaways; turning ideas into action
@vectafrank: well done@cambwireless - best yet!
@cambwireless = Cambridge Wireless official twitter account
@zahidtg = Zahid Ghadialy
@marekpawlowski = Marek Pawlowski
@Qualcomm_UK = Qualcomm UK
@JawadAbbassi = Jawad J. Abbassi
@najeebster = Najeeb Khan
@geoffmccormick = geoff mccormick
@ndahad = Nitin Dahad
@Alliantus = Kevin Coleman
@dw2 = David Wood
@RichardTraherne = Richard Traherne
@bensmithuk = Ben Smith
@roryponeill = Rory O'Neill
@rob_symes = Rob Symes
@BrianIsATwit = Brian Robertson
@eurocomms = eurocomms
@rupert_baines = Rupert Baines
@mattablott = Matt Ablott
@sdfriedner = Saul Friedner
@Brill_Brum = Stu
@rpctelecom = RPC Telecom
@evolaris = evolaris
@RichardTraherne = Richard Traherne
@Peter_Whale = Peter Whale
@vectafrank = Frank Morris
In case you enjoyed my effort in collecting the tweets please let me know by clicking the 'Very Useful' checkbox below.
xoxoxoxoxoxoxoxo Additional Information xoxoxoxoxoxoxoxo
As I mentioned in the beginning, Paul Taylor, Engineering Manager, Google, gave us a presentation and requested that we dont share information because of the Google developer conference. As this is over now, I am sharing the pics I took for his presentation. If anyone from Google raises an objection, I will take them down :-)
This was presented by Giulio Maggiore, Telecom Italia, ETSI TC INT Chairman in the 2nd FOKUS FUSECO Forum 2011, Berlin 17-18 Nov. 2011
From the ETSI leaflet (note that this is quite old information but still on the ETSI website here):
IMS interoperability is a key issue for boosting IMS (IP Multimedia Subsystem) roll-out and more specifically network interconnection between operators. Only through thorough testing in practical scenarios can operators ensure operational excellence in a multi-vendor and multi-provider environment.
IMS comprises a set of specifications designed to enable network operators to implement IP-based networks that can carry services for both fixed and mobile customers simultaneously.
IMS was developed originally in the mobile world (specifically in the specifications created by the 3rd Generation Partnership Project, 3GPP), and was adopted for fixed networks by ETSI’s TISPAN Technical Committee (Telecoms & Internet Converged Services & Protocols for Advanced Networks).
However this promise of advanced communications over the next generation network will only be delivered if those same networks can interconnect.
ETSI is bridging the existing gap between 3GPP IMS Core Network standards and the initial industry IMS implementations through the organization of IMS interoperability events in connection with ETSI’s Centre for Testing & Interoperability (CTI) and Plugtests™ interoperability testing service.
Our Technical Committee for IMS Network Testing (TC INT) is actively establishing close contact with a number of industry fora and organizations dealing with IMS interoperability, including 3GPP, GSMA, MSF (Multi Service Forum), IMS Forum and the ITU-T. TC INT develops IMS test specification according to conformance, network integration and interoperability testing methodologies. Other ongoing work includes development of tests for Supplementary Services based on regulatory requirements and IMS tests with legacy networks (e.g. SIP-I).
ETSI has already held two IMS interoperability events. The first examined interconnection aspects of 3GPP IMS Release 6, including such issues as basic call on the Mw interface. The second event had a wider scope that included the testing of 3GPP IMS Release 7 interworking, roaming, border control, and integration of application servers executing selected Multimedia Telephony supplementary services.
Future ETSI activities and events will go even deeper towards bridging 3GPP IMS standards and industry implementations. These will include the organization of further IMS interoperability events designed to boost the roll-out and take-off of IMS services and operators’ network interconnections.
We all remember the so called 'Antennagate' where the iPhone 4 loses coverage due to the way its held. As can be seen from the above picture, there are a lot of antennas already in the phones and yes they are on the increase with LTE and other technologies being added all the time.
Apple admitted the fault and claimed to have fixed the problem but its well known in technical circles that the fix is more of a software hack which doesn't really fix the problem just pretends to fix it. That is why the networks dread it and you can find awful lot of information on the web about the problems.
In a recent Cambridge Wireless event, I heard an interesting talk from Trevor Gill of Vodafone and one of the slides that caught my attention was the impact of these poorly designed phones on the network. The slide is embedded below.
It is estimated that the RF performance of iPhone4 is around 6dB worse than most other 3G phones. What this means is that you may be getting 4 bars of reception on your other phone where iPhone4 may be having only 1 or 2 bars or reception. So if the reception is poor with 1 or 2 bars, iPhone4 may have no reception at all.
To fix this problem, either the networks can increase the number of base stations to double the existing amount which is a huge cost to the networks and extra radiation or the phones can fix it themseles by having an extra antenna. In fact as the slide says, extra antenna on each phone would translate to increase in network capacity by 20-40%, cell area by 30% and cell edge throughput by 40-75%.
One final thing that I want to mention is that testing (RF, RRM, Conformance, etc.) are mandated by the networks for most phones but they overlook the testing procedure for phones like iPhone. What this means is that they do get a lot more new customers but they get new sets of problems. If these problems are not handled well, the impression they give is that the particular network is rubbish. Another thing is that the devices use a certain build/prototype for testing but the one that they release may contain other patches that can cause chaos. One such problem was Fast Dormancy problem that I have blogged about here.
Hopefully the networks will be a bit more careful and will put quality before quantity in future.