Manufacturing: There may be a manufacturing component to it as well. We know they were rushed out the door without even time for the touchscreen bonding glue to dry. Clearly the Foxconn QA was not followed. If an engineer leaves a thumbprint on an internal antenna it detunes it. Imagine what a rushed assembly with leaky glue would do to the tuning characteristics.
Cannot admit: Apply don't pay their manufacturers enough and circumvent their own QA guidelines to rush product to market. They may appear like greedy bastards.
AT&T: The drop problem is also in a small, small part down to AT&T's 3G network topology. Nowhere near as bad as the old iPhone problem of congesting the signalling channels, this is simply due to the fact that 3G signals are way more sensitive to received signal strength. When you hold it the wrong way not only does the handset not heat the base station well (showing fewer bars on the phone) but it is the network that cannot hear the iPhone that causes the call drops as your entire hand and arm are radiating instead of the antenna. When you broadly detune the antenna with your hand the lower powered 3G signal is simply too feint and distorted to be heard by the base station. It does explain why the locations where the issues appear are random and seemingly not related in all cases to the downlink signal strength shown on the handset. RF signals are like that.
Cannot admit: The issue clearly isn't all to do with AT&T and they blamed them the last time with the 3GS.
1) Ping Test. A simple ping to the nearest visible IP address, usually the GGSN, will give you the round trip time for a session in progress. You are looking for the variability. A simple ping -t command for a few minutes and plot the results in excel. You can vary the packet size, but the two tests below give a more accurate test for throughput. Protip: if you want to measure radio channel activation time too then you need to know a few network parameters, specifically the radio TBF timers. You would only do one ping at an interval greater than the timer so that each new ping needs a new radio resource allocation request. The round trip times for the first ping will always be longer, and recording variability in the allocation requests is useful if you are the network, not so much for users.
2) TCP Test. Use an FTP session download a file of known size to get the actual time taken. Then you need to upload that file back to a separate directory and compare the two (or just see if it opens). You actually have to do the math to get the bits per second, neither the windows or Linux native clients show it correctly. bps = bytes_recieved * 8 / seconds. Protip: you need to test several file sizes to get an accurate picture. I'd suggest one run would up/download several 300k and 1Mb files and one 10Mb file. To complete the test in the field you do need to check the upload is successful using a terminal session, but remember not to have the session open using the test equipment as it will bias the test.
3) UDP Test. For assessing the actual performance of the radio network itself the only test that has any relevance is a unidirectional UDP stream because the radio resources are allocated unidirectionally and have asymmetric speeds. TCP is not a test of the radio network itself as the uplink channel causes throttling on the downlink due to the slower uplink. You need a utility that sends UDP packets of a certain size, and a utility to receive them. Ideally the packets have sequentially numbered content because what you are looking for is out-of-sequence delivery. You measure the bandwidth by sending a known number of packets of a known size and simply subtract the timestamps from the client to get the duration. This has to be tested separately on the uplink and the downlink. To instigate the downlink stream you again need a remote session, ideally not using the test equipment.
Microsoft has always pushed a direct relationship between manufacturers and Operaters and continue to do so with the Windows Phone Series. Unfortunately this is detrimental to pretty much everyone. The usual value chain in the mobile phone industry is that an ODM manufactures the handset and does software integration. An OEM picks up the handset and adds branding, logistics, operator approval, distribution partners and possibly some novel software. The OEM then sells to retail or operators. They also take the monatary risk on forward ordering from the ODM and smooth out peaks and troughs in the device supply to simplify things for the ODM. With a unified UI and hardware specs what incentive is there for the OEM?
When you don't have an OEM in the middle then device approvals take much longer, and bugs slip through. HTC's Nexus One should never have gone to market in such a poor state. 3G is still not working properly. An OEM in the loop would have tested the device on AT&T and T-Mobile before launch. Google don't have the necessary experience to do that, HTC still don't (although after killing off their OEM partners two years ago they SHOULD have by now.
What worries me most is that Microsoft is closing the door on the whole OEM model. This means Operators become more wary of new phones, the money isn't forward loaded into the ODM from distributors to develop the phones in the first place. Who will be paying the NRE on a new handset? Microsoft, the operators, or the ODM? Without any incentive for the OEM to produce a differntated product the whole cycle will fail.
Actually that would be if my app actually ran on this pig. I have to rewrite it all, and all my propriatary corporate integration apps, database backends and productivity apps. Oh and I cannot customise my own theme even? It's turning into a worse lock in than the iPhone.
If I have to rewrite eveny app I use then I may as well port it to Android!
Guess all the stolen UK phones end up in India.
In the corporate space however there are device management solutions available for Windows Mobile, Blackberry and Symbian that have seldom been rolled out at carrier level. These can lock down devices so that malware cannot be installed, and unauthorized applications removed. I cannot see that working as a consumer proposition, it really doesn't work well at the corporate level either. importantly these solutions are all at the IP layer (dumb bitpipe) and don't care how the device connects to the management server. ActiveSync, WiFi, cellular connection (and yes, via SMS too) will all trigger a wiped device or an app uninstall.
Nothing to do with telcos. Move along.
"And remember: Evil will always prevail, because Good is dumb." -- Spaceballs