Field test Analysis
B1
Newbie
Hi, Seeing how a lot of people are having theses constant disconnect and reconnect problems I started looking at the field test report closely and think we can use this info to troubleshoot the problem and also to explain the matter clearly to customer support. I can identify some of the variables but the rest I am not familiar with and would like to ask anyone else to help identify what all the setting identifiers represent and what are the ideal levels they should be at. Here is a complete field test report : parameter value sid NID FER CDMA RSSI PN 0FFSET WALSH CoDE ECH0 lo/db channel # Band class TX power RX power **bleep** previous MS previous Packet zone ID Last active call state Last active call type dormant state Last call end reason Last call error service option call state Active set PN offset echo l/o channel Neighbor set - PN offset echo l/o channel Candidate set -PN offset echo l/o channel UATI MAC index subnet mask color code PN offset echo l/o HDR RSSI Channel # Band class TX power RX power Per at state dormant state Active set PN offset echo l/o channel Neighbor set - PN offset echo l/o channel Candidate set -PN offset echo l/o channel these are all the parameters. can anyone identify them for us and give us the corect values it should be. Thanks.
0 Likes
Re: Field test Analysis
LukeTech
Contributor - Level 1

I'll share with you what I know. Since your post is a lump of text, I'll try to make out what I can as some of these parameters are bunched together. Also note, there may not be a "good" or "bad" value on a lot of these, I'll star ** the ones that effect voice and data call performance.

SID = System ID, each switch transmits the same system ID on all of it's (several hundred) cell sites. If your home SID is 001, for example, and your phone shows 001, then you are in your home area. If it shows 002, you are now on a different switch, which may be on a different network.

NID = Network ID, not used to my knowledge.

FER** = Frequency Error Rate, the error rate of receive signal. The CDMA max limit is .5% at -104dbm before audio warble starts to get bad.

RSSI** = Receive signal strength indicator. Briefly, this is the receive signal strength in dbm. -55 or so is about the strongest you'll get very close to a site, -104 is pretty much the limit of power... we're talking picowatts of receive power.

HDR RSSI** = High data rate RSSI. This can be different than the usual RSSI, it measures the RSSI for the EVDO service.

PN Offset = This is the unique identifier of the sector you are on. This may vary, but on a 3-sector site, sector 1 is the lowest number, sector 2 is 8 higher than the number for sector 1; sector 3 is 4 higher than sector 1.

Walsh Code = the security code that is being used on the uplink channel (cell site > handset).

EC/i0** = Pronounced "Eee Cee over Eye not." This describes signal to noise ratio. Up to -8db is good, I believe.

Channel Number = Just the channel/carrier the phone/data device is using at the time.

TX Power** = Transmit power, lower -dbm numbers = higher transmit power. The **bleep**her away you are from a site, the more TX power you need to reach the site. This is related to RSSI and RX Power.

Dormant state = When a data device is idle, it goes dormant. The logical connection is still up, but no data is moving. When you request data or data is being sent to the device, the connection is instantly established. This saves time as opposed to tearing down the connection when idle then re-establishing it from scratch again.

Active Set = The one (or more) PNs that the mobile is talking to at a given time.

Neighbor Set = If the active PNs start to get weak, the phone will check the neighbor set. If a neighbor PN is stronger than an active PN, they are swapped and the former neighbor becomes the active. There can be a long list of neighbor sets depending on how many cell sites are in the 1 to 3mi vicinity.

Last Call = The state and type keep up with the last call the device made. It typically gives you an error/call code instead of plain English, so being able to crossreference this code to the actual failure is what can really help troubleshoot issues.

As for the ones that I starred, RSSI for voice and HDR RSSI for data are the number one variable that determines call quality, this directly relates to "bars" of service. However, each phone/device shows the bars differently so one cannot compare different phones' bars. EVDO data is very sensitive to RSSI and the more the better, else the MS (mobile station, in EVDO speak) tells the site that it cannot receive the highest rate of data and the site will throttle it down until the MS says the condition has improved... which happens many times per second.

As receive signal strength starts to drop, FER will increase until the call gets choppy or a large portion of the data is lost. Some data loss is allowable because it is transmitted in a reduntant method, depending on the speed the MS/cell site has decided on. As the speeds slow, redundancy increases helping to ensure the MS gets all of the data it should assuming some/most is lost.

Let me know if this is easy enough to understand or if I can clarify anything.

0 Likes
Re: Field test Analysis
B1
Newbie

Thanks for the reply Luke.

 

The explanation was very usefull and informative.

 

the  reason for losing of last call :  EVDo release call for no reason.

 

any thoughts?

 

 

 

Bfox

 

0 Likes
Re: Field test Analysis
LukeTech
Contributor - Level 1

It is difficult to say based on the description. Usually, there's a good reason for losing a call such as RF loss, high error rate or something of the like.

0 Likes
Re: Field test Analysis
VZlwh
Newbie

B1 Awhile back you wrote...

 


"Dormant state = When a data device is idle, it goes dormant. The logical connection is still up, but no data is moving. When you request data or data is being sent to the device, the connection is instantly established. This saves time as opposed to tearing down the connection when idle then re-establishing it from scratch again".

 

Many of us are having this problem of VZAccess going to dormant and then stalling there. It does not refresh, in my case I've had it go "dormant" when my web browser was actively trying to connect to websites, or while I'm surfing the web, if I stop operations briefly to read or do some thing else, VZManager goes to "dormant" phase. When I attempt to resume surfing I get continual error messages from my browser sayin "it could not connect, check for service". VZManager says I'm connected o.k. but "dormant". There is no way to tell VZ to come out of dormant. When I exit VZ, and attempt to connect fresh, I get a variety of error messages. Multiple attemts to re-connect fail. The most common error messages is "could not connect to remote server"
Once we're at this stage its necessary to disconect the modem. I have to shut down & re-start my compter, with the subsequent loss of all the data I've downloaded & all of the time waiting for it to download. I also know that once I "fix" the problem I'll just have to wait until all the pages download again. All of the double downloads, some times triple or quadrupal, cost dataflow which I am charged for. Once I've shut down, I restart VZ, I have to "detect" the modem, activate the modem, and then finally reconnect. This process takes time, sometimes as much as an hour to recover to the previous working stage. This has happened with 4 different browsers on varied websites.

 

Have you seen any fixes for this ??? Verizon senior techs have been no help.

0 Likes