EVDO Connection Problem

[T_ADD]

Hi to all. I have a very challenging EVDO connection problem on a phone that I'm troubleshooting. The phone works properly on 1x voice/data and is able to acquire an EVDO channel. From a layer 2/3 trace (see below) it can be seen that the phone sends a route update/connection request message to BTS-BSC (AN) and then recieves a L2 acknowledgement from the AN but the AN never assigns a traffic assignment.

Can someone with message analysis experience give some tips, ideas, opinions on why this may be happening. One thing, the phone is an MEID type. The MEIDSUP switch in the BSC is set to OFF (can only be switched ON with license [BSC6600]).

I would appreciate some insite into this from other experts here.

Here's the QXDM message log in text:

problem phone:

OTA LOG [0x1076/014/000] SACH/Route Update/Route Update 22:00:39.985 Channel: 201, Pilot PN: 452
OTA LOG [0x1076/012/001] SACH/Idle State/Connection Request 22:00:39.986 Channel: 201, Pilot PN: 452
OTA LOG [0x107C/015/000] SCCHB/Overhead Msgs/Quick Config 22:00:40.116 Channel: 201, Pilot PN: 452
OTA LOG [0x107C/011/000] SCCHB/Init State/Sync 22:00:40.116 Channel: 201, Pilot PN: 452
OTA LOG [0x107C/002/001] SCCHB/AC MAC/Access Parameters 22:00:40.116 Channel: 201, Pilot PN: 452
OTA LOG [0x1086] 1xEV-DO MAC/Control Channel 22:00:40.116 Length: 0065
OTA LOG [0x1085] 1xEV-DO MAC/Access Channel 22:00:40.300 Length: 0029
OTA LOG [0x1078/002/000] SCCHD/AC MAC/AC Ack 22:00:40.375 Channel: 201, Pilot PN: 452
OTA LOG [0x1086] 1xEV-DO MAC/Control Channel 22:00:40.375 Length: 0013
OTA LOG [0x107C/015/000] SCCHB/Overhead Msgs/Quick Config 22:00:40.542 Channel: 201, Pilot PN: 452
OTA LOG [0x107C/011/000] SCCHB/Init State/Sync 22:00:40.542 Channel: 201, Pilot PN: 452
OTA LOG [0x107C/015/001] SCCHB/Overhead Msgs/Sector Parameters 22:00:40.542 Channel: 201, Pilot PN: 452


normal phone:

OTA LOG [0x1076/014/000] SACH/Route Update/Route Update 23:24:20.828 Channel: 201, Pilot PN: 452
OTA LOG [0x1076/012/001] SACH/Idle State/Connection Request 23:24:20.828 Channel: 201, Pilot PN: 452
OTA LOG [0x1085] 1xEV-DO MAC/Access Channel 23:24:20.828 Length: 0028
OTA LOG [0x1078/002/000] SCCHD/AC MAC/AC Ack 23:24:20.997 Channel: 201, Pilot PN: 452
OTA LOG [0x1086] 1xEV-DO MAC/Control Channel 23:24:20.998 Length: 0013
OTA LOG [0x107C/015/000] SCCHB/Overhead Msgs/Quick Config 23:24:21.122 Channel: 201, Pilot PN: 452
OTA LOG [0x107C/011/000] SCCHB/Init State/Sync 23:24:21.122 Channel: 201, Pilot PN: 452
OTA LOG [0x107C/002/001] SCCHB/AC MAC/Access Parameters 23:24:21.122 Channel: 201, Pilot PN: 452
OTA LOG [0x1086] 1xEV-DO MAC/Control Channel 23:24:21.123 Length: 0065
OTA LOG [0x1078/014/001] SCCHD/Route Update/Traffic Channel Assignment23:24:21.125 Channel: 201, Pilot PN: 452



I've also attached full QXDM saved logs here incase someone's interested in playback.

[T_ADD]

Today I found out that the ConnectionRequest message subtype field is different (1) compared to the one from a normally working phone (0). Does any one have any experience with this?

modem:
Frequency Band = 0 CDMA Channel = 201 Pilot PN Offset = 452
Half-Slot TR = 0 Reliable = 0 Fragmented = 0
ACK Seq # Valid = 0 MSG Seq # Valid = 0 Sync CC Flag = 0
ACK Seq # = 0 MSG Seq # = 255 IS-890 Flag = 0
App Subtype = 0


header_rev = 1 (0x1)
num_options = 0 (0x0)
subtype = 0 (0x0) (subtype 0)
protocol_instance = 0 (0x0) (In Use)
protocol_type = 12 (0xc) (Idle State Protocol)
message_id = 1 (0x1) (ConnectionRequest)
idle_state
connect_req
transaction_id = 121 (0x79)
request_reason = 0 (0x0)




phone:
Frequency Band = 0 CDMA Channel = 201 Pilot PN Offset = 452
Half-Slot TR = 0 Reliable = 0 Fragmented = 0
ACK Seq # Valid = 0 MSG Seq # Valid = 0 Sync CC Flag = 0
ACK Seq # = 0 MSG Seq # = 255 IS-890 Flag = 0
App Subtype = 1


header_rev = 1 (0x1)
num_options = 0 (0x0)
subtype = 1 (0x1) (subtype 1 or 2 if protocol type is 0x15-0x17)
protocol_instance = 0 (0x0) (In Use)
protocol_type = 12 (0xc) (Enhanced Idle State Protocol)
message_id = 1 (0x1) (ConnectionRequest)
idle_state
connect_req
conn_req
transaction_id = 26 (0x1a)
request_reason = 0 (0x0)
pref_ch_count = 0 (0x0)
emergency_incl = 1 (0x1)
emergency_ind = 0 (0x0)

[T_ADD]

So I've confirmed this is the case for Rev.A. In other words the above messages are normal. I've been trying to view the hardwareID request/response and UATI request/response messages but even after checking all options in OTA log (for cdma 1xEVDO) I cannot see them.

Can anybody help on this please?

[DANORM]

maybe the problem is in MSC or billing side. Try to rewrite this user number in MSC side.

[T_ADD]

Hi DANCESTORM, may be you forgot :) EVDO doesn't go through MSC/HLR.

My top suspect is MEID which the BSC is failing to recognise because in our BSC doesn't support MEID. It will need license. MEID is what will be broadcasted in the hardwareID which is requested by the AN (if you look at the EVDO call flow)

I've requested a trial MEID license to verify this. Let's see...

[DANORM]

for MSC side i betokened -AN. I call everything MSC side out of BSC part :D

[T_ADD]

carver more or less confirms my suspicion. My phone is sending the MEID in the hardwareID response message rather than ESN. The BSC doesn't support MEID and that's why cannot assign a TCA.

Thanks carver - http://www.finetopix.com/showthread.php?2045-QCAT-(Qualcomm-Analisys-Tool)&p=184391&viewfull=1#post184391

[T_ADD]

So I *****ed it. I removed the MEID from my phone (disable) and now it sends ESN in the HardwareID Response message to the AN. Therefore, the AN now assigns a TCA and EVDO for the first time works on the phone.

[shankarprasai]

I have recently configured EVDO servicein our Network.EVDO signal only seen in Huawei modem but not in any commercial modem.Have you any knowledge about this ?Why we canot get A12 trace in common market EVDO modem?

[jamesbond]

So I *****ed it. I removed the MEID from my phone (disable) and now it sends ESN in the HardwareID Response message to the AN. Therefore, the AN now assigns a TCA and EVDO for the first time works on the phone.

You concluded right. We had the same problem once on some terminals!