I wonder what results are you expecting from the actual majority of handsets. As you must already know, most mobile traffic happens to be handled by the wap gateway in the operator. So basically what you see on your servers (where your test pages are hosted) is the behavior that the wap gateway has about fetching URLs in a page, not the actual phone’s. Let’s assume a phone normal browser does open several concurrent connections, all of them will hit the wap gateway, who will consider doing whatever is best for handling overall traffic - not just this specific phone’s requests. So the point is, the actual phone’s bejavior is obscured by the existence of a wap gateway in the middle. Felt the need to clarify this, wap gateway and proxies to a minor extent is IMHO a major short-comming for this kind of tests. It will only work with smartphones and networks that allow phones to reach the internet directly, rather than actually normal networks (every operator has a wap gateway and most traffic is handled by such network element).
Please kindly reply, I’m intrigued. marionetazorz at yahoo dot com.

Yes, the proxies are going to be challenging. We’re actually looking for them in the apache logs. It was one of the notes we made in our methodology document about the potential short-comings of this way of testing.

So we recognize that as a problem and are going to try to correct for it when we analyze the data.

Thanks for testing and for the information on Japanese handsets.

I live in Japan and the KDDI/Au handset I use here has two browsers on it: One is a version of Opera 8.6, and the other is v6 of the Openwave browser. Both of them rely on proxies, and I think the same is true for preinstalled browsers on handsets for other carriers here (DoCoMo, Softbank, and Willcom).