VERY disappointed with NV 800 Voice

[prophead]

I am in the Central Pa Shentel Market and about a week ago Sprint pushed a PRL update that made 800 MHZ Voice publicly available. They are broadcasting it on SID 22424 (I thought Central PA is supposed to be 22425?)

 

The company I work for migrated from Nextel to Sprint in January and we have lots of issues with dropped calls. My boss has been ready to throw them out months ago but I have convinced him to give it till at least June 30, explaining the NV process and how 800 MHZ should greatly improve that.

 

Now it here and it doesn't work...

 

It seems the PRL Sprint pushed out prioritizes SID 4168 (1900 MHZ). This should not be an issue if handoffs could actually occur to SID 22424 (800MHZ) however I have NEVER seen this successfully happen. Instead what happens is the call drops and if you're lucky and totally loose 1900 MHZ your phone will switch to 800MHZ and you can then complete the call on 800. However if your not so lucky and you still have an intermittent 1900 MHZ signal your phone will hang onto that for dear life and then end result is no better than before.

 

Also....when on 800 your phone will constantly search for a 1900 signal and switch to it as soon as it becomes available.

 

Before NV it did the same thing only it was between Sprint and a roaming partner. Other than reduced roaming costs how is this better? The caller experience is the same.

 

SAY IT ISN'T SO!! Surely this is not what NV will look like when complete!?

 

 

 

 

[Rukin1]

Give it time. 800 here has been in testing for the past month and some change. Every tower of sprint that has NV has to be adjusted to other towers being turned on and what not. Just give it some time, it'll improve. But here, I live old ass brick buildings and I never had more then 2 bars lol. But now I get 2-4 and calls seem richer(When 800 is on)

[digiblur]

Sounds like this is how the iphone prls are designed.

[jefbal99]

What device are you using?  Robert reported testing in Witcha or Waco that showed successful PCS->SMR->PCS or the other way around.  But I believe that was on a Galaxy S3, not sure if it was a stock PRL or digi's PRL.

 

What PRL are you on?

[Rukin1]

What device are you using?  Robert reported testing in Witcha or Waco that showed successful PCS->SMR->PCS or the other way around.  But I believe that was on a Galaxy S3, not sure if it was a stock PRL or digi's PRL.

 

What PRL are you on?

Me? 2015 galaxy s3.

[Dkoellerwx]

Me? 2015 galaxy s3.

No, not you. The OP.

[Rukin1]

No, not you. The OP.

LOL i know. My bad, I had a derp moment .

[Dkoellerwx]

I am in the Central Pa Shentel Market and about a week ago Sprint pushed a PRL update that made 800 MHZ Voice publicly available. They are broadcasting it on SID 22424 (I thought Central PA is supposed to be 22425?)

 

The company I work for migrated from Nextel to Sprint in January and we have lots of issues with dropped calls. My boss has been ready to throw them out months ago but I have convinced him to give it till at least June 30, explaining the NV process and how 800 MHZ should greatly improve that.

 

Now it here and it doesn't work...

 

It seems the PRL Sprint pushed out prioritizes SID 4168 (1900 MHZ). This should not be an issue if handoffs could actually occur to SID 22424 (800MHZ) however I have NEVER seen this successfully happen. Instead what happens is the call drops and if you're lucky and totally loose 1900 MHZ your phone will switch to 800MHZ and you can then complete the call on 800. However if your not so lucky and you still have an intermittent 1900 MHZ signal your phone will hang onto that for dear life and then end result is no better than before.

 

Also....when on 800 your phone will constantly search for a 1900 signal and switch to it as soon as it becomes available.

 

Digi is the PRL expert here, but it sounds like you have a PRL that does not prioritize 800.

 

In other areas, like Chicago, all android device PRLs prioritize 800, and only moves over to 1900 if it absolutely has to, make the experience much better (hence the lack of complaints about dropped calls lately from Chicago.). iPhone devices on the other hand, prioritize 1900, causing this drop every time you reach the edge of the 1900 coverage area and into 800. Hopefully Shentel (or whoever sets the PRL for your devices) will fix this, and prioritize 800 properly.

[WiWavelength]

Guys, no, the PRL influences only system acquisition while a handset is idle.  The PRL is out of the loop when a handset is on a traffic channel. Then, inter band handover is entirely network dependent.

 

AJ

[WiWavelength]

Instead what happens is the call drops and if you're lucky and totally loose 1900 MHZ...

 

Oh no, "loose 1900 MHz"?  Now, I need to make yet another sign.

 

AJ

[Dkoellerwx]

Guys, no, the PRL influences only system acquisition while a handset is idle.  The PRL is out of the loop when a handset is on a traffic channel. Then, inter band handover is entirely network dependent.

 

AJ

I know it doesn't affect the handoffs, but it still determines which technology you initiate the call on does it not? (1900 vs 800)

I thought I had this figured out.... haha.

[ericdabbs]

Guys, no, the PRL influences only system acquisition while a handset is idle.  The PRL is out of the loop when a handset is on a traffic channel. Then, inter band handover is entirely network dependent.

 

AJ

 

So I take it that the OP's issue is Sprint's fault on the network side and they need to adjust and optimize their settings at the base station to have handover occur sooner so it doesn't have a "break before make" issue between 1900 and 800?  I presume that once more 800 CDMA sites are up this issue won't be as bad?

[WiWavelength]

So I take it that the OP's issue is Sprint's fault on the network side...

 

No, prophead is located in a Shentel affiliate market.  So, it would be Shentel's fault.  Or, depending upon where he is located, it could be a handoff from Shentel affiliate to Sprint corporate.

 

AJ

[halcyoncmdr]

So I take it that the OP's issue is Sprint's fault on the network side and they need to adjust and optimize their settings at the base station to have handover occur sooner so it doesn't have a "break before make" issue between 1900 and 800?  I presume that once more 800 CDMA sites are up this issue won't be as bad?

 

Don't take my word on this, but I think I remember discussion a while ago about handoffs between 1900 and 800 requiring a hard handoff, no possibility for a soft handoff, thus often resulting in poor experience in comparison. I caxn't seem to find it now though so maybe that was my imagination.

[koiulpoi]

Are you actually certain that 800 MHz is available at good strength in those instances where a handoff would be appropriate? Unless your market is 100% complete, only 3G NV "clusters" will have any 800 MHz at all (with notable exceptions).

[Deval]

What device are you using?

[SpenceSouth]

Don't take my word on this, but I think I remember discussion a while ago about handoffs between 1900 and 800 requiring a hard handoff, no possibility for a soft handoff, thus often resulting in poor experience in comparison. I caxn't seem to find it now though so maybe that was my imagination.

 

I remember that conversation as well.  It was probably in the Everything 800mhz thread.

[WiWavelength]

Don't take my word on this, but I think I remember discussion a while ago about handoffs between 1900 and 800 requiring a hard handoff, no possibility for a soft handoff, thus often resulting in poor experience in comparison. I caxn't seem to find it now though so maybe that was my imagination.

 

In CDMA1X, inter frequency handoffs, let alone inter band handoffs, are always hard handoffs.  By definition, soft/softer handoff is limited to the same carrier channel.

 

AJ

[strumgewr]

Oh no, "loose 1900 MHz"? Now, I need to make yet another sign.

 

AJ

1900 MHz on the loose!? Better go catch it

[utiz4321]

I had a chance to put the question of hard hand offs to the presenter of the network vision webinar back when sprint was first trying to explain NV. When I worked for AT&T 9 years ago or so I know they had problems with hard handoffs and dropping calls, but the presenter assured us in the webinar that the industry had lots of experiance in limiting the number of drop calls during a hard handoff. If this is true this issue will more than like be fixed.

[utiz4321]

I had a chance to put the question of hard hand offs to the presenter of the network vision webinar back when sprint was first trying to explain NV. When I worked for AT&T 9 years ago or so I know they had problems with hard handoffs and dropping calls, but the presenter assured us in the webinar that the industry had lots of experiance in limiting the number of drop calls during a hard handoff. If this is true this issue will more than like be fixed.

[WiWavelength]

When I worked for AT&T 9 years ago or so I know they had problems with hard handoffs and dropping calls...

 

Did you work for AT&TWS or Cingular?  Either way, nine years ago, were you actually dealing with W-CDMA?  If not, GSM and IS-136 TDMA do nothing but hard handoffs.

 

AJ

[prophead]

What device are you using?

 

Using a DuraXT. Currently using testing PRL 21086X which prioritizes 800, however when Sprint/Shentel made 800 publicly available in this area they pushed PRL 22097 which prioritizes 1900. PRL 22097 is the one I was using when I was testing the handoffs.

 

1900 MHz on the loose!? Better go catch it

 

You making fun of my botching the English language? There is definitely something "loose" otherwise the handoffs would work.

[utiz4321]

Did you work for AT&TWS or Cingular? Either way, nine years ago, were you actually dealing with W-CDMA? If not, GSM and IS-136 TDMA do nothing but hard handoffs.

 

AJ

I didn't work on the network side of things, but it was right after Cingular bought AT&T mobile in California. We had to divest all of the 1900 MHz spectrum and tmobile had bought it. Whenever a customer would go from 850 to 1900 it would drop. No real problems switch between 850 towers though.

[koiulpoi]

Using a DuraXT. Currently using testing PRL 21086X which prioritizes 800, however when Sprint/Shentel made 800 publicly available in this area they pushed PRL 22097 which prioritizes 1900. PRL 22097 is the one I was using when I was testing the handoffs.

 

 

You making fun of my botching the English language? There is definitely something "loose" otherwise the handoffs would work.

I guess that confirms for me that xxx97 scans for 1900 first, while xxx15 scans for 800 first. Not a PRL expert, just speculating. Makes me wonder if the DuraXT (like the iPhone 5) needs to scan for 1900 first for some reason...