please report your SPCS CDMA channel(s)...

Msea <[email protected]> wrote in message news:<Yid8b.322903$Oz4.113054@rwcrnsc54>...
> Andrew Shepherd wrote:
>
> > In the CDMA channel list message broadcast on the paging channel, PCS
> > 0575 is the first channel or frequency (F1) listed in Seattle. PCS
> > 0625 is the second frequency (F2) listed. Roughly half of the SPCS
> > mobiles in Seattle will camp on PCS 0575; the other half will idle on
> > PCS 0625. As described in a previous post, the hashing algorithm in
> > conjunction w/ your handset's ESN will be used by your mobile in
> > selection of a CDMA channel upon which to camp. Depending upon your
> > ESN, as well as the number & order of deployed CDMA channels in the
> > market, you would always idle on either F1, or F2, or F3, so on & so
> > forth, in a particular market.
>
> A minor correction to this: the hashing algorithm is based on the
> mobile's MIN, not ESN. So if a customer were to change MINs (i.e.,
> phone numbers) but keep the same handset, it is entirely possible,
> though not certain, that the phone could idle on a different frequency.

Hmmm, I could have sworn that a portion of the ESN, not the MIN, is
the primary variable in the channel selection hashing algorithm. I
will confer w/ my Garg CDMA reference text. But, then again, we have
already been down that road once before...

> Of course, there shouldn't be any performance difference on the
> various frequencies, presuming the network is properly optimized.

Though I cannot speak definitively, at least from empirical
observation, Sprint PCS appears recently to have begun confining
remaining IS-95 mobiles to only one or two CDMA channels in each
market, reserving at least one channel for 1xRTT mobiles only to fully
take advantage of the quick paging channel, reverse pilot channel, &
fast forward-link power control enhancements. Such mobile segregation
could alter the performance & efficiency balance amongst the deployed
frequencies, though the primary effect would likely be to optimize the
Ec/Io of the 1xRTT-only channel for faster packet-data transfer.

Andrew
--
Andrew Shepherd
[email protected]
[email protected]
http://www.ku.edu/home/cinema/

---

› See More: please report your SPCS CDMA channel(s)...

[email protected] (Andrew Shepherd) wrote in message news:<[email protected]>...
> Msea <[email protected]> wrote in message news:<Yid8b.322903$Oz4.113054@rwcrnsc54>...
> > Andrew Shepherd wrote:
> >
> > > In the CDMA channel list message broadcast on the paging channel, PCS
> > > 0575 is the first channel or frequency (F1) listed in Seattle. PCS
> > > 0625 is the second frequency (F2) listed. Roughly half of the SPCS
> > > mobiles in Seattle will camp on PCS 0575; the other half will idle on
> > > PCS 0625. As described in a previous post, the hashing algorithm in
> > > conjunction w/ your handset's ESN will be used by your mobile in
> > > selection of a CDMA channel upon which to camp. Depending upon your
> > > ESN, as well as the number & order of deployed CDMA channels in the
> > > market, you would always idle on either F1, or F2, or F3, so on & so
> > > forth, in a particular market.
> >
> > A minor correction to this: the hashing algorithm is based on the
> > mobile's MIN, not ESN. So if a customer were to change MINs (i.e.,
> > phone numbers) but keep the same handset, it is entirely possible,
> > though not certain, that the phone could idle on a different frequency.
>
> Hmmm, I could have sworn that a portion of the ESN, not the MIN, is
> the primary variable in the channel selection hashing algorithm. I
> will confer w/ my Garg CDMA reference text. But, then again, we have
> already been down that road once before...

Upon further reflection, according to the Garg CDMA text, the HASH_KEY
parameter can be generated from either the 32-bit ESN or the MIN,
rotated & converted to binary, from which the least significant 32 of
34 bits of the manipulated MIN are used for HASH_KEY generation.

So, it would appear that both are correct. However, it may be that
mobile hashing by MIN is far more common in actual deployment than is
hashing by ESN.

Andrew
--
Andrew Shepherd
[email protected]
[email protected]
http://www.ku.edu/home/cinema/

On 8 Sep 2003 13:04:13 -0700, [email protected] (Andrew Shepherd) said:

CH 0025
Prince William County in Northern VA

Andrew Shepherd wrote:

> Upon further reflection, according to the Garg CDMA text, the HASH_KEY
> parameter can be generated from either the 32-bit ESN or the MIN,
> rotated & converted to binary, from which the least significant 32 of
> 34 bits of the manipulated MIN are used for HASH_KEY generation.
>
> So, it would appear that both are correct. However, it may be that
> mobile hashing by MIN is far more common in actual deployment than is
> hashing by ESN.

I've never seen an implementation of hashing based on ESN, but that
certainly doesn't mean it hasn't been done. I don't see any advantage
to ESN-based hashing, but there are certainly advantages to MIN-based
hashing... at least from a troubleshooting/maintenance/optimization
perspective, that is. In order to properly optimize the various RF
carriers, the engineer generally needs a handset for each carrier
(unless cross-carrier assignments are forced, which works, but can be a
bit of a headache and has limits). It would be a real pain if you had
to find a phone with an ESN that hashed to a particular carrier; with
MIN-based hashing, you just program the handset with a phone number that
hashes to the carrier you need it to. And later, when additional
carriers are added, a phone that used to hash to say, carrier 2, may now
hash to carrier 1. With MIN-based, you just change the MIN to get the
phone back on carrier 2. With ESN-based, you'd have to go find a new phone!

From an overall traffic balancing perspective, which is the purpose of
hashing in the first place, I don't think it really matters which
implementation is used. But if for no other reason, I think MIN-based
is used to facilitate network optimization.

0325 in both spartenberg and hilton head island, sc

Msea <[email protected]> wrote in article
<jrc9b.449930$Ho3.74118@sccrnsc03>:
> Andrew Shepherd wrote:
>
> > Upon further reflection, according to the Garg CDMA text, the HASH_KEY
> > parameter can be generated from either the 32-bit ESN or the MIN,
> > rotated & converted to binary, from which the least significant 32 of
> > 34 bits of the manipulated MIN are used for HASH_KEY generation.
> >
> > So, it would appear that both are correct. However, it may be that
> > mobile hashing by MIN is far more common in actual deployment than is
> > hashing by ESN.
>
> I've never seen an implementation of hashing based on ESN, but that
> certainly doesn't mean it hasn't been done. I don't see any advantage
> to ESN-based hashing, but there are certainly advantages to MIN-based
> hashing... at least from a troubleshooting/maintenance/optimization
> perspective, that is. In order to properly optimize the various RF
> carriers, the engineer generally needs a handset for each carrier
> (unless cross-carrier assignments are forced, which works, but can be a
> bit of a headache and has limits). It would be a real pain if you had
> to find a phone with an ESN that hashed to a particular carrier; with
> MIN-based hashing, you just program the handset with a phone number that
> hashes to the carrier you need it to. And later, when additional
> carriers are added, a phone that used to hash to say, carrier 2, may now
> hash to carrier 1. With MIN-based, you just change the MIN to get the
> phone back on carrier 2. With ESN-based, you'd have to go find a new phone!
>
> From an overall traffic balancing perspective, which is the purpose of
> hashing in the first place, I don't think it really matters which
> implementation is used. But if for no other reason, I think MIN-based
> is used to facilitate network optimization.
>

[posted via phonescoop.com]

Andrew,

On my SPHA400 in the DEBUG screen, I see CH0625. This is the only number
multiple of 25 I see here. Does that fit your information?

Daryl
Lexington, Kentucky


>
> I am in the process of updating my Sprint PCS spectrum license
> database to also include deployed CDMA channels & infrastructure
> vendors per each SPCS MTA.
>

Daryl Doss <[email protected]> wrote in message news:<[email protected]>...
> Andrew,
>
> On my SPHA400 in the DEBUG screen, I see CH0625. This is the only number
> multiple of 25 I see here. Does that fit your information?
>
> Daryl
> Lexington, Kentucky

Daryl...norelpref...p lane...

Thank you all for the initial & follow-up CDMA channel reports,
respectively. I fully concur w/ your findings.

Lexington is in the Louisville-Lexington-Evansville MTA026 SID 4148
system for which Sprint PCS holds the PCS B license. Nortel CDMA
infrastructure has been utilized, and valid CDMA channel assignments
w/in the PCS B license are PCS 0425 - PCS 0675. Thus, I will
inaugurate the MTA026 channel deployments w/ PCS 0625.

Prince William County, VA is in the Washington-Baltimore MTA010 for
which SPCS possesses the PCS A license awarded to its APC PCS
predecessor as a Pioneer's Preference before the initial round of PCS
auctions. The valid range of channel assignments for the PCS A
license are PCS 0025 - PCS 0275, and PCS 0025 - PCS 0100 have been
determined to be deployed in the MTA.

Hilton Head & Spartanburg, while both in South Carolina, are actually
in separate MTAs, respectively. Hilton Head is in the Savannah, GA
BTA410 of the Atlanta MTA011. Conversely, Spartanburg is in the
Greenville-Spartanburg, SC BTA177 of the
Charlotte-Greensboro-Greenville-Raleigh MTA006. Perhaps you noticed
differing SPCS SIDs in the two locations: SID 4274 in Hilton Head &
SID 4376 in Spartanburg. Both markets, however, were constructed &
are managed by SPCS network partner AirGate PCS.

SPCS does not hold an MTA-wide PCS A or B 30 MHz license in either the
Atlanta MTA or Charlotte MTA. AT&TWS won at auction the PCS A license
in both MTAs. T-Mobile's Powertel legacy won the PCS B in the Atlanta
MTA, while BellSouth Mobility DCS got the PCS B in the Charlotte MTA.
Instead, SPCS has a complete collection of PCS D 10 MHz licenses for
each & every BTA in both of the MTAs. Additionally, SPCS has
acquired, in post-auction spectrum transactions w/ AT&TWS, PCS A5 10
MHz partitions & disaggregations in key markets: Atlanta, Charlotte,
Fayetteville-Lumberton, Greensboro-Winston-Salem, & Raleigh-Durham.
In those BTAs, SPCS has upped its PCS spectrum ante to 20 MHz
adjacent. However, neither Hilton Head nor Spartanburg are in markets
affected by the spectrum acquired from AT&TWS. Both are limited to
PCS D 10 MHz licenses, for which valid channel assignments are PCS
0325 - PCS 0375. I will add PCS 0325 to the Atlanta MTA data, the
first report from MTA011, as well as include PCS 0325 alongside the
previously reported PCS 0350 in the Charlotte MTA.

Thanks...

Andrew
--
Andrew Shepherd
[email protected]
[email protected]
http://www.ku.edu/home/cinema/

crossvile/cookeville ten area is 100

[email protected] (Andrew Shepherd) wrote in article
<[email protected]>:
> Hello everyone...
>
> After about a six week respite, traveling & moving to a new home, I am
> back, once again ensconced in the alt.cellular family.
>
> I am in the process of updating my Sprint PCS spectrum license
> database to also include deployed CDMA channels & infrastructure
> vendors per each SPCS MTA.
>
> http://people.ku.edu/~cinema/wireless/spcs.html
>
> Through my research, I have been successful in tracking down the
> infrastructure vendor utilized in each MTA. But I could greatly use
> some grassroots assistance in databasing the currently known deployed
> CDMA channel(s) in each SPCS license. I can only personally speak to
> the CDMA channel deployments in my home market, as well as those
> additional markets that I have visited recently. So, if you have
> access to the field test screen on your handset, I would be most
> grateful if you could report to the group (or to me), in reference to
> your location(s), the CDMA channel(s) upon which your handset idles,
> as well as any other CDMA channel(s) to which you have been assigned a
> traffic channel.
>
> Thanks...
>
> Andrew
> --
> Andrew Shepherd
> [email protected]
> [email protected]
> http://www.ku.edu/home/cinema/

[posted via phonescoop.com]

> crossvile/cookeville ten area is 103


what legal purpose does this serve?

IT'S LEGAL?????

[email protected] (Sprintposter) wrote in article
<[email protected]>:
> > crossvile/cookeville ten area is 103
>
>
> what legal purpose does this serve?

[posted via phonescoop.com]

In-Reply-To: <[email protected]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 23
Message-ID: <Nec9b.452261$uu5.80687@sccrnsc04>
NNTP-Posting-Host: 12.230.89.108
X-Complaints-To: [email protected]
X-Trace: sccrnsc04 1063604269 12.230.89.108 (Mon, 15 Sep 2003 05:37:49 GMT)
NNTP-Posting-Date: Mon, 15 Sep 2003 05:37:49 GMT
Organization: Comcast Online
Date: Mon, 15 Sep 2003 05:37:49 GMT
Xref: news.newshosting.com alt.cellular.sprintpcs:113554

Andrew Shepherd wrote:

>> Of course, there shouldn't be any performance difference on the
>>various frequencies, presuming the network is properly optimized.
>
>
> Though I cannot speak definitively, at least from empirical
> observation, Sprint PCS appears recently to have begun confining
> remaining IS-95 mobiles to only one or two CDMA channels in each
> market, reserving at least one channel for 1xRTT mobiles only to fully
> take advantage of the quick paging channel, reverse pilot channel, &
> fast forward-link power control enhancements. Such mobile segregation
> could alter the performance & efficiency balance amongst the deployed
> frequencies, though the primary effect would likely be to optimize the
> Ec/Io of the 1xRTT-only channel for faster packet-data transfer.

True. My statement assumed an implementation of identical protocols
revs on each channel. Of course this may no longer be the case, and
there will likely be a trend toward 1x-only channels. In the end, I
would still argue that at least from a customer's perspective, if the
network is properly optimized, there shouldn't be any performance
difference (e.g., more/less dropped calls, setup failures, etc).