TROUBLE SHOOT Packet Data PDF

Troubleshooting 1X Data
Service
Software Release 2.16.0
White Paper
CDMA2000 1X
English
JUN 2002
CIGCOMGENAWP0071.01
2002 Motorola, Inc
Troubleshooting R16.0 1X Data Service

Abstract
This document contains the background information, and troubleshoot guide for R16.0 1X
data service.
Document: CIG-COM-GEN-AWP-007
Version No.: 1.01
Status: Release
Date:
<5/30/2002>
Motorola Inc.
Network Solutions Sector
1441 West Shure Drive, Arlington Heights, IL 60004
U.S.A.
Last modified 6/5/02
2002 Motorola, Inc
References
[1]
Motorola. "CDMA Call Processing System Functional Specification", Version 16.00. Feburary 2002
[2]
Motorola. "Supercell Performance Management Software Functional Specification", Version 16.0.

May 2001
[3]
Motorola. "SMAP Operators Guide", Version 2.16.x.x. January, 2002
[4]
Motorola. "UNO 2.16.0.0 Administrators/Users Guide", Version 2.16.0.0. May, 2001
[5]
Motorola. "System Functional Specification System Surveillance, Reconfiguration, and Recovery",

Version 16.00. August 2001
[6]
Motorola. "CDMA Online Document - Performance Analysis", Release 2.16.0. 2002
[7]
Motorola. "CFC Resolution Document", Version 2.3.3, May, 2002
2002 Motorola, Inc
Glossary
AAA . . . . . .Authentication, Authorization, Accounting
AN . . . . . . .Access Node
BTS . . . . . .Base Transceiver Subsystem
CBSC . . . . .Central Base Station Controller in the cellular network
CDL . . . . . .Call Detail Log
CDMA . . . . .Code Division Multiple Access
CFC . . . . . .Call Final Class
DUN . . . . . .Dial-Up Network
FACN . . . . .Foreign Agent Control Node
FCH . . . . . .Fundamental Channel
FER . . . . . .Frame Eraser Rate
FTP . . . . . .File Transfer Protocol
HA . . . . . . .Home Agent
MM . . . . . . .Mobility Manager
MS . . . . . . .Mobile Station
MCC. . . . . .Multi-Channel Card
OMC-R. . . . .Operation Maintenance Center - Radio
PCF . . . . . .Packet Control Function
PDSN . . . . .Packet Data Serving Node
PPP . . . . . .Point-to-Point Protocol
RAN . . . . . .Radio Access Network
RLP . . . . . .Radio Link Protocol
SCH . . . . . .Supplemental Channel
SMAP . . . . .System Monitoring Application Processor
2002 Motorola, Inc

TCP . . . . . .Transmission Control Protocol
UDP . . . . . .User Datagram Protocol
UNO . . . . . .Universal Network Operation
XC . . . . . . .Transcoder Subsystem
2002 Motorola, Inc
Table of Contents
1.
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1
1.2
1.3
2.
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1
2.2
3.
Call Flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Data Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Statistics Collection and Fault Monitoring . . . . . . . . . . . . . . . . . . . . 15

3.1
3.2
3.3
3.4
4.
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Scope. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2.1 Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2.2 Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Performance Management Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.1 BTS per Data Rate SCH Allocation Report . . . . . . . . . . . . . 16
3.1.2 BTS Carrier-Sector SCH Allocation Report. . . . . . . . . . . . . 19
3.1.3 Packet Pipe SCH Allocation Report . . . . . . . . . . . . . . . . . . . 19
3.1.4 Packet Pipe SCH Utilization Report . . . . . . . . . . . . . . . . . . . 20
3.1.5 SCH Group Allocation / Utilization Report . . . . . . . . . . . . . 22
3.1.6 BTS SCH Allocation Failures Report. . . . . . . . . . . . . . . . . . 25
3.1.7 Packet Data Statistics Activations - XC Report . . . . . . . . . . 26
3.1.8 Packet Data Statistics Sessions Bytes - XC Report . . . . . . . 26
3.1.9 Packet Data Statistics Packet Size - XC Report . . . . . . . . . . 26
3.1.10 Packet Data Statistics Sessions Durations - XC Report . . . . 26
3.1.11 XC PCF-CE Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.12 XC PCF-RA Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1.13 CDMA Call Setup Timing - MM Report . . . . . . . . . . . . . . . 26
3.1.14 Sector Call Setup Effectiveness Report . . . . . . . . . . . . . . . . 26
3.1.15 Packet Data Activity - MM Report. . . . . . . . . . . . . . . . . . . . 26
CDL Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
System Fault Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4.1 DUN Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4.2 Microsoft Performance Monitor . . . . . . . . . . . . . . . . . . . . . . 31
3.4.3 Motorola Netspy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.4 SMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.5 Netmon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4.6 Qualcomm CDMA Air Interface Tester (CAIT) . . . . . . . . . 35
Troubleshoot - Call Setup Failures. . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.1
4.2
Methodology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
CFC Based Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.1 CFC 03 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.2 CFC 04 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.3 CFC 05 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.4 CFC 15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.5 CFC 12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.6 CFC 13 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.7 CFC 32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.8 CFC 20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.9 CFC 111 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2002 Motorola, Inc
Table of Contents
4.3
5.
Low Data Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.1
5.2
5.3
5.4
5.5
5.6
A1.
4.2.10 CFC 112 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.2.11 CFC 113 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2.12 CFC 138 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2.13 CFC 139 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2.14 CFC 142 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2.15 CFC 143 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
User Experience Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3.1 Authentication Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3.2 Authentication Time-out . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3.3 IPCP Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3.4 Mobile-Initiated Reactivation . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3.5 Network-Initiated Reactivation. . . . . . . . . . . . . . . . . . . . . . . 43
4.3.6 MS Alert during Idle State . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3.7 RF/L2 Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3.8 PDSN Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3.9 PCF/SDU Equipment Failure . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3.10 Mobility - Inter-PDSN Handoff . . . . . . . . . . . . . . . . . . . . . . 44
4.3.11 Mobility - Intra-PDSN Handoff . . . . . . . . . . . . . . . . . . . . . . 45
4.3.12 Application - TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
PPP Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Radio Link Protocol (RLP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Frame Eraser Rate (FER) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
TCP Window Size. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
SCH Allocation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Low Throughput Scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.6.1 PPP Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.6.2 High FER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.6.3 Resource Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.6.4 Ethernet Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.6.5 Microsoft TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
CDL Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
A1.1
A1.2
CDL example for a good data call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

CDL example for a failed data call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
A2.
Debug Log Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
A3.
Packet Data FAQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

A3.1
A3.2
PCF Buffer Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

PCF Operation on A10/A11 Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
2002 Motorola, Inc
List of Figures
Figure 1.
Figure 2.
Figure 3.
Figure 4.
Figure 5.
Figure 6.
R16.0 1X Data Call Path . . . . . . . . .

Packet Data Call Flow . . . . . . . . . . .
Throughput with TCP header compression
Logical flow Diagram . . . . . . . . . . .
CFC Based Decision Tree. . . . . . . . .
User Perception Decision Tree . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 3
. 3
13
37
38
42
2002 Motorola, Inc
List of Tables
Table 1.
Table 2.
Table 3.
Packet Data Related CDL Elements . . . . . . . . . . . . . . . . . . . . 28

FER Impact on Throughput . . . . . . . . . . . . . . . . . . . . . . . 50
MCC Resource Groups . . . . . . . . . . . . . . . . . . . . . . . . . 52
2002 Motorola, Inc
1. Introduction
1.1 Purpose
3G CDMA-1X packet data network allows a mobile service provider to offer highspeed, wireless data access to the Internet.
The introduction of the packet data network increases CDMA 1X system complexity and operability. This document provides packet data service troubleshooting
guide for FOA teams and account teams.This guide is designed to be a starting
point for resolving problems, not an all-encompassing solution for troubleshooting
the network. The scope of this document is limited to the RAN that supports
packet data service.
1.2 Scope
The scope of this document is limited to identify and troubleshoot RAN related
issues with regarding to simple IP packet data call setup and low data throughput
using existing R16.0 system tools.
The document is delivered in two phases.
1.2.1 Phase 1
Phase 1 of this document identifies all possible aids for troubleshooting
available in R16.0 release. They include system performance statistics
and reports, Call Detail Logs (CDL), and fault notifications. Using these
tools, we should be able to understand the causes of the following issues.
Data call does not complete.
Phase 1 further provides basic guideline for troubleshooting 1X packet

data call setup.
1.2.2 Phase 2
Phase 2 provides more detail analysis on throughput of 1X data call.
Data call is successful but throughput is low.
1.3 Organization
This document is organized as follows:
Chapter 1 - Introduction
Chapter 2 - Overview of packet data network
Chapter 3 - Description of PM reports, CDL, and fault notifications
Chapter 4 - Troubleshooting guide for packet data call setup
Chapter 5 - Troubleshooting guide for low data throughput

1
2002 Motorola, Inc

Appendix A - Call detail logs for successful and failed data calls
Appendix B - General debugging log notes
Appendix C - PCF and A10/A10 FYI

2
2002 Motorola, Inc
2. Overview
The R16.0 CDMA RAN architecture supports high speed packet data utilizing both fundamental channel (FCH) and supplemental channel (SCH). The bearer data traffic paths for
FCH and SCH are illustrated in Figure 1.
Figure 1. R16.0 1X Data Call Path

To Packet
Data
D ata N etwork
etw ork
To PSTN
M SC
Packet
IW U
C
ircuit
Circuit
IW U
PDSN
MM
XC
AAA
AN
D
AC
DA
Cs
FCH Path
SCH Path
C ircuit Backhaul
IS95A /B
M ixed Backhaul
ISIS- 95A/B & 1X
2.1 Call Flow

A successful 1X data call flow is shown in the following figure.[1]
Figure 2. Packet Data Call Flow

3
2002 Motorola, Inc
Successful Packet Data Call Setup Procedures

MS
PACH-CE TCH-CE
GLI
PSI-CE
SM
CPP
PSI-SDU
FEP
PCF
PCF-RA MMCP
PDSN
MSC
The MS transmits an Origination message or a Page Response

message, with Layer 2 Ack required, over the access channel to
request service.
1. CAI:Origination or Paging Response
2. CAI:BTS Ack Order
3. CHI: SCAP CDMA Channel Required or CDMA Page Response
4. LAPD: SCAP CDMA Channel Required or CDMA Page Response
5. LAN: SCAP CDMA Channel Required or CDMA Page Response
CFC 20
CFC 32
The MM receives the message, determines that this is a request

for high speed packet data service. MM checks service option
database to see if packet data service option is enabled or set to
negotiate. In this case, it is enabled or set to negotiate. The MM
chooses a PCF-RA to send the PCF Resource Request to via IMSI hashing.
.
MM sends the following messages in parallel:
1) PCF Resource Request to the PCF-RA
2) CM Service Request or Paging Response to the MSC
.
MM allocates a TCH, CPP, and WC.
.
Call setup at the XC is contingent upon the Sync ID and
"Service Option Override During Call Setup":
.
If Sync ID is received and "Service Option Override
During Call Setup" is not in progress, then the
CDMA XC Channel Assigned message will be sent after
the PCF Resource Response message from the PCF-RA
indicating a found/allocated PCF.
Otherwise the CDMA Channel Assigned and
CDMA XC Channel Assigned messages are sent in parallel.
.
6. SCTP: SCAP CDMA PCF Resource Request

4
2002 Motorola, Inc

MS
PACH-CE TCH-CE
GLI
PSI-CE
SM
CPP
PSI-SDU
FEP
PCF
PCF-RA MMCP
PDSN
MSC
7. Timer: Start PCFReqT

8. LAN: SCAP CDMA Channel Assigned
9. LAPD: SCAP CDMA Channel Assigned
10. CHI: SCAP CDMA Channel Assigned
11. CAI:Null TCH Data
12. Timer: Start MccCpT1
13. SS7:SCCP Connection Request + Complete Layer 3 Information Message (CM Service Request or Paging Response)
14. Timer: Start MmCpT14
15. Timer: Start T303Ap
The SCCP Connection Confirmed from the MSC may also be

piggybacked on the SS7:Assignment Request message from the
MSC.
17. SS7:SCCP Connection Confirm
18. Timer: Stop T3230Ap
19. CHI: SCAP CDMA Target Channel Designation
20. CHI: SCAP CDMA Target Channel Designation
21. Timer: Start T200 * N200 retx
22. CAI: Extended Channel Assignment/Channel Assignment Message
The PCF Resource Response may contain the stored service

configuration if the MS is transitioning from dormant.
23. SCTP: SCAP CDMA PCF Resource Response

5
2002 Motorola, Inc

MS
PACH-CE TCH-CE
GLI
PSI-CE
SM
CPP
PSI-SDU
FEP
PCF
PCF-RA MMCP
PDSN
MSC
24. Timer: Stop PCFReqT

25. LAN: SCAP CDMA XC Channel Assigned
26. LAPD: SCAP CDMA XC Channel Assigned
CFC 12
CFC 138
CFC 139
27. Timer: Start XcCpT11
The CPP:
- allocates a PSI-SDU resource
- allocates a PSI-CE resource
- tells the PSI-SDU the PSI-CE address
- tells the PSI-CE the PSI-SDU address
.
28. EXEC: SM Port Lock Request (request PSI-SDU resource)

29. EXEC: SM Port Lock Response (PSI-SDU UDP/IP address)
30. EXEC: SM Port Lock Response (request PSI-CE)
31. EXEC: SM Port Lock Response (PSI-CE UDP/IP address)
32. MCAP:SDU-Connect (PSI-CE UDP/IP address)
The PSI-SDU resource now has the address of the PSI-CE bearer port,
so the PSI-SDU resource can now source frames to the TCH-CE via
the PSI-CE.
.
33. UDP: A3-IS-2000 DCCH Forward, if MS is DCCH capable
(UDP:A3-IS-2000 FCH Forward, if MS is not DCCH capable)
34. STRAU frames
35. CAI: Variable Rate Frames
36. MCAP: PSI-Connect (PSI-SDU UDP/IP address)

6
2002 Motorola, Inc

MS
PACH-CE TCH-CE
GLI
PSI-CE
SM
CPP
PSI-SDU
FEP
PCF
PCF-RA MMCP
PDSN
The PSI-CE now has the packet address of the PSI-SDU bearer
port and upon acquisition of the MS, can send frames received from
the MS on to the PSI-SDU.
37. CAI: TCH Preamble
CFC 05
38. Timer: Stop MccCpT1

39. Event:MS Acquisition
40. CHI: SCAP CDMA Suspend TCH Assignment
41. CHI: SCAP CDMA Suspend TCH Assignment

42. Timer: Stop T200 * N200 retx
43. STRAU frames
44. UDP: A3-IS-2000 DCCH Reverse, if MS is DCCH capable
(UDP:A3-IS-2000 FCH Reverse, if MS is not DCCH capable)
45. Event: MS Acquisition
46. MCAP: Traffic Channel State Change Indication (Invalid Speech)
47. MCAP: Layer 3 Message Request Without Confirm (BS Ack Order)
48. CAI: BS Ack Order
49. CAI: Null TCH Data
50. STRAU frames
52. CAI: MS Ack Order
53. STRAU frames

7
MSC
2002 Motorola, Inc

MS
PACH-CE TCH-CE
GLI
PSI-CE
SM
CPP
PSI-SDU
FEP
PCF
PCF-RA MMCP
PDSN
MSC
55. MCAP: Traffic Channel State Change Indication (Valid Speech)
CFC 13
CFC 03
The MS is on channel and service negotiation begins.

Refer to service negotiation call flow.
56. MCAP:Service Option Change Request
Setup the A8 connection only after the Assignment Request

is received so that the cellular authentication is complete
before the A8 connection is setup.
.
In addition, the subscriber's subscribed rate information may be present in
the Assignment Request. This information is sent to the CPP
in the PCF Assignment message.
57. SS7: Assignment Request

59. LAN: SCAP CDMA PCF Assignment
60. LAPD: SCAP CDMA PCF Assignment
When both of the following conditions are met, the CPP

indicates successful call setup to the MM;
- RF call setup is complete and
- PCF Assignment is received from the MM.
Note that the CPP does not wait for A8/A10 bearer path
setup to complete before sending this message.
61. LAPD: SCAP CDMA XC Assignment Successful
(MS Service Configuration included)
62. Timer: Stop XcCpT11
63. LAN:SCAP CDMA XC Assignment Successful
64. Timer: Stop MmCpT14

8
2002 Motorola, Inc

MS
PACH-CE TCH-CE
GLI
PSI-CE
SM
CPP
PSI-SDU
FEP
PCF
PCF-RA MMCP
PDSN
MSC
The SCAP CDMA PCF Update is only sent if

Mob_P_Rev > 6 and 1x Service Configuration Records
(negotiable and non-negotiable) were received in the
SCAP CDMA XC Assignment Successful message and
the "USESYNCID" database parameter = "YES".
65. SCTP:SCAP CDMA PCF Update
After the MM sends the Assignment Complete, the MM can
start performing soft handoffs.
66. SS7: Assignment Complete
The following steps occur on the MS termination case only.

The A1 Connect message to the MSC only occurs if the A1 Paging
Response message was sent to the MSC earlier in this
call flow. These steps can occur anytime after the Assignment
Successful message is sent to the MM and after the A1 Assignment
Complete message is sent to the MSC.
67. LAN: SCAP CDMA XC Alert With Information
68. LAPD: SCAP CDMA Alert With Information
69. MCAP:Layer 3 Message Request (Alert with Information message)
70. CAI: Alert with Info
71. CAI: Connect Order
72. MCAP: Layer 3 Message Indication (Connect Order)
73. LAPD: SCAP CDMA XC Connect
74. LAN: SCAP CDMA XC Connect
76. SS7: Connect
77. SS7: Connect Ack

9
2002 Motorola, Inc

MS
PACH-CE TCH-CE
GLI
PSI-CE
SM
CPP
PSI-SDU
FEP
PCF
PCF-RA MMCP
PDSN
MSC
End of MS termination specific call flow.
CFC 112
79. MCAP: PCF Setup Request

80. Timer: Start PCFSetupT
The SDU-E allocates the A8 GRE Header key for the call
and this key is unique to the PSI SDU Card.
81. UDP: A9-Setup-A8
CFC 112
82. Timer: Start TA8Setup
At this point, the A11 messages either:

(1) establish the A10 connection and perform accounting
(the PCF allocates a unique A10 GRE Header Key for
the call. The key must be unique to the PSI PCF card)
or
(2) only perform accounting
.
depending on if this an establishment of a tunnel to the PDSN
or if the tunnel was already established, respectively.
83. UDP: A11-Registration Request

84. Timer: Start Tregreq
85. UDP: A11-Registration Reply
CFC 142
86. Timer: Stop Tregreq
87. UDP: A9-Connect-A8

88. Timer: Stop TA8Setup
CFC 143
89. MCAP: PCF Setup Complete

10
2002 Motorola, Inc

MS
PACH-CE TCH-CE
GLI
PSI-CE
SM
CPP
PSI-SDU
FEP
PCF
PCF-RA MMCP
PDSN
90. Timer: Stop PCFSetupT

11
MSC
2002 Motorola, Inc
Service Negotiation - Success(CBSC Proposes, Mobile Initiates, MS Accepts)

MS
XCDR
CPP
1. Service Request Message

[REQ_PURPOSE = 0010 (propose)]
[Service Configuration]
2. MCAP:Layer 3 Message Request
[The CPP counter proposes a service configuration.]
[ The MCAP message contains Service Negotiation Call Setup quick
[repeat parameters and Service Response message]
3. Service Response message
[RESP_PURPOSE = 0010 (propose)]
[Service Configuration]
4. Start XcCpT10
5. Service Request Message

[REQ_PURPOSE = 0000 (accept)]
[CPP clears XcCpT10]
[the CPP considers that a mutual service configuration is reached.]
[Therefore, the CPP sends Service Connect message]
[Refer to Service Negotiation - Success (CBSC sends Service Connect,]
[Mobile sends Service Connect Completion call flow for details]

12
2002 Motorola, Inc

2.2 Data Throughput
Average throughput seen by users is a key factor affecting user experience. Correctly defining throughput is important, as usage varies widely.
1X data service can theoretically achieve 153.6kbps + 9.6kbps = 163.2 kbps peak
data throughput at the physical layer. Control overhead consumed at each layer
between the physical and transport layers is around 13 to 14%. Of 163.2kbps carried by the physical layer, about 141kbps is available to the application layer. The
maximum peak throughput for TCP applications is 141kbps or 17.6Kbytes/sec.
For UDP applications, the maximum peak throughput is 137.6kbps or 17.2 kbytes/
sec.
Figure 3. Throughput with TCP header compression
If the network provides a circuit switched connection at 163.2 kbps rate, the 141
kbps would be the peak application throughput seen by the user, assuming the
base station had sufficient power to maintain the link. However, due to the bursty
nature of packet data services, the network should provide such bandwidth only
when the user has sufficient data to send (or receive). Because the air link is a
shared resource, the user must share that data pipe with other users, reducing the
throughput the user sees. Both factors result in a reduction of the throughput from
the peak user throughput.
The following factors will degrade the actual throughput user experiences.
Shared resource among multiple users
RLP retransmissions due to erasures
TCP slow start
Variations in packet sizes between Application server and client
13
2002 Motorola, Inc

Bandwidth consumed by overhead messages
TCP retransmissions
FTP file size
PPP errors and overhead
As result, the actual throughput will be lower. Microsoft Performance Monitor is highly configurable to monitor TCP statistics and data throughput of any specific interface. DUN monitor shows
the speed of the connection, and PPP error. Most of FTP utility also shows the main data rate.

14
2002 Motorola, Inc
3. Statistics Collection and Fault Monitoring

3.1 Performance Management Reports
R16.0 currently collect performance statistics and provided the following packet
data related reports.[2]
Below is the list of PM reports related to packet data service.
Packet Data Statistic Forward Burst Size XC
Packet Data Statistic Reverse Burst Size XC
Packet Data Statistic Forward Burst Duration XC
Packet Data Statistic Reverse Burst Duration XC
Packet Data Statistic Burst Rate XC
Packet Data Statistic Session Burst Count XC
Packet Data Statistic Session Bytes XC
Packet Data Statistic Inter-Arrival XC
Packet Data Statistic Activations XC
Packet Data Statistic Durations XC
PDSN Packet Data Statistics Packet Size XC
Resource Allocation - Sector
XC PSI-CE Resource Group Report
XC PCF-RA Report
MCCce 1X Resource Group Site Report
MCCce 1X Resource Group Sector Report
BTS SCH Allocation Failures Report
BTS per Data Rate Carrier-Sector SCH Allocation Report
BTS Carrier Sector Paging Channel Usage Report
Packet Pipe MCC1X SCH Allocation Report
Packet Pipe MCC1X SCH Utilization Report
SCH Group Allocation Report
SCH Group Utilization Report
For detail description of each report, please refer to CDMA Online Document Performance Analysis.[6]
All these reports can be generated via UNO PM reporting tool[4], or using CLI
command GENERATE PMREPORT (KEYWORD).
KEYWORDS for packet data-related reports associated with their names:
15
2002 Motorola, Inc

Packet Data Statistic Forward Burst Size XC:PDFBRSTSZ
Packet Data Statistic Reverse Burst Size XC:PDRBRSTSZ
Packet Data Statistic Forward Burst Duration XC:PDFBRSTDRTN
Packet Data Statistic Reverse Burst Duration XC:PDRBRSTDRTN
Packet Data Statistic Burst Rate XC:PDBRSTRT
Packet Data Statistic Session Burst Count XC:PDSSNBRSTCNT
Packet Data Statistic Session Bytes XC:PDSSNBYTE
Packet Data Statistic Inter-Arrival XC:PDINTARRVL
Packet Data Statistic Activations XC:PDACTVTN
Packet Data Statistic Durations XC:PDDRTN
PDSN Packet Data Statistics Packet Size XC: PDSNPKTSZ
Resource Allocation - Sector: SECALLOC
XC PSI-CE Resource Group Report: XCRESGRP
XC PCF-RA Report: XCPCFRA
MCCce 1X Resource Group Site Report: MCCCE1XSITGRP
MCCce 1X Resource Group Sector Report: MCCCE1XSECGRP
BTS SCH Allocation Failures Report: BTSSCHALLOC
BTS per Data Rate Carrier-Sector SCH Allocation Report: CSEC BTSDRSCHALLOC
BTS Carrier Sector Paging Channel Usage Report: CSEC BTSCSPCHUSG
Packet Pipe MCC1X SCH Allocation Report: PPIPE MCC1XSCHALLOC
Packet Pipe MCC1X SCH Utilization Report: PPIPE MCC1XSCHUTIL
SCH Group Allocation Report: SCHGRALLOC
SCH Group Utilization Report: SCHGRUTIL
3.1.1 BTS per Data Rate SCH Allocation Report

These measurements are given in Table pmC_45_hr.
There is an almost-identical set of measurements for the Forward (FWD) and Reverse
(RVS) direction. ("No Walsh Code" failure does not apply in the Reverse direction);
All SCAP messaging between PSI-SDU and BTS during the Supplemental Channel
(SCH) allocation algorithm is covered;
Pegs are separated by the following identifiers: BTS Id; Rate Set; and Logical Data Rate
number; Data Rate is calculated as "Logical Data Rate" multiplied by x=9.6 for Rate Set 1,
or x=14.4 for Rate Set 2.
Using the Table pmC_45_hr,
if (subj_id_2 == 1) x=9.6;
else if (subj_id_2 == 2) x=14.4;
Data Rate (kbps) = subj_id_3 * x
Rate Set
--------1 (x=9.6)
1
1
1
1
2 (x=14.4)
2
2
2
Logical Data Rate

----------------1
2
4
8
16
1
2
4
8
Data Rate (kbps)

---------------9.6 (=x)
19.2 (=2x)
38.4 (=4x)
76.8 (=8x)
153.6 (=16x)
14.4 (=x)
28.8 (=2x)
57.6 (=4x)
115.2 (=8x)
16
2002 Motorola, Inc

Pegs are separated by the Data Rate in order to track how the allocation algorithm
depends on the requested data rate.
SCH Requests going to a single BTS are tracked separately from SCH
Requests which involve multiple BTSs because the allocation algorithm is different in
those two cases. Besides, the allocation success rate for multiple BTS case is expected to
be slightly smaller than in the single BTS case, since multiple BTSs have to agree on a
common set of parameters.
Raw measurements are as follows:
FWD SCH Single BTS Requests
RVS SCH Single BTS Requests
FWD SCH Multiple BTS Requests
RVS SCH Multiple BTS Requests
- track number of requests sent from the SDU
FWD SCH Single BTS Responses - data rate same as requested
RVS SCH Single BTS Responses - data rate same as requested
- track number of successful allocations in Single BTS case, pegged on the
ASSIGNED data rate which is the same as the originally requested data rate
FWD SCH Single BTS Responses - data rate lower than requested
RVS SCH Single BTS Responses - data rate lower than requested
- track number of successful allocations in Single BTS case, pegged on the
ASSIGNED data rate which is lower than the originally requested data rate
- can be used together with the previous peg to get total number of Single BTS
Responses
- can be used alone to track which BTSs consistently have problem to match the
requested data rate
FWD SCH SDU Commits - data rate same as requested
RVS SCH SDU Commits - data rate same as requested
- track number of successful allocations in Multiple BTS case, pegged on the
COMMITTED data rate which is the same as the originally requested data rate
FWD SCH SDU Commits - data rate lower than requested
RVS SCH SDU Commits - data rate lower than requested
- track number of successful allocations in Multiple BTS case, pegged on the
COMMITTED data rate which is lower than the originally requested data rate
- can be used together with the previous peg to get the total number of Commits
(for the Multiple BTSs case)
- can be used alone to track which BTSs were involved in most cases when the
data rate could not be matched
17
2002 Motorola, Inc

FWD SCH BTS Responses - Failures - No RF Capacity
RVS SCH BTS Responses - Failures - No RF Capacity
FWD SCH BTS Responses - Failures - No Walsh Codes
- track number of failures due to no RF / no WCs, pegged at the data rate
requested
FWD SCH BTS Rate Changes - old rate
RVS SCH BTS Rate Changes - old rate
FWD SCH BTS Rate Changes - new rate
RVS SCH BTS Rate Changes - new rate
- track number of data rate changes during the SCH allocation procedure;
pegged on the initially assigned ("old rate") and the post-change ("new rate")
data rate. The "new rate" is always LOWER than the "old rate". Both measurements are pegged in order to be able to track % successful allocations on any
data rate.
FWD SCH Single BTS Requests Cancelled
RVS SCH Single BTS Requests Cancelled
FWD SCH Multiple BTS Requests Cancelled
RVS SCH Multiple BTS Requests Cancelled
- track number of SCH assignment procedures which were cancelled prior to
actual assignment of BTS resources; in single case and multiple BTS case the
point of the commitment differs
FWD SCH BTS Assignments Cancelled
RVS SCH BTS Assignments Cancelled
- track number of SCH assignment procedures which were cancelled only after
the actual assignment of BTS resources happened (together with "requests
cancelled" pegs, represents total cancellations)
Derived measurements:
FWD SCH Allocation Successes - Total
RVS SCH Allocation Successes - Total
- gives total number of successful procedures per data rate requested
FWD SCH Requests Not Cancelled - Total
RVS SCH Requests Not Cancelled - Total
- gives effectively how many SCH allocation procedures are completed without
being interrupted by a request cancellation; (if the cancellation happens AFTER
the procedure already resulted in a successful BTS Resource Response (in Single BTS case) or the SDU Commit (in Mult. BTS case), it is not considered here)
- this number is needed to correct the total number of SCH requests for purpose
18
2002 Motorola, Inc

of determining the success rate, since cancelled requests cannot be considered
neither a success nor a failure
FWD SCH Allocation Successes - Matched Data Rate
RVS SCH Allocation Successes - Matched Data Rate
- with respect to the number of SCH Requests Not Cancelled (above), represents
the percentage of successful procedures in which the initially committed data
rate equals the requested (attempted) data rate.
- does not account for post-commitment data rate changes
FWD SCH Effective Usage
RVS SCH Effective Usage
- this measurement accounts for assignment cancellations and data rate
changes, and gives the timeslice usage, in seconds, for each data rate; if
summed over all data rates, gives total SCH usage on the BTS
3.1.2 BTS Carrier-Sector SCH Allocation Report

SCH Allocation failures due to "No RF Capacity" and "No Walsh Codes" are included in
the previous set of measurements (BTS per Data Rate) in order to determine how (if at all)
those types of failures depend on the requested data rate. For example, there may be a
shortage of WCs of certain length, which are needed for certain data rates; also, it is more
likely that the RF capacity would be exhausted on a request for a high data rate. However,
those failures are captured at the Carrier/Sector level as well, because RF capacity and
WCs are needed per Carrier/Sector.
Due to implementation, those failures are pegged only against the first carrier-sector
involved in the allocation request which was found to cause this failure - if one was found,
there is no checking against remaining ones, the Failures is sent immediately and the procedure is terminated.
To interpret the number of failures, the number of Requests is also tracked (lumped
together for Single and Multiple BTSs case).
Raw measurements:
CSEC FWD SCH Requests
CSEC RVS SCH Requests
CSEC FWD SCH Requests - Failures - No Walsh Codes
CSEC FWD SCH Requests - Failures - No RF Capacity
CSEC RVS SCH Requests - Failures - No RF Capacity
There are no Derived measurements specified. To calculate % of failures, divide Failures
by the number of SCH Requests.
3.1.3 Packet Pipe SCH Allocation Report


19
2002 Motorola, Inc

Only MCC1Xs can be equipped with a packet pipe.
Due to no backhaul bandwidth or no CEs, blocking can occur on the MCC1X. These measurements will help the customer determine if more CEs or more backhaul bandwidth is
needed per specific MCC1Xs.
It is more likely that blocking situations would occur more frequently for higher data rates.
Therefore all the stats are broken per Data Rate level, but can be summed up to the
Packet Pipe level to get total statistics per Packet Pipe. This break-down by Data Rate is
also useful for calculating the total throughput per Packet Pipe.
The Data Rate is represented in the same way as for the BTS per Data Rate Record
pmC_45_hr.
Raw measurements:
Packet Pipe FWD SCH Resource Requests
Packet Pipe RVS SCH Resource Requests
- tracks the requests received at the BTS from the SDU, i.e. the same event as
the BTS/Data Rate and the BTS/Carrier-Sector level pegs, but on a different
level: MCC1X per Data Rate; also used for interpretation of the rest of pegs on
this level
Packet Pipe FWD SCH Request Failures - No Backhaul Bandwidth
Packet Pipe RVS SCH Request Failures - No Backhaul Bandwidth
Packet Pipe FWD SCH Request Failures - No Channel Elements
Packet Pipe RVS SCH Request Failures - No Channel Elements
- tracks the number of "no backhaul bandwidth" (or "No Channel Element")
Cause Values sent back to the SDU, per REQUESTED data rate (notice that
the algorithm will try lower data rates as well before declaring the failure); this
will happen when the prevailing cause for failing the procedure is the absence of
the available bandwidth (or channel elements), and it is pegged per the MCC1X
because the on-demand SCHs must be assigned on the same MCC1X which
holds the call;
Packet Pipe FWD SCH Expected Transmissions
Packet Pipe RVS SCH Expected Transmissions
- used to measure scheduled traffic and estimate the average usage on a Packet
Pipe; measures all the expected transmissions of a certain Data Rate on a
Packet Pipe, which represents all the scheduled SCH assignments which are
not cancelled by the time that the scheduling stops for the current timeslice
- this number can differ in terms that the data actually transmitted may have a
lower Data Rate, or maybe no data gets transmitted at all, but as far as the
resource usage goes, the resources cannot be reused for anything else since it
is reserved for this expected transmission;
- for stats which measure ACTUAL transmission, see the SCH Group pegs
3.1.4 Packet Pipe SCH Utilization Report

These measurements track the usage and throughput per individual Packet Pipe (associated with the MCC1X Id) and are given in Table pmC_02_hr.
20
2002 Motorola, Inc

For each pending timeslice, the BTS keeps track of the total assignment (in kbps) so it
knows if it can accept a new assignment on the timeslice,or must it defer it to another
timeslice;
In order to see what is the timeslice usage, we peg the maximum, minimum and the average scheduled timeslice throughput per the collection period (it is possible that the minimum throughput be zero, if there are unused timeslices, and that the maximum equals the
maximum bandwidth of the Packet Pipe;
Min and Max are Raw pegs; Average is Derived from a compatible statistic on the Packet
Pipe per Data Rate level (see 3.)
Raw measurements:
Packet Pipe FWD SCH Max Scheduled Timeslice Throughput
Packet Pipe RVS SCH Max Scheduled Timeslice Throughput
Packet Pipe FWD SCH Min Scheduled Timeslice Throughput
Packet Pipe RVS SCH Min Scheduled Timeslice Throughput
- these measurements are given in 10*(kbps), in order to transfer them without
the floating point (as integers), because our pegs are all integers
-calculated as a Max and Min over the whole collection period, based on scheduled throughput on the current timeslice when no additional assignments are
possible for the timeslice
- "Max" should correlate with "No Backhaul Bandwidth" failures and can be used
to guide adding of additional bandwidth
-"Min" should be low;
Packet Pipe FWD SCH Avg Scheduled Timeslice Throughput
Packet Pipe RVS SCH Avg Scheduled Timeslice Throughput
- To be used in conjunction with "Max" and "Min" measurements and to monitor if
each timeslice would have equal throughput (in 10*kbps), what it would amount
to
Packet Pipe FWD SCH Max Scheduled Timeslice Bit Usage
Packet Pipe RVS SCH Max Scheduled Timeslice Bit Usage
Packet Pipe FWD SCH Min Scheduled Timeslice Bit Usage
Packet Pipe RVS SCH Min Scheduled Timeslice Bit Usage
Packet Pipe FWD SCH Avg Scheduled Timeslice Bit Usage
Packet Pipe RVS SCH Avg Scheduled Timeslice Bit Usage
- Same quantity as the previous measurements, but given in kbits transferred
during a maximally/averagely/minimally loaded timeslice (can range from 0 to
packet pipe's bandwidth)
Packet Pipe FWD SCH Total Scheduled Interval Bit Usage
Packet Pipe RVS SCH Total Scheduled Interval Bit Usage
21
2002 Motorola, Inc

- represents TOTAL Megabits (Mb) transferred during through the Packet Pipe
during the collection interval
SCH Group FWD CEs Equipped - MCC1X
SCH Group RVS CEs Equipped - MCC1X
- derived from the SCH Group Configuration record - represents the total number
of CEs (grouped into groups of 1, 2, 4, 8, 16 or 32) available on the MCC1X for
Supplemental channel allocation
SCH Group FWD Usage - MCC1X (Commits)
SCH Group RVS Usage - MCC1X (Commits)
- represents the total expected SCH CE usage, in seconds, as follows from the
number of SCH Group commits (see SCH Group stats for more details)
SCH Group FWD Usage - MCC1X (Transmissions)
SCH Group RVS Usage - MCC1X (Transmissions)
- represents the total SCH CE usage, in seconds, as follows from the number of
SCH Group transmissions (see SCH Group stats for more details) and differs
from the "Commits" (see above) only if there were "zero-transmissions" i.e. if at
the end of the timeslice the MCC1X determined that there was actually NO data
transferred; if there was ANY data sent, even if it's a lower data rate then previously committed, it contributes to this measurement.
3.1.5 SCH Group Allocation / Utilization Report

There are different SCH Resource Groups on MCC1X, separately for the FWD and RVS
direction; A SCH Group Type X means "consisting of X CEs" in the following text; possible
values of X are: 1, 2, 4, 8, 16, and 32 CEs (32 only in FWD direction)
The user can configure various number of members per the SCH Group Type. The mapping of how many members are configured per particular group type (separately for FWD
and RVS direction) is given in the "SCH Group Configuration Record" pmC_83_hr.
Since the user can configure arbitrary numbers of elements per SCH Group type, and
since the optimal number will differ from system to system (depending on user profiles,
number of requests per various data rates, etc.), we are providing some statistics to track
efficiency of SCH Group allocation
Apart from the Configuration record, there is another record, pmC_77_hr, where some
SCH allocation statistics are taken at the BTS / MCC1X / SCH Group Type Used / SCH
Group Type Needed level, where: SCH Group Type Used is the group being 'tried'
(attempted, committed, or actually transmitting), when
SCH Group Type Needed is the minimal group needed to satisfy the data
rate needed for that same 'try' (attempt, commit, or actual transmission)
SCH Group Type Used must be greater than or equal then SCH Group
Type
Needed, so for a particular MCC1X, here are all possible rows of data:
SCH Group Type Used
SCH Group Type Needed

22
2002 Motorola, Inc

(pmC_77_hr.subj_id_3)
(pmC_77_hr.subj_id_4)
===================== =====================
1
1
2
2
1
2
4
4
4
...
16
16
16
16
16
1
2
4
1
2
4
8
16
Due to implementation, it may actually not be possible to have any Attempts/Failures/

Commits for combinations of Used/Needed such as 16/1, since the algorithm shall not
make attempt on a group much bigger than needed (it could allocate too many resources
and lead to poor performance), but since the final Transmissions do not depend on the
allocation algorithm, the final data rate transmitted can happen to be very low and some
occurrences of 16/1 could happen (or no transmission at all, which would not even peg
and could be only determined by the total difference between Commits and Transmissions
for the SCH Group Type (Used).
For all the resource engineering purposes, we should consider Commits, since no matter
what the actual Transmission would be minimally needing to use, the resources are
reserved beyond option to re-use for something else after the Commit happens.
The effective number of CEs per SCH Group Type used should help accessing how well
individual CEs are used
Number of Failures per Number of Allocation Attempts is meant to be used for optimally
tweaking the number of members per each SCH Group Type, i.e. if the user sees that
there are too many Failures 4/4 and 4/2 (Used/Needed) as opposed to very few failures 8/
8 and 8/4, the user may want to equip additional groups of 4 CEs at the expense of the
group of 8 CEs (unless there are far too many more requests for data rates minimally
served by a group of 8 than there are requests for a group of 4, in which case some other
group(s) should be 'taxed' (16).
Raw measurements:
SCH Group FWD Allocation Attempts
SCH Group RVS Allocation Attempts
- this measurement DIFFERS from all other "SCH Resource Requests" measurements on the BTS/Data Rate, Carrier-Sector or MCC1X level; it represents
number of actual SCH Group attempts,
- one per each timeslice configured example: if there are 5 timeslices for a Data
Rate which in a given radio configuration needs 4 CEs, there will be at least 5
"Allocation Attempts" on SCH Group Type Used/Needed combination of 4/4; if 2
of them fail, there will be 2 "Allocation Failures - No Idle Members", as well as 2
"Allocation Attempts" on Used/Needed= 8/4, etc.
SCH Group FWD Allocation Failures - No Idle Members
SCH Group RVS Allocation Failures - No Idle Members

23
2002 Motorola, Inc

- to be used in conjunction with the above measurements (see the above example) means that there are no available Members of the "SCH Group Type Used"
for an assignment which minimally needs a "SCH Group Type Needed" but
does not mean that the SCH request failed since there may be other resources
available, on the same as well as other timeslices
SCH Group FWD Allocation Successes (Commits)
SCH Group RVS Allocation Successes (Commits)
- pegged once per successful SCH allocation procedure, i.e. NOT per timeslice (if
there are 5 timeslices, up to 5 SCH Groups may be Reserved (see Derived
measurements below), but only ONE SCH Group/Timeslice pair will be Committed;
SCH Group FWD Transmissions
SCH Group RVS Transmissions
- represents the actual number of transmissions per SCH Group Type Used /
SCH Group Type Needed; it differs from the "Commits" peg if the transmission
occurs on a Data Rate lower than Committed (or none at all), which means that
for the same "SCH Group Type Used", it may get pegged against a smaller
"SCH group Type Needed" (or none at all).
Derived measurements (some on the "SCH Group Type Used" vs. "SCH Group Type
Needed" level; some on the unique "SCH Group Type (Used)" level:
SCH Group FWD Members Configured
SCH Group RVS Members Configured
- belong to the Configuration table pmC_83_hr; give number of equipped groups
per each SCH Group Type (MCC1X/SCH Group Type)
SCH Group FWD Allocation Failures - No Idle Members (%)
SCH Group RVS Allocation Failures - No Idle Members (%)
- gives percentage of Failures on each allocation attempt per SCH Group Type,
irrespective of which SCH Group Type was minimally "Needed" (MCC1X/SCH
Group Type)
SCH Group FWD Allocation Successes (Reservations)
SCH Group RVS Allocation Successes (Reservations)
- represents number of successful reservations per timeslice, which is in fact a
difference between "Allocation Attempts" and "Allocation Failures - No Idle
Members" (MCC1X/SCH Group Type Used/SCH Group Type Needed)
SCH Group FWD Effective Number of CEs Used (Commits)
SCH Group RVS Effective Number of CEs Used (Commits)
- for each SCH Group Type (X), gives how many CEs out of X are used on the
average per a resource Commit
- example: if for SCH Group Type 8, we had 1 Commit when we minimally
needed 4 CEs, (8/4) and 3 Commits when we minimally needed exactly 8 CEs
(8/8), our average number of utilized CEs for Group 8 is: (1*4 + 3*8)/(1 + 3) = 7
24
2002 Motorola, Inc

CEs. So we used, on the average, 7 out of 8 CEs for members of SCH Group
Type 8.
SCH Group FWD Effective Number of CEs Used (Transmissions)
SCH Group RVS Effective Number of CEs Used (Transmissions)
- for each SCH Group Type (X), gives how many CEs out of X are ACTUALLY
(measured post-transmission) used on the average
- see the above example, except "Transmissions" should be in place of "Commits"
- Potentially lower number than "Commits" due to last-moment cancellations and
data rate reductions which the BTS was not aware ahead of the actual transmission
3.1.6 BTS SCH Allocation Failures Report

Measurements covered on the BTS level are number of SCH Resource Requests and all
different types of allocation Failures which can be reported, and are given in Table
pmC_75_hr.
Since various failures are tracked on various levels (BTS, Carrier-Sector, MCC1X-levels),
the BTS level is where we report them all, in order to compare % occurrence of various
Failures
Raw measurements:
BTS FWD SCH Resource Requests - Failures - No Common Timeslice
BTS RVS SCH Resource Requests - Failures - No Common Timeslice
- if SDU cannot find a common timeslice for each of the BTSs involved in the
SCH Resource Request, it will report that failure to each BTS involved
BTS FWD SCH Resource Requests - Failures - Timer Expiry
BTS RVS SCH Resource Requests - Failures - Timer Expiry
- if the BTS or the SDU detect a timer expiry during the SCH allocation procedure, this failure will be pegged
BTS FWD SCH Resource Requests - Failures - CPU Overload
BTS RVS SCH Resource Requests - Failures - CPU Overload
- if a BTS detects its CPU is overloaded, it does not send any response to the
SDU, but it pegs this type of failure (SDU would detect a timer expiry, which it
would send to the remaining BTSs)
BTS FWD SCH Resource Requests
BTS RVS SCH Resource Requests
- derived from the Packet Pipe-level record, since there is one-to-one mapping
(only one Packet Pipe (MCC1X) pegs per one BTS request); given in order to
interpret % of Failures
25
2002 Motorola, Inc

BTS FWD SCH Resource Allocation Failures - No Walsh Codes
BTS FWD SCH Resource Allocation Failures - No RF Capacity
BTS RVS SCH Resource Allocation Failures - No RF Capacity
BTS FWD SCH Resource Allocation Failures - No Backhaul Bandwidth
BTS RVS SCH Resource Allocation Failures - No Backhaul Bandwidth
BTS FWD SCH Resource Allocation Failures - No Channel Elements
BTS RVS SCH Resource Allocation Failures - No Channel Elements
-derived per subtending BTS/Data Rate and MCC1X/Data Rate measurements
by summing over all Data Rates
3.1.7 Packet Data Statistics Activations - XC Report

3.1.8 Packet Data Statistics Sessions Bytes - XC Report
3.1.9 Packet Data Statistics Packet Size - XC Report
3.1.10 Packet Data Statistics Sessions Durations - XC Report
3.1.11 XC PCF-CE Report
3.1.12 XC PCF-RA Report
3.1.13 CDMA Call Setup Timing - MM Report
3.1.14 Sector Call Setup Effectiveness Report
3.1.15 Packet Data Activity - MM Report
3.2 CDL Logs

On a per call basis, CDL logs provide detail information about a specific call that
has completed. It is also used to provide an indication of specific types of call failures.
The following elements in CDL can be very useful for understanding data calls
and identifying possible problems related to call setup and throughput. It is important to look all the listed elements in CDL log as entirety. Individual element alone

26
2002 Motorola, Inc

can sometimes mislead. For detail, please refer to Call Detail Log section in
CDMA Call Processing System Functional Specification document.[1]

27
2002 Motorola, Inc

Table 1. Packet Data Related CDL Elements
CDL Log (Appendix)
ACCESS_TIME
RELEASE_TIME
XC_RELEASE_TIME
ENTRY_TYPE
SERVICE_OPTION
NEGOTIATED_SO
LAST_MM_SETUP_EVENT
CFC
FWD_QUALITY
LAST_FWD_INCR
RVS_QUALITY
LAST_RVS_INCR
RVS_ERASE_COUNT
RF_FADE_COUNT
PKT_DATA_TYPE
PSI_SDU_ID
PDSN_IPADDR
PCF_IPADDR
PCFRA_IPADDR
BYTES_FWD
BYTES_RVS
TIME_FWD
TIME_RVS
DATA_ATTEMPTS
DATA_AT_RQSTD_RATE
DATA_BELOW_RQSTD_RATE
Understanding
Time when Mobile Origination or Page Response is received. Must. Used
for calculating throughputfor the call.
Time when MS is released at MM
Time when MS is released at XC. This is the time reported by PCF
0 - Origination, 1 - Termination, 2 - Hard handoff, 3 - Soft handoff
SO33 for highspeed packet data, It should be 0x0021
Service option if changed
15 - A+ Assignment Request rx
16 - Assignment of the MS to a TCH was initiated (SCAP Channel
Assigned sent to channel element)
17 - The MS was successfully assigned to a TCH (SCAP XC Assignment
Successful rx)
18 - A+ Assignment Complete tx
24 - Assignment of XC resources was initiated (SCAP XC Channel
Assigned sent to XC)
25 - Connection of the terrestrial circuit was initiated (SCAP XCAssigned
sent to XC)
26 - SCAP: CDMA PCF Resource Request sent
27 - SCAP: CDMA PCF Resource Response received
28 - SCAP: CDMA PCF Assignment sent
Call Final Class. Must. Refer to Section 4 for possible CFC values.
Count the number of intervals during which MS etecs excessive forward
TCH FERs.
Time when FWD_QUALITY was last incremented.
Count the number of 2.56 second intervals during which MS detects
excessive reverse TCH FERs.
Time when RVS_QUALITY was last incremented.
Frame erasure count during the 2.56 interval when the call ended.
Count of number of times the CPP received an indication of RF LOSS.
Only for IWU Packet
16 bits, display in hexadecimal. With the following format (00=MSB):
00 - 07: 8 bits - PSI_SDU CARD ID
08 - 11: 4 bits - DSP ID
12 - 15: 4 bits - logical channel number
It shows IPs after successful call setup. These fields will not be filled if
setup fails.
Total number of Kbytes transmitted in the forward/reverse direction. Used
for calculating throughput for the call.
Must. These fields indicate SCH is used for data call.

28
2002 Motorola, Inc

3.3 System Fault Notifications
System is constantly been monitored for possible fault. Alarms are generated by
individual network element when faults are detected. Alarms are then forwarded
to the alarm manager on UNO.
The list below shows some of alarms defined in R16.0 system that are related to
packet data call. For detail and entire alarm list, please refer to System Surveillance, Reconfiguration, and Recovery System Function Specification (SSRR
SFS).[5]
Alarms related to PKTPCF
PKTPCF - PSI to MM SCTP Connection Lost
Whenever MM detects that the SCTP connection to PKTPCF is lost, then MM attempts to
recover the lost connection. If the connection was successfully recovered, then the PKTPCFresources remain available for allocation. Recovery counter is incremented. This alarmis generated when the value of theRecovery Counter reaches max_pcf_recovery
during an hour. Note that this counter is reset every hour.
PCF Resources Unavailable

This alarm is generated bythe PKTPCFwheneverit determines that it has lost all SCTPconnections to MM. At that moment PCF resources will be unavailable at the MM for allocation.
PSI to PDSN Communication Loss

The PKTPCF PSI maintains a list of the PDSNs which have failed to respond to ping messages. Whenever any PKTPCF PSI does not receive ping responses from a PDSN, this
alarm is raised. If this alarm is already set then the alarm is cleared and set again with IP
address of the PDSN added to the list which is listed in the additional text field. If the PKTPCFPSI is able to get the response to the ping message from PDSN, then the alarm is
cleared and set again with the IP address of that PDSN removed from the list which is
listed in the additional text field. The alarm is cleared (with no PDSNs in the list) whenever
all the PDSNs are responding to the pings. For an alarm clear, the additional_text field will
have the IP address of the PDSN to which the PKTPCF PSI is able to talk.
PKTPCF Out-of-Service - Manual

This alarm indicates that the PKTPCF PSI is out of service due to an operator command
to LOCK the host PSI card.
PKTPCF Out-of-Service - Faulted Board

This alarm indicates that the PKTPCF PSI is out of service due to a failure of the host PSI
device to communicate with the Cage Controller GPROC after the GPROC received a
spurious interrupt or another error information from the PSI. This alarm indicates that the
PSI has failed.
PKTPCF Out-of-Service - General Disable

29
2002 Motorola, Inc

This alarm indicates that the PKTPCF PSI is out of service due to a disable action. The
system has disabled the host PSI board through device state management software and
no hardware or software alarm indication is associated with the disable.
PKTPCF Out-of-Service - Clock A Signal Lost (GCLK to PKTPCF)

This alarm is posted when the PKTPCF PSI stops receiving GCLK As signal and the
error source has been isolated to the implicated PSI by the system.
PKTPCF Out-of-Service - Clock B Signal Lost (GCLK to PKTPCF)

This alarm is posted when the PKTPCF PSI stops receiving GCLKBs signal and the
error source has been isolated to the implicated PSI by the system.
PKTPCF Out-of-Service - Front Panel Reset

This alarm is posted when the PKTPCF PSIs front panel is reset by the operator.
PKTPCF Out-of-Service - Watchdog Timer Expired

This alarm is posted when the PKTPCF PSIs watchdog timer is expired. It might be due
to hardware (or software) malfunction in the PSI board (or PKTPCF software).
PKTPCF Out-of-Service - Communication Failure Over PBUS

This alarm is posted when the GPROC detects a failure in communicating to the PKTPCFPSI over a PBUS.
PKTPCF Out-of-Service - MCU Internal Fault

This alarm is posted when the PKTPCF PSI detects a MCU internal fault.
PKTPCF Initialization Failure

This alarm is posted when the PKTPCF PSI detects an initialization failure. The initialization process has detected an error during the tests performed.
PKTPCF Out-of-Service - Initialized Unexpectedly

This alarm is posted when the PKTPCF PSI gets unexpectedly initialized.
PKTPCF Out-of-Service - General Reset

This alarm is posted when the PKTPCF PSI is reset. It might be due to hardware (or software) malfunction in the PSI board (or PKTPCF software).
PKTPCF - LMLS to PSI Link Failure

This alarm is posted when the PSI fails to ping the Access Node Logical IP Address.
Similar alarms related to PKTIF and PKTSEL cards are defined in SSRR[5] as
well.
Alarm Manager on UNO displays detail description of the alarm. It is important to
monitor alarms related to these devices and take appropriate actions.
30
2002 Motorola, Inc
For preventative purposes, Performance Management Thresholding (PMT) feature on UNO provides functionality to monitor PM data, generate PMT alarms
based on threshold setting. PMT alarms can be defined based on individual pegs
and CFCs, as well as User Defined Measurements.[4]
3.4 Tools
The following monitoring and debug tools can be used for troubleshooting call
setup as well as low data throughput problems.
3.4.1 DUN Monitor
Displays summary data such as bytes transferred on a PPP session basis
Useful for flagging PPP errors
3.4.2 Microsoft Performance Monitor

Invoke by perfmon
31
2002 Motorola, Inc

Useful for monitoring data throughput
Need configuration to add counters for rx/tx byte/sec
Monitor TCP Performance by adding TCP counters
Identify errors
3.4.3 Motorola Netspy

Product developed by Motorola
Collect data from many sniff points
Understand RAN protocols
Fault isolation features
Analysis of bearer as well as control traffic
Motorola internal use only

32
2002 Motorola, Inc
3.4.4 SMAP
Motorola official product
System performance monitoring
RF tuning
Real-time call trace
CDL analysis
RLP statistics
FER statistics
Can be used for troubleshooting data call

33
2002 Motorola, Inc
3.4.5 Netmon
Microsoft Sniffer Utility
Standard package with Microsoft Server Operating systems
Capability to capture data directly from Microsoft PPP stack
Very useful to capture data in and out of client

34
2002 Motorola, Inc
3.4.6 Qualcomm CDMA Air Interface Tester (CAIT)

Diagnostic monitor from MS perspective
Collects statistics from mobile perspective
Real-time
RLP statistics
FER information
Power Level
Software runs on a laptop with Windows 95/98/NT.
Note: RLP reset value starts at 1 in CAIT.

35
2002 Motorola, Inc

36
2002 Motorola, Inc
4. Troubleshoot - Call Setup Failures

4.1 Methodology
Figure below shows all relevant elements involved in end-to-end packet data
calls.
Figure 4. Logical flow Diagram
AAA
MGX
PC
MS BTS DACS
SEL PCF PDSN
HA
FTP
CE
FCH and SCH data
FCH data
SCH data
*CAT not shown since it only provides physical transport
Each link in the diagram can possibly attribute to call setup failure and low
throughput.
On RAN, MM will generate Call Detail Log (CDL) and then log at OMC-R. The
Call Final Classes (CFCs) for CDMA are also specified in CDL. The CFC provides
an indication of why a call fails. A browser facility provides a user interface to the
CDLs logged at the OMC-R. Examples are provided in Appendix A. Section 4.2
provides detail description of call failure cases and associated CFC value generated in CDL. The call flow in Figure 4, on page 2-16 is highlighted with CFC values to identify when call setup can fail during the call setup.
From user perspective, call failure can be categorized into setup, stable, mobility,
and application error. Section 4.3 describes scenarios of call failures or releases
and what action should take.

37
2002 Motorola, Inc

4.2 CFC Based Approach
Figure 5. CFC Based Decision Tree
CDL Analysis
Failure
Type
Setup
Stable
15
112
04
138
139
111
142
143
113
32
03
04
20
05
13
4.2.1 CFC 03
CDL log is generated with CFC 03 when XC subsystem detected a L2 failure during
the call setup. This can happen between Step 54 and 63 in Figure 4, on page 2-16.
This problem could occur to voice call as well.
4.2.2 CFC 04
CDL log is generated with CFC 04 when XC subsystem detects an RF loss during the
call or call setup. XC subsystem determines that the radio channel has been lost.
This can happen between Step 54 and thereafter in Figure 4, on page 2-16. This
could happen if user is mobile. This problem could occur to voice call as well.

38
2002 Motorola, Inc

4.2.3 CFC 05
CDL log is generated with CFC 05 when MS does not arrive on the assigned TCH during the call setup. This happens between Step 37 and 49 in Figure 2, on page 2-3.
This problem could occur to voice call as well.
4.2.4 CFC 15
CDL log is generated with CFC 15 when CPP fails to negotiate the service option/configuration during the call setup. This happens between Step 55 and Step 56 in Figure
2, on page 2-3. Refer to the service negotiation section of the call flow.
Action:
Make sure there is signal strength on MS.

Try the call again. It might be a temporary RF condition.
Try voice call to see if there is an RF coverage problem in the area.
Refer to CFC Resolution Document for detail if problem exists for
voice call as well.[7]
4.2.5 CFC 12
CDL log is generated with CFC 12 when call setup timer (XcCpT11) in CPP times out.
This can happen after Step 27 in Figure 2, on page 2-3, where the timer starts. If timer
is not stopped (Step 62 in Figure 2, on page 2-3) before the expiration, the call will fail.
This problem could happen to voice calls as well.
Action:
USe CLI to display the timer and verify [Need to provide command]
4.2.6 CFC 13
CDL log is generated with CFC 13 when CPP fails to receive L2 acknowledgment for
the service option negotiation during the call setup. This happens between Step 55
and Step 56 in Figure 2, on page 2-3. THis problem could happen to voice calls as
well. Refer to the service negotiation section of the call flow.
4.2.7 CFC 32
CDL log is generated with CFC 32 when the requested service option is disabled in
the database (MM). This can happen after Step 5 in Figure 2, on page 2-3, where MM
checks service option database to see if packet data service option is enabled or set
to negotiate.
Action:
Verify the service option database using CLI command

Fix the service option database on MM via OMC-R CLI if necessary.
4.2.8 CFC 20
CDL log is generated with CFC 20 when CBSC does not have a channel element or
walsh code available to assign to a call during the call setup. This can happen after
39
2002 Motorola, Inc

Step 6 in Figure 4, on page 2-16, where MM tries to allocate a TCH, CPP and WC. It
must happen before Step 8 in Figure 2, on page 2-3, where MM sends CDMA Channel assignment. This problem could happen to voice calls as well.
Action:
Use CLI commands to verify there is available channel elements on

MCC and Walsh code configured on sector-carrier.
Make changes if necessary.
Try the call again.
4.2.9 CFC 111

CDL log is generated with CFC 111 due to normal release of a packet-oriented data
call.
Action:
This is normal release from RAN perspective. However, the user

might experience discontinuity in the data session.
Check the session status on PDSN and take proper action per PDSN
procedure.
4.2.10 CFC 112

CDL log is generated with CFC 112 when a packet-oriented data call is released due
to setup failure. This happens after Step 80 in Figure 2, on page 2-3. Check if this is
applicable for high speed packet data service by looking at Service Option in CDL.
Action:
It is hard to tell from CFC alone. Need to look at Cause value in SCAP
message to determine if it is due to TA8 setup timer expires or equipment failure.
Try the call again. It might be due to heavy load on the system.
4.2.11 CFC 113

CDL log is generated with CFC 113 when the data call is released due to an invalid
message or protocol violation.
Action:
Is it reproducible?
Is it the cause of one specific type of mobile?
4.2.12 CFC 138

CDL log is generated with CFC 138 when XC does not have any PSI-SEL to associate with the call during the call setup. This happens after Step 27 in Figure 2, on page
2-3, where CPP tries to allocate PSI-SEL resource.
Action:
Maybe PSI-SEL is busy.

Verify PSI-SEL is in service and has resource.
Generate XC PSI-SEL report for further study.
4.2.13 CFC 139

CDL log is generated with CFC 139 when XC does not have any PSI-CE (or PSI-IF) to
associate with the call during the call setup. This happens after Step 27 in Figure 2,
on page 2-3, where CPP tries to allocate PSI-CE resource.

40
2002 Motorola, Inc

Action:
Maybe PSI-CE is busy.

Verify PSI-CE is in service and has resource.
Generate XC PSI-CE report for further study.
4.2.14 CFC 142

CDL log is generated with CFC 142 when PCF fails to setup the A10/A11 interface
due to PDSN resources are not available. This happens after Step 86 in Figure 2, on
page 2-3. At the same time, we should be able to see alarms related to PCF-PDSN
connection on UNO.
Action:
CDL should also contains the IP addresses of PCF and PDSN

Check the availability of PDSN by ping command
If PDSN responses to ping, PDSN might have reached its capacity.
Verify PCF has proper key and SPI with respect to PDSN
Motorola PCF refers to Keys in hex format. Verify the key representation of particular PDSN vendor.
Verify PDSN status per PDSN vendor documents.
4.2.15 CFC 143

CDL log is generated with CFC 143 when A8/A9 interface between PSI-SDU and PCF
setup fails due to PCF resources are not available during the call setup. This can
happen after Step 23 in Figure 2, on page 2-3, where MM might receive PCF resource
response from PCF-RA indicating PCF is not available. As part of the resource management on MM and SDU, request will be sent to the next PCF-RA in the PCF-RA list.
Upon exhausting all PCF-RAs in the list, the call will be released and CFC 143 will be
logged.
It can also happen before Step 89 in Figure 2, on page 2-3, where A8/A9 setup fails.
The description of CFC 143 is "PCF Resources Not Available". As indicated below,
there are 2 cases here:
1) If the MM received no response after it sent the PCF Resource Request, the MM
will retry. Only after exhausting its retry would the MM deem "PCF Resources Not
Available". Possible reasons for not getting a response are:
a) The SCTP link between the MM and the PCF-RA is down. If this were the
case, the SCFM would detect the outage and inform the MM not to use the
PCF-RA.
b) The timer setting for the PCF Resource Request is too small causing it to
expire quickly. If this is the case, the timer setting should be increased.
2) An explicit PCF Resource Response was received by the MM indicating no PCF
resources are available. If so, the MM will select another PCF-RA for a PCF
resource. Request denied is possible if all the PCF-RAs are full.
For CFC 143, the Cause value will also indicate "PCF Resources Not Available",
which does not allow us to distinguish between case 1) and 2) above. In a future
release, Motorola will look into identifying 1) and 2) via cause value within CFC143, if
our customers indicate to us that this is an important distinction for them, based on the
frequency of occurrence and value for trouble shooting in the field.
Action:
This condition occurs when PCF is overloaded.

CDL should contains the IP addresses of PCF.
IF PCF IP address is blank, it means no PCF is available and system is
busy.
Check the availability of PCF and try the call again
41
2002 Motorola, Inc
Otherwise, PCF might have a problem since it can not setup A8/A9.
4.3 User Experience Approach

Figure 6. User Perception Decision Tree
Start Analysis
Failure
Type
Stable
Failure
Setup
Mobility
(Handoff)
Application
New PDSN
Authentication
New call
Reactivation
RF/L2
Same PDSN
Equipment
Timeout
Network
IPCP
Failure
PDSN
MS Alarm
PCF/SDU
Mobile
4.3.1 Authentication Failure

During the call setup, user authentication might fail.
4.3.2 Authentication Time-out

During the call setup, user authentication might time-out if local AAA or home AAA are
not reachable/congested.
Action:
Determine PPP error using Netmon (Microsoft debug tool) or via

PDSN. Caution: Enabling PPP debugging may have negative impact
on PDSN
Verify the communication between PDSN and AAA.
Verify user profile on AAA is valid.
Verify user name and password is entered correctly.
42
2002 Motorola, Inc

4.3.3 IPCP Negotiation
IPCP is responsible for configuring, enabling, and disabling the IP protocol modules
on both ends of the point-to-point link. It is used to assign and negotiate IP address
and header compression parameters. This can fail if PDSN does not have IP
resources available (No more IP left in the IP pool.)
IPCP will fail if MS or laptop is configured to use static IP address.
Action:
Verify the MS or laptop does not have static IP and it allows dynamic
IP assignment (TCP/IP property).
Verify PDSN or AAA has sufficient IP resources available.
4.3.4 Mobile-Initiated Reactivation

MS can go into the dormancy if there is not data activity or infrastructure forces MS to
go into the dormant state. When MS/laptop attempts to send data, it will try to reactivate the PPP session. The reactivation can fail if PPP state is not in sync between
PDSN and MS/laptop. This can happen because:
Infrastructure tears down the dormant session
Mobile move to a new PDSN serving area without support for packet zone
re-registration.
PDSN/PCF equipment failure during dormancy
Action:
The session is lost and MS/laptop has to re-establish a new packet

data session (new call).
4.3.5 Network-Initiated Reactivation

MS can go into the dormancy if there is not data activity or infrastructure forces MS to
go into the dormant state. When network attempts to send data to this mobile, the
mobile shall respond to the networks page and reactivate the PPP session. The
reactivation can fail if PPP state is not in sync between PDSN and MS/laptop. This
can happen because:
If MS has cleared the session, when paged by the network, the mobile will
fail to reactivate the call.
Mobile move to a new PDSN serving area without support for packet zone
re-registration.
PDSN/PCF equipment failure during dormancy
If packet zone area is not configured properly to match the paging zone area, the page will fail.
Action:
The session is lost and MS/laptop has to re-establish a new packet

data session (new call).
Verify packet zone and paging zone are configured properly.
4.3.6 MS Alert during Idle State

It is reported in the field that some idle mobiles alert in responding to an network reactivation attempt. This is probably due to mobile/laptop tearing down the PPP session,
without informing the PDSN/PCF. Graceful application exit is required to clear the
session completely within the infrastructure.
43
2002 Motorola, Inc

Action:
Identify the mobile.

Verify if this happens to mobiles from other vendors
If the scenario only happens to a particular type of mobile, mobile
might not behave properly during the idle state. Inform the operator.
If the scenario happens to all mobiles, verify resources are cleared on
PDSN/PCF when mobile tears down the PPP session.
Issue AT command AT&C0 to mobile to ensure MS does not toggle
carrier detect line.
4.3.7 RF/L2 Failure

During a stable data call, if there is RF/L2 failure, MS will go into the dormant state.
MS/laptop can reactivate the call to send data. The reactivation might fail resulting the
application failure or time-out.
Action:
Verify MS has sufficient RF strength.

Verify the system is RF optimized.
Verify voice call has good quality and does not have the same problem.
If application times out, it needs to be restarted/reloaded. There is no
need to restart a data session.
4.3.8 PDSN Failure

During a stable data call, if there is PDSN failure, the PPP session to this PDSN is
lost. Any dormant call on this PDSN are also lost. Accounting data associate to
active calls will be lost. MS/laptop has to renegotiate PPP session with a new PDSN.
Application on MS/laptop will fail or time-out.
Action:
Verify alarms raised against this equipment. Fix/replace equipment

per PDSN procedure.
Verify there are still other PDSN available to handle these failed data
calls.
Application needs to be restarted/reloaded.
4.3.9 PCF/SDU Equipment Failure

During a stable data call, if PCF/SDU fails, MS will go into the dormant state. MS/laptop has to reactivate the call. The reactivation might fail resulting the application failure or time-out.
Action:
Verify alarms raised against this equipment. Fix/replace equipment

per PCF/SDU procedure.
Verify there are still other PCF/SDU available to handle data call.
4.3.10 Mobility - Inter-PDSN Handoff

During a hard handoff of a data call, MS will go into the dormant state. If the handoff
results in an new PCF/PDSN, new PPP session has to be established. Application
will failure or time-out.
Action:
New data session establishment may be required.

Application needs to be restarted/reloaded.

44
2002 Motorola, Inc

4.3.11 Mobility - Intra-PDSN Handoff
During a hard handoff of a data call, MS will go into the dormant state. If the handoff
does not result in an new PDSN, there is not need to establish a new PPP session.
However, application might time-out due to dormancy transition.
Action:

4.3.12 Application - TCP/IP

MS fails to establish TCP session with the remote terminal.
Action:
Verify there is IP assignment using ipconfig

Verify the remote host is reachable using ping and retry the application if connection is already established.
If host name is referenced instead of IP address, make sure DNS
server is configured properly.
If user name is required in the application, verify user name and password on the remote host.

45
2002 Motorola, Inc
5. Low Data Throughput

Typical problems attribute to low data throughput
PPP errors
RLP
TCP Window Size
Frame Eraser Rate (FER)
Resource groups not available
5.1 PPP Error

When a mobile station first registers for packet data services, it establishes a
Point-to-Point Protocol (PPP) connection with a PDSN. PPP errors, can occur
due to missing RLP frames, or physical link between MS and terminal. Dial-Up
Networking (DUN) Monitor displays summary data such as speed, bytes transferred on a PPP session basis, and compression. DUN Monitor also flags PPP
errors.
5.2 Radio Link Protocol (RLP)

Radio Link Protocol (RLP) is used with a CDMA2000 system to support data services. When transferring data, RLP is a pure NAK-based protocol. That is, the
receiver does not acknowledge received data frames, it only sends NAK control
frames and requests the retransmission of data frames that were not received.
The retransmission will have negative impact on data throughput.
Most of the time, RLP uses NAK/retransmission to recover data frames. In cases
when RLP determines that it can not recover, it will perform abort or reset procedure. Abort and reset procedures also have negative impact on data throughput.
SMAP is the best tool to monitor data call statistics. It is capable of displaying
RLP performance related parameters.
No. Supplemental Channel
The average number of Supplemental Channels used by the current data call.
Abort Count
The number of RLP data frames transmitted from the mobile station to the base
station/transcoder that were not received within the RLP timer interval (RLP 2
timer). If RLP data frames are not received within the allocated retransmission
interval, they are discarded. If this count is zero, the data delivered to the IWU or
AN/PDSN should be complete and in the proper sequence (there are some
holes in this scenario, like if the RLP layer resets). If this count is nonzero, the
data delivered to the IWU or AN/PDSN contains one or more holes that were
unrecoverable by the RLP protocol.
46
2002 Motorola, Inc
RLP Signalling Overhead
Percentage expressed as 100 less percentage of total bytes transmitted that are
forward signaling.
This field will be blank if the Service Option field is not present in the General Call
State Change message.
Fwd Throughput
The number of bytes transmitted on the forward link of a data call per second.
Rev Throughput
The number of bytes received on the reverse link of a data call per second.
Fwd Retransmit Bytes %
This value indicates, for the total number of both transmitted and retransmitted
bytes sent on the forward link of a data call, the percentage of those total bytes
that were retransmitted bytes.
The Radio Link Protocol layer sends NAK control frames to request retransmission of missing frames that it detected as unreceived. Forward NAK control
frames request the mobile station to retransmit missing frames, and Reverse NAK
control frames request the transcoder/base station to retransmit missing frames.
Rev Retransmit Bytes %
This value indicates, for the total number of both transmitted and retransmitted
bytes sent on the reverse link of a data call, the percentage of those total bytes
that were retransmitted bytes.
The Radio Link Protocol layer sends NAK control frames to request retransmission of missing frames that it detected as unreceived. Forward NAK control
frames request the mobile station to retransmit missing frames, and Reverse NAK
control frames request the transcoder/base station to retransmit missing frames.
Fwd NAK Rate
This is a count of the RLP layer NAK control frames sent on the forward link per
second for the data call.
A forward NAK frame is a control frame sent at the RLP protocol layer from the
base station (transcoder) to the mobile station, requesting the mobile station to
retransmit user data frames that the receiver detected as missing/unreceived, due
to skips in the sequence numbering of the received frames.
Rev NAK Rate
This is a count of the RLP layer NAK control frames sent on the reverse link per
second for the monitored data call.
A reverse NAK frame is a control frame sent at the RLP protocol layer from the
mobile station to the base station (transcoder), requesting the base station to
retransmit user data frames that the receiver detected as missing/unreceived, due
to skips in the sequence numbering of the received frames.
47
2002 Motorola, Inc
% Utilization
This value is the percentage of the transmitted bytes out of the total bytes sent
over the air. This value will show Not Applicable if it relates to a 1X packet data
call.
Avg Fwd OTA Bytes/sec
The average of bytes sent over the air on the Forward link per second.
Avg Rev OTA Bytes/sec
The average of bytes sent over the air on the Reverse link per second.
CDMA system also provides rlpStat that gives basic RLP statistics and information
and is available from PSI prompt on the PSI-SEL.
[18Sep2001 00:15:35] PSI CLI-> rlpstat ?
Usage: rlpstat <dspId> <dsp chanId>
Requests RLP statistics for a specified DSP.
[18Sep2001 00:15:35] PSI CLI-> rlpStat 0 1
Response from DSP: 0
Version: 1
Channel Type: 1
FORWARD_RC: 0x0004
REVERSE_RC: 0x0003
FCH-DCCH:
RATE_FULL
RATE_HALF
RATE_QRTR
RATE_EGHT
NULL
IDLE
FORWARD:
0x0a67
0x0000
0x0000
0x06d3
0x0000 0x06d3
REVERSE:
0x0e10
0x0037
0x000b
0x030e
0x0000 0x02fc
RLP TYPE:
NAK_RNDS
1ST_NAK_RND 2ND_NAK_RND 3RD_NAK_RND
FORWARD:
0x2
0x2
0x3
0xf
REVERSE:
0x2
0x2
0x3
0xf
RLP TYPE:
4TH_NAK_RNDS 5TH_NAK_RND 6TH_NAK_RND 7TH_NAK_RND
FORWARD:
0xf
0xf
0xf
0xf
REVERSE:
0xf
0xf
0xf
0xf
RLP TYPE:
FIRST_RND_NAKS
SECOND_ROUND_NAKS
FORWARD:
0x0064
0x0007
RLP_TYPE:
CONTROL
TOTAL_NAKS
FORWARD:
0x0000
0x0090
REVERSE:
0x0000
0x0033
RLP_TYPE:
RETX SEG_RETX
NEW_DATA_BYTES RETX_DATA_BYTES
FORWARD:
0x0033 0x0000
0x0000a339
0x0000034f
RLP_TYPE:
RETX DUP_RETX
SEG_RETX
NEW_DATA_BYTES
RETX_DATA_BYTES
REVERSE:
0x0063 0x0080
0x002b
0x0008d2b7
0x00000b32
RLP TYPE:
RECD_PKT
RECD_BYTES
LOST_PKT
DISCARDED_PKT
FORWARD:
0x0395
0x0000a339
0x0000
0x0000
RLP TYPE:
CN_HIT_CNT
CN_CLR_CNT
CURRENT_CN
FORWARD:
0x0000
0x0000
0x0000
RLP TYPE:
TX_PCF_PKT
TX_PCF_BYTES
REVERSE:
0x03ee
0x0008ddcd
48
2002 Motorola, Inc

RLP TYPE:
RATE_1 RATE_2 1X
2X
4X
FORWARD:
0x0000 0x0000 0x0000 0x0000 0x0000
REVERSE:
0x0000 0x0bf8 0x0000 0x0000 0x0000
RLP TYPE:
8X
16X 32X
FORWARD:
0x0000 0x0000 0x0000
REVERSE:
0x0bf8 0x0000 0x0000
RLP RTT:
0x08
RLP3_RESET_COUNT: 0x00
LAST_RESET_CAUSE: 0x0
TOTAL_NAKS indicates number of NAK control frames are sent to request

retransmission of missing data frames. Higher NAK indicates more retransmission, and thus lower throughput.
Channel resource group includes 1X, 2X, 4X, 8X, and 16X. Non-zero values in
higher channel resource group indicate number of data frames delivered at higher
data rate. Refer to Table 3, MCC Resource Groups, on page 5-52 for corresponding data rate.
RLP3_RESET_COUNT increments when RLP is reset. When there are lots of
lost data frames, and RLP is unable to recover gracefully, RLP must reset itself.
RLP reset will have negative impact on overall data throughput.
Qualcomm CAIT tool can also be used for displaying RLP stats from MS perspective.
5.3 Frame Eraser Rate (FER)

Poor RF results in high FER.
SMAP has capability to identify poor RF and FER troublespots. Target FER for
FCH should be less than 1%, and should be less than 5% for SCH. A location
with a FER reaching 5% or higher is of concern. A 5% or greater FER causes call
coverage and quality to suffer noticeably. Therefore, it is crucial to maintain under
the target FER and identify the high FER locations. A high FER location will cause
a high level of call drops, regardless of the variance in the call success rate from
time to time on the same route.
In addition, FER causes RLP to retransmit the missing frames. RLP allows two
NAK schemes, namely, 1/2/3, and 2/3/-. Motorola RLP implementation uses 2/3/NAK scheme. If missing frames are detected, RLP will send two NAK for the first
round to the transmitter. For each NAK received, the tranmitter retransmits a copy
of the missing frame. The retransmitted frames are not received within NAK timer,
the receiver will send three NAKs to the transmitter.
The maximum throughput or capacity can be approximated by 1/(1+2*FER),
ignoring the second round since the probability for the second round is very small.
49
2002 Motorola, Inc

As result, giving the miximum theoritical throughput of 141Kbps for TCP
applications, impact of FER is shown in the following table.
Table 2. FER Impact on Throughput

2/3/-
1/2/3
FER Impact
Peak
Throughput
(Kbps)
FER Impact
Peak
Throughput
(Kbps)
1%
98%
138.18
99%
139.59
2%
96%
135.36
98%
138.18
5%
91%
128.31
95%
136.8
FER
However, the reason choosing 2/3/- NAK scheme is probability of longer delay of
1/2/3 NAK scheme, and keep delay low is highly desirable for TCP applications.
The probability of successfully retransmitting after the first round is an order of
magnitude higher for 2/3/- NAK scheme than for the 1/2/3 NAK schemes. This
means that 1/2/3 NAK scheme has a substantial higher probability of delaying
RLP frames for an extra NAK timeout. This results in further throughput
degradation.
Mobile Call Status Display on SMAP shows FER.
If system experience poor RF or high FER, RF optimization is required. RF optimization is beyond the scope of this document.
5.4 TCP Window Size

TcpWindowSize determines the maximum TCP receive window size offered by
the system. The receive window specifies the number of bytes a sender may
transmit without receiving an acknowledgment. In general, larger receive windows
will improve performance over high-bandwidth (delay * bandwidth) networks. For
highest efficiency, the receive window should be an even multiple of the TCP Maximum Segment Size (MSS)
The procedure for changing the registry value is described in detail on the
Microsoft Product Support Services site in the Knowledge Database article
Q120642. Portions of this article related to changing the TcpWindowSize value
are shown below. For a more detailed description of this procedure, please refer
to the article Q120642 on the Microsoft support web site.
Selected excerpts from KB article Q120642 are as follows:

50
2002 Motorola, Inc

WARNING: Using the Registry Editor incorrectly can cause serious
problems that may require you to reinstall your operating system.
Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at
your own risk.
For information about how to edit the registry, view the Changing Keys and Values Help topic in the Registry Editor (Regedit.exe) or the Add and Delete Information in the Registry and Edit Registry Data Help topics in Regedt32.exe. Note
that you should back up the registry before you edit it. If you are running Windows
NT or Windows 2000, you should also update your Emergency Repair Disk
(ERD).
To change the TcpWindowSize parameter, use the following procedure:
1. Start Registry Editor (Regedt32.exe).
2. From the HKEY_LOCAL_MACHINE subtree, go to the following key:
\SYSTEM\CurrentControlSet\Services
3. Add a value to the key as described in the appropriate entry below by clicking
Add Value on the Edit menu, typing the value. Use the Data Type check box
to set the value type.
4. Click OK.
5. Quit Registry Editor.
6. Reboot the computer to make the change take effect.
All of the TCP/IP parameters are registry values that are located under one of two
different subkeys of the following menu
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services.
Tcpip\Parameters
Adapter Name\Parameters\Tcpip*
Adapter Name refers to the subkey for a network adapter that Transmission Control Protcol/Internet Protocol (TCP/IP) is bound to, such as Lance01. Values under
the latter key(s) are specific to each adapter. Parameters for which there may be
both a Dynamic Host Control Protocol (DHCP) and statically configured value
may or may not exist depending on whether the system/adapter is DHCP configured and/or static override values have been specified. A reboot of the system is
required for a change in any of these parameters to take effect.
Specific information about the TcpWindowSize parameter is shown below:
TcpWindowSize values:
Key: Tcpip\Parameters
Value Type: REG_DWORD - Number of bytes
Valid Range: 0 - 0xFFFF
51
2002 Motorola, Inc

Default: The smaller of 0xFFFF
OR
(The larger of four times the maximum TCP data size on the network
OR
8192 rounded up to an even multiple of the network TCP data size.)
The default is 8760 for Ethernet.
The information in the article Q120642 applies to:
Microsoft Windows 2000 , Professional

Microsoft Windows 2000 , Server
Microsoft Windows 2000 , Advanced Server
Microsoft Windows 2000 , Datacenter Server
Microsoft Windows NT Workstation versions 3.5 , 3.51 , 4.0
Microsoft Windows NT Server versions 3.5 , 3.51 , 4.0
For Microsoft Window XP version of this article, refer to Q314053.

Windows TCP/IP Registry Entries (Q158474) applies to:
Microsoft Windows 95
Microsoft Windows 98
Microsoft Windows 98 Second Edition
Microsoft Windows Millennium Edition
Motorola recommands TCP Window size of 24K - 28K to achieve optimal

throughput. However, feature FR 6027 (CAR 190) eliminates the need.
5.5 SCH Allocation

Each MCC1X card has 128 channel element resources. One resource is required
for FCH or DCCH. SCH requires more than one resource to achieve higher data
rate.
Table 3. MCC Resource Groups

RC3
Forward
RC4
Reverse
Forward
1X
9.6 kbps
19.2 kbps
19.2 kbps
2X
19.2 kbps
38.4 kbps
38.4 kbps
4X
38.4 kbps
76.8 kbps
76.8 kbps
8X
76.8 kbps
153.6 kbps
153.6 kbps
16X
153.6 kbps
Reverse

52
2002 Motorola, Inc

Resource group can be allocated using edit mcc-<bts#>-<mcc#> resgrp
Running DISPLAY BTS-13 RESGRP shows the resource allocation on BTS-13:
MCC/MAWI
(bts#-mcc#/mawi#)
|
|
Number of Resource Groups with

|
Forward Supplemental Channels of:
|
Number of Resource Groups with

Reverse Supplemental Channels
of:
|1
|2
|4
|8
|16
|1
|2
|4
|8
------------------------------|-------|-------|-------|-------|-------|-------|-------|-------|------------MCC-13-31
CSM 1
CSM 2
2
1
1
1
1
1
1
1
1
1
1
1
0
0
1
1
0
0
It is recommended that at least one resource group for each data rate.
RC3: fwd1resgrp, fwd2resgrp, fwd4resgrp, frd8resgrp, fwd16resgrp
rev1resgrp, rev2resgrp, rev4resgrp, rev8resgrp
RC4: fwd1resgrp, fwd2resgrp, fwd4resgrp, frd8resgrp
Supplemental Channel (SCH) is required in CDMA2000 to achieve high data rate.
On demand Supplemental Channel Management is the concept to allocate supplemental resources only when needed, and only for a short time so as to share
the resources among multiple users. Data is initially sent on fundamental channel
(FCH). When there is enough data to be sent, SCH will be allocated and data will
be transferred on SCH as well as FCH/DCCH.
The following PM reports also show SCH utilization.
BTS per Data Rate SCH Allocation Report
BTS Carrier-Sector SCH Allocation Report
Packet Pipe SCH Allocation Report
Packet Pipe SCH Utilization Report
SCH Group Allocation Report
SCH Group Utilization Report
BTS SCH Allocation Failures Report
Known Problem:
Multiple simultaneous high speed packet data calls with limited Backhaul cause
poor or no SCH allocation and lead to throughput drop. There are relatively large
gaps or skips where no data is sent. The scheduling gaps force TCP into retransmissions which lowers the throughput.
There is a feature enhancement (FR6027) to modify SCH scheduling Algorithm to
allow a greater range of tuning for increasing overall data throughput.

53
2002 Motorola, Inc

5.6 Low Throughput Scenarios
5.6.1 PPP Error
PPP errors are observed on Dial-Up Network (DUN) Monitor
Check RLP stats from CAIT and/or SMAP
Are there any RLP resets or NAK Aborts?
If these RLP conditions exist check RF environment
Make sure FER does not exceed 1% for FCH and 5% for SCH on Forward
and Reverse links
5.6.2 High FER

There are no PPP errors on DUN Monitor
Make sure FER does not exceed 1% for FCH and 5% for SCH on Forward
and Reverse links
High FER can increase latency which may slow file transfers
5.6.3 Resource Group

FER is not excessive
Check configuration to make sure all resource groups are available
(16X,8X,4X,2X,1X)
Check pegs from pmC_77_hr. Configuration of Resource Groups per
MCC1X is obtainable from pmC_83_hr.
Other reasons for low throughput would be SCH allocation errors, from other pegs described in detail, the overall high-level summary being given in
the BTS SCH Allocation Failures report.
Make sure TCP Window size is 28000 (decimal), can be verified with Netmon on client or sniffer at FTP server
5.6.4 Ethernet Link

All resource groups are available
TCP window size is set properly on client
Check for CRC errors on Ethernet links due to Duplex mismatch
Force duplex mode on devices to remedy problem, DO NOT allow devices
to Auto-negotiate duplex
5.6.5 Microsoft TCP

54
2002 Motorola, Inc

All resource groups are available
TCP window size is set properly on client
There are no Ethernet CRC errors on devices
Make sure Application server (typically FTP) is not causing TCP Retransmissions
Windows2000 FTP servers with certain network configuration have a known
problem that causes TCP retransmission at beginning of file transfer, use
Unix or Linux FTP server.

55
2002 Motorola, Inc
A1. CDL Examples

A1.1 CDL example for a good data call
MSI-8049439730 02-03-07 14:52:18 omc MM-4 L000000.00000 978923/080572
CDL:1
"Call Detail Log"
CDL_SEQ_NUM=0x4df3
INIT_MAHO_CAND3_PHASE=0x0000
CALL_REF_NUM=0x031c
INIT_MAHO_CAND3_BM_TYPE=0
CBSC=614
LAST_MAHO_TIME=0x654d
MMADDR=0xc4
LAST_MAHO_CAUSE=14
XC=1
LAST_MAHO_CAND_COUNT=0
CPP=3
LAST_MAHO_ACT1_CBSC=614
MID=8049439730
LAST_MAHO_ACT1_MMADDR=0xc4
ESN=0x9f85f060
LAST_MAHO_ACT1_BTS=488
SCM=0xca006300
LAST_MAHO_ACT1_SECTOR=3
MOBILE_PROTOCOL_REV=6
LAST_MAHO_ACT1_STR=0x12
DIALED_DIGITS=#777
LAST_MAHO_ACT1_PHASE=0x7b03
NUMBER_TYPE=0x00
LAST_MAHO_ACT1_BM_TYPE=1
NUMBER_PLAN=0x00
ASCII_DIGITS=
ACCESS_TIME=14:50:24
ACCESS_PN_OFFSET=37
ACCESS_STR=0x0210
LAST_MAHO_ACT2_STR=0x2d
ACCESS_CHANNEL=375
LAST_MAHO_ACT2_PHASE=0x0000
ACCESS_BTS=401
ACCESS_SECTOR=2
ENTRY_TYPE=0
LAST_MAHO_ACT3_MMADDR=0x00
SERVICE_OPTION=0x0021
NEGOTIATED_SO=0x0021
LAST_MM_SETUP_EVENT=18
CIC_SPAN=0
CIC_SLOT=0
XCDR=0xffff
INIT_RF_CONN_BTS=401
INIT_RF_CONN_SECTOR=2
INIT_RF_CONN_MCC=7
INIT_RF_CONN_ELEMENT=37
INIT_RF_CONN_CHANNEL=375
CFC=111
RELEASE_TIME=14:52:16
XC_RELEASE_TIME=0x6708
INIT_MM_REL_EVENT=3
INIT_DISC_CAUSE_TYPE=1
INIT_DISC_CAUSE=0x1802
HHO_TGT_CBSC=0
HHO_TGT_MMADDR=0x00
HHO_TGT_CELLID=0xffff
HHO_TGT_CELLID_FORMAT=0xff
HHO_TGT_MCC1=0xff
HHO_TGT_MCC2=0xff
HHO_TGT_MCC3=0xff
HHO_TGT_MNC1=0xff
HHO_TGT_MNC2=0xff
HHO_TGT_MNC3=0xff
LAST_MAHO_CAND1_CBSC=0
HHO_TGT_LAC=0x0000
LAST_MAHO_CAND1_MMADDR=0x00
HHO_TGT_MARKET_ID=0xffff
LAST_MAHO_CAND1_BTS=0
HHO_TGT_SWITCH_NUMBER=0xff
LAST_MAHO_CAND1_SECTOR=0

56
2002 Motorola, Inc

HHO_TGT_DISCR_FMT_CODE=0xffff
HHO_TGT_DISCR_VALUE=0xff
ONE_PILOT_COUNT=1
TWO_PILOTS_COUNT=3
THREE_PILOTS_COUNT=13
FOUR_PILOTS_COUNT=6
FIVE_PILOTS_COUNT=0
SIX_PILOTS_COUNT=0
LOC_S_ADD_COUNT=12
LOC_SR_ADD_COUNT=3
LOC_S_DROP_COUNT=12
LOC_SR_DROP_COUNT=4
EXT_S_ADD_COUNT=0
EXT_SR_ADD_COUNT=0
EXT_S_DROP_COUNT=0
EXT_SR_DROP_COUNT=0
NUM_SR_SHUFFLE=0
NUM_BTS_SHUFFLE=8
NUM_S_SHUFFLE=0
RELEASE_L_CE=1
RELEASE_L_WC=1
RELEASE_E_CE=0
RELEASE_E_WC=0
NUM_SHO_FAILURES=0
FIRST_SHO_FAIL_TIME=0:00:00
LAST_SHO_FAIL_CAUSE=0x0000
LAST_SHO_FAIL_TIME=0:00:00
LAST_HO_BLOCK_CAUSE=14
LAST_HO_BLOCK_TIME=14:51:48
LAST_HO_BLOCK_PN=92
ICS_BEGIN_TGT_CBSC=618
ICS_BEGIN_TGT_MMADDR=0x00
ICS_BEGIN_TGT_BTS=0
ICS_BEGIN_TGT_SECTOR=0
ICS_BEGIN_SRC1_BTS=0
ICS_BEGIN_SRC1_SECTOR=0
ICS_BEGIN_TIME=0:00:00
ICS_BEGIN_TGT_COUNT=0
ICS_BEGIN_SRC_COUNT=0
ICS_END_TGT_CBSC=615
ICS_END_TGT_MMADDR=0x00
ICS_END_TGT_BTS=0
ICS_END_TGT_SECTOR=0
ICS_END_SRC1_BTS=0
ICS_END_SRC1_SECTOR=0
ICS_END_SRC2_BTS=0
ICS_END_TIME=0:00:00
ICS_END_TGT_COUNT=0
ICS_END_SRC_COUNT=0
ICS_COUNT=0
ICS_CBSCS=0
ICS_FP_TGT_CBSC=0
ICS_FP_TGT_MMADDR=0x00
ICS_FP_TGT_BTS=0
ICS_FP_TGT_SECTOR=0
ICS_FP_SRC1_BTS=0
LAST_MAHO_CAND1_STR=0x00
LAST_MAHO_CAND1_PHASE=0x0000
LAST_MAHO_CAND1_BM_TYPE=0
LAST_PSMM_TIME=0x654d
LAST_PSMM_CAUSE=0
LAST_PSMM_CAND_COUNT=0
LAST_PSMM_ACT1_CBSC=614
LAST_PSMM_ACT1_MMADDR=0xc4
LAST_PSMM_ACT1_BTS=488
LAST_PSMM_ACT1_SECTOR=3
LAST_PSMM_ACT1_STR=0x12
LAST_PSMM_ACT1_PHASE=0x7b03
LAST_PSMM_ACT1_BM_TYPE=1
LAST_PSMM_ACT2_MMADDR=0x00
LAST_PSMM_ACT2_PHASE=0x0000

57
2002 Motorola, Inc

ICS_FP_SRC1_SECTOR=0
ICS_FP_SRC2_BTS=0
ICS_FP_TIME=0:00:00
ICS_FP_TGT_COUNT=0
ICS_FP_SRC_COUNT=0
ICS_FP_ATT_COUNT=0
LAST_RF_CONN3_CBSC=614
LAST_RF_CONN3_MMADDR=0xc4
LAST_RF_CONN3_BTS=398
LAST_RF_CONN3_1SECTOR=1
LAST_RF_CONN3_MCC=7
LAST_RF_CONN3_ELEMENT=0
LAST_RF_CONN3_ELEMENT_TYPE=1
LAST_RF_CONN3_IPADDR=
LAST_RF_CONN3_LOSIG_IPADDR=
LAST_RF_CONN3_LOSIG_IPPORT=0
LAST_RF_CONN3_LOCE_IPADDR=11.202.0.145
LAST_RF_CONN3_LOCE_IPPORT=60018
LAST_RF_CONN3_RESIG_IPADDR=
LAST_RF_CONN3_RESIG_IPPORT=0
LAST_RF_CONN3_RECE_IPADDR=
LAST_RF_CONN3_RECE_IPPORT=0
MCC_RELEASE3_TIME=0x0000
LAST_RF_HIGA3_INTERVALS=0
LAST_RF_HIGA3_BEGIN=0x0000
LAST_RF_HIGA3_END=0x0000
LAST_RF_HIGA3_COUNT=0
LAST_RF_HIGA3_TEMP=0x0000
LAST_RF_SETP3_INTERVALS=0
LAST_RF_SETP3_BEGIN=0x0000
LAST_RF_SETP3_END=0x0000
LAST_RF_SETP3_COUNT=0
LAST_RF_SETP3_TEMP=0x0000
LAST_RF_CONN2_MCC=7
LAST_PSMM_CAND1_CBSC=0
LAST_PSMM_CAND1_MMADDR=0x00
LAST_PSMM_CAND1_BTS=0
LAST_PSMM_CAND1_SECTOR=0
LAST_PSMM_CAND1_STR=0x00
LAST_PSMM_CAND1_PHASE=0x0000
LAST_PSMM_CAND1_BM_TYPE=0
FIRST_SHO_TIME=14:50:25
FIRST_SHO_CAUSE=12
FIRST_SHO_POST_AGST=0x11
FIRST_SHO_RESULT=1
LAST_SHO_TIME=14:52:06
LAST_SHO_CAUSE=9
LAST_SHO_POST_AGST=0x12
LAST_SHO_RESULT=1
SHUFFLE_TYPE=0
LAST_SHO_NUM_SECT_DET=1
LAST_SHO_NUM_SECT_EXEC=1
LAST_SHO_CBSC=614
LAST_SHO_MMADDR=0xc4
LAST_SHO_BTS=401
LAST_SHO_SECTOR=2
LAST_SHO_MCC=7
LAST_SHO_ELEMENT=8
SETUP_EVENTS1=0x0c6f02f4
SETUP_EVENTS2=0x0007
FWD_QUALITY=28
LAST_FWD_INCR=0x66e1
MEAS_COUNT=0
RVS_QUALITY=0
LAST_RVS_INCR=0x6b80
RVS_ERASE_COUNT=6
RF_FADE_COUNT=0
VOCODER_BYPASS=0x00
PKT_DATA_TYPE=0x01
IWU_ID=0
SERV_CONF_TOGGLE_TIME=0:00:00
SERV_CONF_TOGGLE_TYPE=0xff
SERV_CONF_TOGGLE_PARTY=0xff
SERV_CONF_TOGGLE_STATUS=0xff
FINAL_SERVICE_OPTION=0xffff
CHANNEL_COST=-22.12

58
2002 Motorola, Inc

LAST_RF_CONN1_MCC=7
FIRST_MAHO_TIME=0x513e
FIRST_MAHO_CAUSE=18
FIRST_MAHO_ACT_STR=0x17
FIRST_MAHO_CAND_COUNT=1
FIRST_MAHO_CAND1_PN=96
FIRST_MAHO_CAND1_STR=0x18
INIT_MAHO_TIME=0x513e
INIT_MAHO_CAUSE=18
INIT_MAHO_ACT_STR=0x17
INIT_MAHO_CAND_COUNT=1
INIT_RF_CONN_PSICE_IPADDR=11.202.0.145
LOAD_BTS=401
LOAD_SECTOR=2
LOAD_CHANNEL=375
LOAD_TIME=0x3c87c4a9
LPA_FPROTECT=0
EXCITER_POWER=-9.60
FWD_EC_IOR=0.29
FWD_LIMIT_ORIG=0.05
FWD_LIMIT_TERM=0.05
TRANSMITTER_POWER=40.49
LPA_POWER=43.89
LPA_SELFCAL_PROTECT=0
RVS_RISE=0.97
RVS_LIMIT_ORIG=13.00
RVS_LIMIT_TERM=13.00
FWD_HI_FER=0.00
RVS_HI_FER=4.00
FWD_ACT_CHANNELS=25
RVS_ACT_CHANNELS=25
HIGA_INTERVALS=0
HIGA_BEGIN=0x0000
HIGA_END=0x0000
HIGA_COUNT=0
HIGA_TEMP=0x0000
COMPOSITE_FER=0
EIB_COUNT=0
SETP_INTERVALS=0
SETP_BEGIN=0x0000
SETP_END=0x0000
SETP_COUNT=0
SETP_TEMP=0x0000
SCM_ENTRY_LIST1=0x0201ea01
SCM_ENTRY_LIST2=0x0301f006
QPCH_SUPPORTED=1
OTD_SUPPORTED=0
STS_SUPPORTED=0
FWD_FCH_RC_SUPPORTED=0x01f0
REV_FCH_RC_SUPPORTED=0x3c
FWD_DCCH_RC_SUPPORTED=0x0000
REV_DCCH_RC_SUPPORTED=0x00
NEGFCH_TYPE=1
NEGRCH_TYPE=1
NEGFBASE_RC=3
NEGRBASE_RC=3
NEGFSUPP_RC=4
NEGRSUPP_RC=0
SRV_RQ_SENT=0
SRV_RQ_RCVD=2
SRV_RSPS_SENT=1
SRV_RSPS_RCVD=0
CBSC_PREF_SO_OVERRIDE=0
UPGRD_SO_CHANGE=0
DWNGRD_SO_CHANGE=0
DWNGRD_NO_SO_CHANGE=0
QUICK_SN=0
INIT_RF_CONN_ELEMENT_TYPE=1
INIT_RF_CONN_ELEMENT_IPADDR=

59
2002 Motorola, Inc

INIT_MAHO_CAND1_CBSC=614
INIT_MAHO_CAND1_MMADDR=0xc4
INIT_MAHO_CAND1_BTS=401
INIT_MAHO_CAND1_SECTOR=3
INIT_MAHO_CAND1_STR=0x18
INIT_MAHO_CAND2_MMADDR=0x00
INIT_RF_CONN_PSICE_PORT=60047
LAST_SHO_ELEMENT_IPADDR=
PSI_SDU_ID=0x0081
PDSN_IPADDR=10.28.206.145
PCF_IPADDR=11.202.4.26
PCFRA_IPADDR=11.202.4.26
BYTES_FWD=57
BYTES_RVS=3
TIME_FWD=4
TIME_RVS=0
DATA_ATTEMPTS=196
DATA_AT_RQSTD_RATE=5
DATA_BELOW_RQSTD_RATE=9
HO_SETUP_EVENTS1=0x02
XCDR_CAGE_NUMBER=0xff
XCDR_SLOT_NUMBER=0xff
PSI_SDU_CAGE_NUMBER=0x04
PSI_SDU_SLOT_NUMBER=0x0d
A1.2 CDL example for a failed data call

MSI-8045199729 02-03-07 14:44:38 omc MM-4 L000000.00000 975406/067550
CDL:1
"Call Detail Log"
CDL_SEQ_NUM=0x4036
CALL_REF_NUM=0x125e
CBSC=614
LAST_MAHO_TIME=0x0bad
MMADDR=0xc4
LAST_MAHO_CAUSE=17
XC=1
LAST_MAHO_CAND_COUNT=1
CPP=16
MID=8045199729
ESN=0xb31d3004
SCM=0xca006200
MOBILE_PROTOCOL_REV=6
DIALED_DIGITS=#777
NUMBER_TYPE=0x00
NUMBER_PLAN=0x00
ASCII_DIGITS=
ACCESS_TIME=14:44:24
ACCESS_PN_OFFSET=42
ACCESS_STR=0x03c7
ACCESS_CHANNEL=375
LAST_MAHO_ACT2_PHASE=0x3d05
ACCESS_BTS=488
ACCESS_SECTOR=3
ENTRY_TYPE=0
SERVICE_OPTION=0x0021
NEGOTIATED_SO=0xffff
LAST_MM_SETUP_EVENT=28
CIC_SPAN=0
CIC_SLOT=0
XCDR=0xffff
INIT_RF_CONN_BTS=488
INIT_RF_CONN_SECTOR=3
INIT_RF_CONN_MCC=7
INIT_RF_CONN_ELEMENT=32
INIT_RF_CONN_CHANNEL=375
CFC=15
RELEASE_TIME=14:44:32

60
2002 Motorola, Inc

XC_RELEASE_TIME=0x0000
INIT_MM_REL_EVENT=7
INIT_DISC_CAUSE_TYPE=1
INIT_DISC_CAUSE=0x1124
HHO_TGT_CBSC=0
HHO_TGT_MMADDR=0x00
HHO_TGT_CELLID=0xffff
HHO_TGT_CELLID_FORMAT=0xff
HHO_TGT_MCC1=0xff
HHO_TGT_MCC2=0xff
HHO_TGT_MCC3=0xff
HHO_TGT_MNC1=0xff
HHO_TGT_MNC2=0xff
HHO_TGT_MNC3=0xff
HHO_TGT_LAC=0x0000
HHO_TGT_MARKET_ID=0xffff
HHO_TGT_SWITCH_NUMBER=0xff
HHO_TGT_DISCR_FMT_CODE=0xffff
HHO_TGT_DISCR_VALUE=0xff
ONE_PILOT_COUNT=0
TWO_PILOTS_COUNT=1
THREE_PILOTS_COUNT=1
FOUR_PILOTS_COUNT=0
FIVE_PILOTS_COUNT=0
SIX_PILOTS_COUNT=0
LOC_S_ADD_COUNT=2
LOC_SR_ADD_COUNT=0
LOC_S_DROP_COUNT=0
LOC_SR_DROP_COUNT=0
EXT_S_ADD_COUNT=0
EXT_SR_ADD_COUNT=0
EXT_S_DROP_COUNT=0
EXT_SR_DROP_COUNT=0
NUM_SR_SHUFFLE=0
NUM_BTS_SHUFFLE=0
NUM_S_SHUFFLE=0
RELEASE_L_CE=0
RELEASE_L_WC=0
RELEASE_E_CE=0
RELEASE_E_WC=0
NUM_SHO_FAILURES=0
FIRST_SHO_FAIL_TIME=0:00:00
LAST_SHO_FAIL_CAUSE=0x0000
LAST_SHO_FAIL_TIME=0:00:00
LAST_HO_BLOCK_CAUSE=0
LAST_HO_BLOCK_TIME=0:00:00
LAST_HO_BLOCK_PN=-1
ICS_BEGIN_TGT_CBSC=618
ICS_BEGIN_TGT_MMADDR=0x00
ICS_BEGIN_TGT_BTS=0
ICS_BEGIN_TGT_SECTOR=0
ICS_BEGIN_TIME=0:00:00
ICS_BEGIN_TGT_COUNT=0
ICS_BEGIN_SRC_COUNT=0
ICS_END_TGT_CBSC=618
LAST_MAHO_CAND1_MMADDR=0xc4
LAST_MAHO_CAND1_PHASE=0x16fe
LAST_PSMM_TIME=0x0bad
LAST_PSMM_CAUSE=0
LAST_PSMM_CAND_COUNT=0
LAST_PSMM_ACT1_PHASE=0x3d05
LAST_PSMM_ACT2_PHASE=0x16fe

61
2002 Motorola, Inc

ICS_END_TGT_MMADDR=0x00
ICS_END_TGT_BTS=0
ICS_END_TGT_SECTOR=0
ICS_END_SRC1_BTS=0
ICS_END_SRC2_BTS=0
ICS_END_TIME=0:00:00
ICS_END_TGT_COUNT=0
ICS_END_SRC_COUNT=0
ICS_COUNT=0
ICS_CBSCS=0
ICS_FP_TGT_CBSC=0
ICS_FP_TGT_MMADDR=0x00
ICS_FP_TGT_BTS=0
ICS_FP_TGT_SECTOR=0
ICS_FP_SRC1_BTS=0
ICS_FP_SRC2_BTS=0
ICS_FP_TIME=0:00:00
ICS_FP_TGT_COUNT=0
ICS_FP_SRC_COUNT=0
ICS_FP_ATT_COUNT=0
LAST_RF_CONN3_MCC=7
FIRST_SHO_TIME=14:44:25
FIRST_SHO_CAUSE=8
FIRST_SHO_POST_AGST=0x10
FIRST_SHO_RESULT=1
LAST_SHO_TIME=14:44:29
LAST_SHO_CAUSE=8
LAST_SHO_POST_AGST=0x10
LAST_SHO_RESULT=1
SHUFFLE_TYPE=0
LAST_SHO_NUM_SECT_DET=1
LAST_SHO_NUM_SECT_EXEC=1
LAST_SHO_CBSC=614
LAST_SHO_MMADDR=0xc4
LAST_SHO_BTS=401
LAST_SHO_SECTOR=2
LAST_SHO_MCC=7
LAST_SHO_ELEMENT=1
SETUP_EVENTS1=0x040302f4

62
2002 Motorola, Inc

LAST_RF_CONN2_MCC=7
LAST_RF_CONN1_MCC=7
SETUP_EVENTS2=0x0007
FWD_QUALITY=2
LAST_FWD_INCR=0x0c08
MEAS_COUNT=0
RVS_QUALITY=0
LAST_RVS_INCR=0x0000
RVS_ERASE_COUNT=0
RF_FADE_COUNT=0
VOCODER_BYPASS=0x00
PKT_DATA_TYPE=0x00
IWU_ID=0
SERV_CONF_TOGGLE_TIME=0:00:00
SERV_CONF_TOGGLE_TYPE=0xff
SERV_CONF_TOGGLE_PARTY=0xff
SERV_CONF_TOGGLE_STATUS=0xff
FINAL_SERVICE_OPTION=0xffff
CHANNEL_COST=0.00
LOAD_BTS=401
LOAD_SECTOR=2
LOAD_CHANNEL=375
LOAD_TIME=0x3c87c2c9
LPA_FPROTECT=0
EXCITER_POWER=-10.00
FWD_EC_IOR=0.32
FWD_LIMIT_ORIG=0.05
FWD_LIMIT_TERM=0.05
TRANSMITTER_POWER=40.09
LPA_POWER=43.49
LPA_SELFCAL_PROTECT=0
RVS_RISE=0.79
RVS_LIMIT_ORIG=13.00
RVS_LIMIT_TERM=13.00
FWD_HI_FER=5.26
RVS_HI_FER=0.00
FWD_ACT_CHANNELS=19
RVS_ACT_CHANNELS=19
HIGA_INTERVALS=0
HIGA_BEGIN=0x0000
HIGA_END=0x0000
HIGA_COUNT=0
HIGA_TEMP=0x0000
COMPOSITE_FER=0
EIB_COUNT=0
SETP_INTERVALS=0
SETP_BEGIN=0x0000
SETP_END=0x0000
SETP_COUNT=0
SETP_TEMP=0x0000
SCM_ENTRY_LIST1=0x0201aa01
SCM_ENTRY_LIST2=0x0301c006
QPCH_SUPPORTED=1
OTD_SUPPORTED=0
STS_SUPPORTED=0
FWD_FCH_RC_SUPPORTED=0x01f0
REV_FCH_RC_SUPPORTED=0x3c
FWD_DCCH_RC_SUPPORTED=0x0000
REV_DCCH_RC_SUPPORTED=0x00
NEGFCH_TYPE=0
NEGRCH_TYPE=0

63
2002 Motorola, Inc

FIRST_MAHO_TIME=0x0af5
FIRST_MAHO_CAUSE=18
FIRST_MAHO_ACT_STR=0x15
FIRST_MAHO_CAND_COUNT=1
INIT_MAHO_TIME=0x0af5
INIT_MAHO_CAUSE=18
INIT_MAHO_ACT_STR=0x15
INIT_MAHO_CAND_COUNT=1
INIT_RF_CONN_PSICE_IPADDR=11.202.0.147
INIT_MAHO_CAND1_MMADDR=0xc4
INIT_MAHO_CAND1_PHASE=0x3d05
NEGFBASE_RC=0
NEGRBASE_RC=0
NEGFSUPP_RC=0
NEGRSUPP_RC=0
SRV_RQ_SENT=0
SRV_RQ_RCVD=1
SRV_RSPS_SENT=0
SRV_RSPS_RCVD=0
CBSC_PREF_SO_OVERRIDE=0
UPGRD_SO_CHANGE=0
DWNGRD_SO_CHANGE=0
DWNGRD_NO_SO_CHANGE=0
QUICK_SN=0
INIT_RF_CONN_ELEMENT_TYPE=1
INIT_RF_CONN_ELEMENT_IPADDR=
INIT_RF_CONN_PSICE_PORT=60006
LAST_SHO_ELEMENT_IPADDR=
PSI_SDU_ID=0x0071
PDSN_IPADDR=
PCF_IPADDR=11.202.4.26
PCFRA_IPADDR=11.202.4.26
BYTES_FWD=0
BYTES_RVS=0
TIME_FWD=0
TIME_RVS=0
DATA_ATTEMPTS=0
DATA_AT_RQSTD_RATE=0
DATA_BELOW_RQSTD_RATE=0
XCDR_CAGE_NUMBER=0xff
XCDR_SLOT_NUMBER=0xff
PSI_SDU_CAGE_NUMBER=0x04
PSI_SDU_SLOT_NUMBER=0x0d

64
2002 Motorola, Inc
A2. Debug Log Notes

Logs required for effective debugging of throughput issues in 16.0 system:
1. Netmon log from PC client (PC connected to mobile phone)

Make sure capture buffer is set large enough for file transfer. Default is 1MB, 2MB is recommended for a 1MB file transfer. Do not set capture buffer too large, this utilizes PCs RAM
resources.
This log allows engineers to view data in and out of the PC client.
Make sure log only contains data for one COMPLETE file transfer
Do not try to use Ethereal for this function on Windows2000, it will only capture data in one
direction or stop data from being transferred over PPP link.
2. Sniffer log from RAN (sniffer connected to CAT port monitor including PDSN, PCF, Selector, etc.)
Make sure capture buffer is set large enough for file transfer. Default is 8MB, 16MB is recommended for a 1MB file transfer. Do not set capture buffer too large, this utilizes PCs RAM
resources.
Make sure log only contains data for one COMPLETE file transfer.
This log is useful to trace data through various RAN components.
3. Sniffer log from FTP server (sniffer connected to FTP server)

This log is useful to see when FTP packets are sent and received by the FTP Server.
4. Capture of RLP statistics and IS2000 Mux Statistics window from CAIT
This log can be captured by using Print Screen or ALT-Print Screen and then pasting
into editor like WordPad or Word and saving in .rtf format.
This log is useful to monitor RF/RLP conditions.
5. Dial-Up Networking (DUN) Monitor from PC client.

Make sure log only contains data for one COMPLETE file transfer. The statistics cannot be
reset. They are reset when a new PPP session is started. In order to record errors for multiple
transfers in a single session the user must keep a record of this window for each file transfer.
This log is useful to monitor PPP errors.

Additional Notes:
In order to have good logs you must reset/clear logs after each file transfer. If you are making new calls between file transfers and do not wish the call to enter dormant mode will you
are resetting logs set the CBSC inactivity timer to a large value such as 250 seconds so you
have enough time.
Sanity check logs before you send them to other engineers to review. Make sure there is
valid data present for the type of log collected.
Make sure to use a non-repeating ASCII file with line numbers. Such a file can be found at /
home/sharpe/debug/humpty.
Provide the IP addresses of mobile client, FTP server, SEL, PCF, PDSN, etc.

65
2002 Motorola, Inc
A3. Packet Data FAQ

A3.1 PCF Buffer Size
(1) Reserved buffer space
1.1)Reserved buffer space of current PCF has 420 blocks. What is a justification of 420 blocks?
Response:
For each call we reserve 3 blocks. This gives a total of 11kbytes. However, we
must consider fragmentation of buffers and overhead of indexing information to
ensure that each session has at least 5k of buffer space for actual data. We
reserve the buffers for the number of active calls + 10%. The 10% is to provide
buffer space for dormant sessions that are in process of being reactivated. Therefore, assuming 128 max active calls, number of reserved buffers is (128 + 10%) *
3 = 420
1.2)What is a justification of your design, i.e. minimum guarantee buffer size per call= 11 kilobytes (= 420
blocks x 3200 bytes / 140 users)?
Response:
To ensure each call can buffer 5K of real data. Allow additional space for fragmentation and overhead of indexing information.
1.3) If a variable parameter "MaxActiveCall (default = 128)" is changed, how will the minimum guarantee
buffer size per call? Describe the relationship with "MaxActiveCall".
Response:
The minimum guarantee buffer size per call will not change. However the number
of reserved buffers will change.
1.4) If, likely with above, "ReactCapaRate (default=5)" is changed, how will the minimum guarantee buffer
size per call? And please describe the relationship with "ReactCapaRate" as well.
Response:
The minimum guarantee buffer size per call will not change.
(2) Maximum buffer size per user
2.1) Please describe how to calculate the maximum buffer size per call (200 bytes).
Response:
For TCP based applications, maximum downlink data buffer size at the PCF will
be determined based on mobile receive TCP window buffer size and number of
simultaneous TCP sessions which are actively transferring bulk data or files
towards the mobile. The max buffer size should be more than the size of typical
TCP window.
2.2) Please describe the reason why Motorola designed the maximum buffer size of 200 kilo bytes per call.
Why is it 200Kilo-bytes?
66
2002 Motorola, Inc

Response:
PCF needs to provide enough buffer size to accommodate multiple TCP sessions,
bigger window size etc. so that some enhanced end-users such as magazine editors/mobile application developers will see reasonable buffer allowance (to not fail
performance benchmarking test etc.) 200KB (which provides 6 concurrent 32KB
window size TCP sessions for example) should give enough buffer size for such
special use, and was determined as a reasonable upper limit per user. We implemented per user limit so that one particular user will not impact rest of normal
users.
(3)Buffer allocation
3.1) In data buffering by PCF, what buffer is used at first?
Response:
For each session, the first 3 buffers are allocated from the reserved buffer space.
Then the Total blocks are used.
3.1.1) In buffering the data that first reaches PCF after the session is established,
RESERVED (420 blocks) or "Total (3700 blocks)" is used?
which of
Response:
For each session, the first 3 buffers are allocated from the reserved buffer space.
Then the Total blocks are used.
3.1.2) In buffering the data of 4th block or later, which of RESERVED or Total is used? If it depends on
any condition, please describe it with the operation.
Response:
The Total is always used for 4th block or later.
3.1.3) Depending on allocation algorithm in 3.1.1) and 3.1.2), free buffer may take "0" even if the number
of sessions is MaxActiveCall or less. If, in this case, a new call is established, what buffer is used (or overwritten)? Please describe then the operational specification of PCF.
Response:
For each session the first 3 buffers are allocated from the reserved buffer space.
The reason is that they are reserved is to make sure they are always available for
any session.
3.2) If data against a dormant call is received from PSDN, what sequence is used for paging?
(1)Describe the sequence between PCF - SEL - CPP - MM.
Response:
When the PCF receives data from the PDSN for a dormant call, it issues a SCAP A9 BS-Service-Request to the MM to page the mobile.
The MM will send A1: BS-Service-Request to the MSC.

If the MSC can process the request, it will respond to MM with A1: BS-Service Response, with
positive cause value. (MSC could return MS busy or other cause value depending on MS
state/feature interaction.)
67
2002 Motorola, Inc

MM will then forward back BS-Service-Response to the PCF using SCAP A9 BS-ServiceResponse. The PCF then waits for A9 setup to complete.
In the mean time, if page can be performed, the MSC will proceed to normal MS paging procedure. (Send out A1: Paging Request to every CBSC in a specified paging area.)
After MS responds to the page, MM will start call radio resource assignment procedure, contact BTS and CPP to bring the mobile to traffic channel. MM also contacts one of local PSIPCFs to locate the anchor PCF with the dormant session/buffered data.
MS is assigned a Traffic channel, and SEL-BTS-MS path is setup.

MM will send SCAP PCF Assignment message to CPP after PSI-PCF/PCF-RA responds to
the anchor PCF location. The CPP directs PSI-SEL to start A9 setup procedure with the
anchor PCF. PSI-SEL sends A9-Setup-A8 to the PCF. PCF responds to A9-Connect-A8.
PDSN-PCF-SEL-BTS-MS path setup is complete at this point.
The buffered data at the PCF will be sent to the SEL, and the SEL will send the data to MS.
PCF/SEL will then continue processing bearer packets as usual.
(2) What is the maximum retry count if MS is not acknowledged for paging? Is this retry count changeable? If so, please describe name of parameter.
Response:
A database parameter, XC PCFPARMS PagingMaxRetries controls number of
retries in the case of no MS page response. The range of this parameter is 0-25,
and the default value is 10. Together with other tiemr and backoff parameters
(PCFPARMS TPagingResponse and TPagingIncrement) it controls paging retry
behavior at PCF.
A3.2 PCF Operation on A10/A11 Failure

The followings are questions regarding the PSIPCF operation when any failure occurred in the A10/A11
interface that is used between the PSI-pcf and PDSN.
Behavior of Active call
1. Please explain the operation of PDSN Reselect function. How is the PDSN to be reselected determined?
Response:
There are two scenarios when A10/A11 failure may occur and selection of another PDSN will be performed. These are as follows:
1) Individual Call Fails During Registration Request to a PDSN:
During changes in state for a call between active/dormant and release states or during session
reregistration, the PCF sends a registration request to the PDSN. If there is no response to the
Registration Request, or a Registration Reply is received with Reply Code of 0x81 (Registration
Denied Administratively Prohibited) or 0x82 (Registration Denied Insufficient Resources) then
another PDSN may be selected. Whether a new PDSN is in fact selected depends on both the
state transition being performed and also the value of the PDSNMaxReselect parameter. More
details of the correspondence of the state transition and whether PDSN reselection is performed
can be found in the remainder of this document
2) PDSN Failure:
68
2002 Motorola, Inc

During normal operations, each PDSN is pinged repeatedly to monitor for failures. If a PDSN fails
to respond successfully to 2 successive pings, the PDSN is determined to have failed. For all sessions that were active on the PDSN at the time of failure, PDSN reselection is performed. For sessions that are dormant, a page is issued to the corresponding mobile. When the mobile responds
to the page, and a new session established, a new PDSN will be selected. Paging of dormant sessions is performed in groups of up to DormantPageLimit sessions. After the pages have been
issued for each group then PCF waits time equal to TpageDormant before paging the next batch of
dormant sessions
In all cases where PDSN reselection is performed the new PDSN is selected by round-robin selection in the list of active PDSNs
If the Registration Message that was reselected does not reach the PDSN, what operation does the PCF
perform?
Response:
If a Registration Message that was resent does not result in a response, the PCF retries the message
for a configurable number of times according to the RegReqMaxRetries parameter. After this retry
limit is exceeded then action is performed as described below. [Note: There is some ambiguity in the
question and clarification of the question may be necessary]
Please list the conditions on which the PDSN's Reselect operates, for
each one of [new call],[renewal (Active call)], [renewal (Dormant call)], [Tear down], and [Reactivate from
Dormant] and [transition from Active to Dormant].
[new call]
Response:
For a new RP session establishment, if there is no response to RRQ, the PCF retries the message for a
configurable number of times according to the RegReqMaxRetries parameter. After this retry limit is
exceeded the PCF will choose another PDSN from its list, upto a configurable number of times based on
the PDSN reselection count. (Table 3.6 in Section 3.2.2.5). PDSNs are selected in a round-robin manner.
[transition from Active to Dormant]
Response:
For transition from Active to Dormant if the PDSN does not respond the PCF retries the message for a configurable number of times according to the RegReqMaxRetries parameter. After this retry limit is exceeded
the mobile is paged. When the mobile responds and PCF receives A9-Setup-A8 a new PDSN will be
selected and ppp session established.
[Reactivate from Dormant]
Response:
For reactivation from Dormant, if the PDSN does not respond the PCF retries the message for a configurable number of times according to the RegReqMaxRetries parameter. After this retry limit is exceeded
the PCF will choose another PDSN from its list, upto a configurable number of times based on the PDSN
reselection count.
69
2002 Motorola, Inc
[Tear Down]
Response:
In case of tear down, Registration Request with Lifetime = 0 is sent. If no responses are received the PCF
retries the message for a configurable number of times according to the RegReqMaxRetries parameter.
After this retry limit is exceeded an A9-Release-A8-Complete is sent to the selector to complete the tear
down of the session.
[renewal (Active call)],
Response:
For active calls, when the PCF tries to renew lifetime, if the PDSN does not respond the PCF retries the
message for a configurable number of times according to the RegReqMaxRetries parameter. After this
retry limit is exceeded the PCF will choose another PDSN from its list, up to a configurable number of times
based on the PDSN reselection count.
[renewal (Dormant call)],
Response:
For dormant calls, when the PCF tries to renew lifetime, if the PDSN does not respond the PCF retries the
message for a configurable number of times according to the RegReqMaxRetries parameter. After this
retry limit is exceeded the RP session with that PDSN will be torn down immediately without waiting for lifetime to expire.
* Please also list the contents included in the VOSE field when reselected.
RP Session Setup Air link record and the Active Start Airlink record are sent to the selected PDSN.
Behavior of Dormant call
4. We understand that a session is formed with a new PDSN for the number set by (2) DormantPageLimit
for each of the value set by (1) TpageDormant. Is our understanding correct?
Response:
Yes. In the case PDSN reselection is performed after PDSN failure has been detected by ping failures, the
session re-establishment is controlled by these 2 configurable entities. Dormant mobiles that were being
served by the failed PDSN are paged. Dormant Page Limit is the number of simultaneous pages requested
from that PCF. For example, if DormantPageLimit is 5 then no more than 5 pages will be sent at a time. A
time interval = TpageDormant will elapse before the next group of pages is sent.
5. Our understanding is as follows. By the TpageDormant operation, if a Reactivate request is made from a
mobile station before moving a session, as the result of a Reselect operation, a session is formed with
another PDSN. Is this understanding correct?
Response:
YES. If the mobile originates after PCF has determined that the PDSN has failed, a new PDSN will be
selected for that mobile.

70
2002 Motorola, Inc

6. When reactivated by TpageDormat, what will be in the VOSE Field inside the Registration Request that
is sent to the PDSN?
Response:
After paging the mobiles, the old sessions are cleared. Any reactivation is treated like a new session
establishment. RP Session Setup Air link record and the Active Start Airlink record are sent to the
selected PDSN.

71

TROUBLE SHOOT Packet Data PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TROUBLE SHOOT Packet Data PDF

Uploaded by

Copyright:

Available Formats

Troubleshooting 1X Data

2002 Motorola, Inc

Troubleshooting R16.0 1X Data Service

Version No.: 1.01

Last modified 6/5/02

2002 Motorola, Inc

Motorola. "Supercell Performance Management Software Functional Specification", Version 16.0.

Motorola. "SMAP Operators Guide", Version 2.16.x.x. January, 2002

Motorola. "UNO 2.16.0.0 Administrators/Users Guide", Version 2.16.0.0. May, 2001

Motorola. "System Functional Specification System Surveillance, Reconfiguration, and Recovery",

Motorola. "CDMA Online Document - Performance Analysis", Release 2.16.0. 2002

Motorola. "CFC Resolution Document", Version 2.3.3, May, 2002

Last modified 6/5/02

2002 Motorola, Inc

2002 Motorola, Inc

Last modified 6/5/02

2002 Motorola, Inc

Statistics Collection and Fault Monitoring . . . . . . . . . . . . . . . . . . . . 15

Performance Management Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Troubleshoot - Call Setup Failures. . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2002 Motorola, Inc

Low Data Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.2.10 CFC 112 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

CDL example for a good data call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Debug Log Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Packet Data FAQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

PCF Buffer Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Last modified 6/5/02

2002 Motorola, Inc

R16.0 1X Data Call Path . . . . . . . . .

Last modified 6/5/02

2002 Motorola, Inc

Packet Data Related CDL Elements . . . . . . . . . . . . . . . . . . . . 28

Last modified 6/5/02

2002 Motorola, Inc

Phase 1 further provides basic guideline for troubleshooting 1X packet

Last modified 6/5/02

2002 Motorola, Inc

Last modified 6/5/02

2002 Motorola, Inc

Figure 1. R16.0 1X Data Call Path

2.1 Call Flow

Figure 2. Packet Data Call Flow

Last modified 6/5/02

2002 Motorola, Inc

Successful Packet Data Call Setup Procedures

The MS transmits an Origination message or a Page Response

The MM receives the message, determines that this is a request

6. SCTP: SCAP CDMA PCF Resource Request

Last modified 6/5/02

2002 Motorola, Inc

Successful Packet Data Call Setup Procedures

7. Timer: Start PCFReqT

The SCCP Connection Confirmed from the MSC may also be

The PCF Resource Response may contain the stored service

Last modified 6/5/02

2002 Motorola, Inc

Successful Packet Data Call Setup Procedures

24. Timer: Stop PCFReqT

27. Timer: Start XcCpT11

28. EXEC: SM Port Lock Request (request PSI-SDU resource)

Last modified 6/5/02

2002 Motorola, Inc