>> I'd even like to see a fewer wireless carriers (consider that each for carrier are spending billions of dollars to roll out what amount to essentially identical network infrastructure often even from the same vendors)
> The identical network infrastructure argument only works if you assume it's a big part of the cost. I don't think that's true, only a fraction of your cell phone bill is spent building or maintaining the network.
> The tiny cost savings we would get by eliminating competition in Wireless aren't worth the huge increases in cost we'd undoubtedly have to pay in extra profit to those same organizations.
> We only have to look at Cable / DSL to see how that ends. Or look at wireless carrier pricing before T-Mobile woke up and actually started to compete. It's not a coincidence that Sprint, AT&T and Verizon all dropped their prices as soon as T-Mobile woke up. They aren't eating those costs, every non-Sprint carrier can drop prices and still record millions of dollars in profit, even with their existing spectrum footprint, because their primary infrastructure costs are actually very low in comparison to the rates they charge for service.

You missed the other argument I made, you know at the bottom. If pricing was regulated - as in the old days, based on rate of return - this strategy would work, if the carriers are left up to their own devices, they will just try to extract the greatest dollar they can out of the rate paying public.

- - -
>> Having been in the industry for about 2 years now, looking at the spectrum, I believe that we have enough for two, possibly three really competitive national wireless carriers - as in a complete nation wide footprint
> I don't know where you get that. We have four carriers now, and none of them are hurting for spectrum, except in a handful of specific markets that are interrupted by other players or outside forces.
> Seattle, for instance, has plenty of spectrum. However, some of it is being hoarded for speculation (Allen/Vulcan Inc sitting on 700a in Seattle and Portland comes to mind, or Dish sitting on nationwide AWS, or Sprint sitting on tons of 2.5ghz). If the unused spectrum becomes used, and the smaller carriers like US Cellular / Leap / Cincinnati Bell merge into T-Mobile / Sprint, everyone has a pretty decent playing field in every market nationwide, and there's plenty of spectrum for 4 nationwide carriers nationwide.

2.5 works great in a dense metro area, where you have the customers required to support the density to pay for the much higher required number of cell sites, clearwire has done wonders with it. 2.5 doesnt work anywhere near as well outside the urban core. I read a study that right now there is 350 mhz of spectrum nation wide for cellular/mobile - I did a back of the napkin and figure you need about 100 mhz in a market (the largest ones) to make it really viable (by viable I mean wired equivalent speeds).

I personally believe in something of a use it or loose it concept for spectrum, either offer service on it, or you loose the right to do so, it's a public resource, not private property.

- - -
>> but consider the current for a moment, that Sprint in Seattle on 1900 mhz only has 20 mhz duplex, and nothing on 800 at all - this is excluding the acres on 2.5, because of the obvious limitations of use with atmospheric issues.
> If your in the industry, you know that Sprint's problems are not spectrum related, they're all execution related. Sprint's got plenty of capacity on spectrum, they are just too cheap to deploy it properly. Seattle is a perfect example of this.
> There are no "atmosphereic issues" with 2.5. There's no issues with 2.5, period. The only issue is Sprint trying to pretend 2.5ghz is 800mhz, and deploying 2.5 as if it is as low as 800mhz. The spectrum is not at fault, Sprint is.
Seattle's a major market, there's no reason downtown Seattle doesn't have Sprint small-cell 2.5 radios on every street intersection in the whole city - it would allow Sprint to offer multiple 20x20 LTE carriers on 2.5ghz to work properly, even indoors, throughout the majority of the city. Sprint phones shouldn't be using data over PCS in the urban area, except in the most strenuous of situations (deep underground).
> Seattle's density supports this deployment, the tech is easily available, off the shelf equipment. Sprint's just not executing properly. Hopefully, SoftBank forces them to wake up and care about fixing their service.

There are most certainly more atmospheric issues with 2.5 compared to 1900, in so much as higher frequency brings more atmospheric attenuation. That aside - Sprint has not even begun 2.5 deployment yet, not even close, none of the NV sites have 2.5 on the tower, and the only 2.5 is the legacy clearwire network, and if you look at the NV documentation thats been leaked/released it shows that Sprint is expecting a lower overall footprint for 2.5 compared to either 1900 or 800 (in the markets that have enough 800 mhz spectrum to be viable) - without the PCS G-Block Sprint would have a hell of a time deploying LTE.

Another factor complicating the LTE deployment, I've been told that EV-DO Carrier demand is well outstripping LTE demand - even in areas where LTE is fully turned up - I suspect this is because of the demand MNVO's place on Sprints network - I was also told that something like 20-40% of the devices on the network are 1x only (I wish I could remember the exact number, I know it was large enough to surprise the hell out of me).

Supposedly microcells are part of the future planning for Sprint, but nothing is past the post yet, which will solve the problems in the downtown core. The problem of course is out in the suburbs which is where the majority of the population lives - the density is simply not present to make microcells pay, you need more spectrum at 1900 or 800 to really make it fly, and even if you had more 1900, in many places you'd still need more infill sites to make it really work.

For what its worth, no one up here is doing wide deployment of microcells, unless you count all the in-building systems out there, they are sort of the exception.