You are on page 1of 20

subject:

RF Call Trace capabilities for 3G1x Voice and Data calls R21.0

date:

October 3, 2003 CDMA RF Optimization & Applications Group

Abstract

The purpose of this document is to describe 3G1x RF Call Trace metrics for their use in RF optimization and performance monitoring of both 3G1x Voice and Data systems. The paper addresses metrics available through R21.0.

Lucent Technologies Proprietary


Internal Distribution Only

Table of Contents 1 2 Introduction ......................................................................................................................................... 3 3G1X RFCT Capabilities .................................................................................................................... 3 2.1 RFCT capabilities for 3G1x Voice calls .3 2.2 RFCT capabilities for 3G1x High Speed Data (HSD)......4

3 Use Of 3G RFCT Metrics In RF Optimization/Performance Troubleshooting - Use Of RFCT Metrics/Workarounds ................................................................................................................................ 5 3.1 Use of RFCT metrics for 3G1x Voice RF optimization/performance troubleshooting ..6 3.1.1 Reverse FCH Before-frame-selector (BFS) and After-frame-selector (AFS) frame counts ... 6 3.1.2 Reverse Eb/No ........................................................................................................................ 6 3.1.3 Traffic Channel power (Ectf) .................................................................................................. 6 3.1.4 Forward Pilot Ec/Io ................................................................................................................. 7 3.1.5 Round-trip delay...................................................................................................................... 7 3.2 Use of RFCT metrics for 3G1x Data calls7 3.2.1 Average FFCH traffic channel power (Ectf)........................................................................... 8 3.2.2 Average FSCH traffic channel power (Ects)........................................................................... 8 3.2.3 Number of FSCH frames for each rate.................................................................................... 8 3.2.4 Before-frames selection (BFS)/After-frame selection (AFS) RSCH error frame counts........ 9 3.2.5 Number of RSCH frames for each rate ................................................................................... 9 3.2.6 Average total power transmitted by the sector/carrier(s) supporting the FCH Active set ...... 9 3.2.7 F-SCH DTx frame counts accumulated over each F-SCH rate............................................. 10 3.2.8 After-selection R-SCH DTx counts accumulated over each R-SCH rate ............................. 10 3.2.9 Reverse Eb/No for each R-SCH leg for each R-SCH rate .................................................... 11 3.2.10 Cumulative counts of total received F-SCH frames reported by mobile .............................. 11 3.2.11 Cumulative counts of received total and good LTU counts reported by the mobile............. 11 3.2.12 Cumulative counts of total transmitted R-SCH frames reported by mobile ......................... 11 3.2.13 Forward SCH Burst History.................................................................................................. 12 3.2.14 Information on a per burst basis up to a maximum of 12 RSCH bursts per polling interval 13 3.2.15 Anchor Transfer History ....................................................................................................... 15 4 REFERENCES .................................................................................................................................. 15

APPENDIX 1: RFCT METRIC TO RELEASE MAPPING................................................................ 16 APPENDIX 2: AN OVERVIEW OF LUCENT RECOMMENDED OPTIMIZATION PROCEDURES ......................................................................................................................................... 18

Lucent Technologies Proprietary


Internal Distribution Only

Introduction

RF Call Trace (RFCT) is a Lucent tool, often utilized to collect RF performance metrics from the cell site for a given test call. Traditionally, its use has been integral to RF optimization, performance monitoring and RF problem investigation efforts in 2G systems. A past few software releases have introduced several RFCT metrics for 3G1x test calls. In this document, we discuss RFCT metrics reported for 3G1x Voice and Data calls in CDMA releases 17.03 through 21.0. In addition to outlining their use in Lucent recommended RF optimization procedures, we discuss their application in investigating RF performance related issues. Note that the implementation of 3G1x in 17.03 required use of a new base station ASIC to support both 2G and 3G calls. This new ASIC significantly altered the manner in which data had to be collected and processed to compute RF Call Trace metrics. Due to the risk of this added development complexity, it was decided to defer some of the RF Call Trace functionality in the initial 3G releases. In the meantime, potential workarounds can be used to aid RF optimization and performance troubleshooting. Although the primary emphasis of this paper is on the 3G1x metrics, we also discuss potential workaround for a 2G metric that was deferred in R17.03 due to the development complexity. We begin below by listing various 3G1x Voice and Data RFCT metrics in Section 2. In section 3, we provide a discussion on the use of these metrics as well as potential workarounds for some of the deferred ones. Appendix 1 shows release information for various RFCT metrics. Appendix 2 provides a synopsis of Lucent recommended RF optimization guidelines for 3G1x Voice and Data. For exhaustive discussion on the 3G1x RF optimization guidelines, refer to [1].

3G1x RFCT capabilities

This section provides a breakdown of 3G1x Voice and Data RFCT metrics. For a quick reference, refer to Tables 1 and 2 in Appendix 1, which provide a mapping of metrics to software release. Note that each metric is polled and reported by RFCT at a user-specified interval. 2.1 RFCT capabilities for 3G1x Voice calls

There are many similarities in the RFCT metrics reported for 2G and 3G1x voice calls. We begin by listing the full set of 2G metrics. The comparison also leads to a better understanding of potential workarounds for some of the deferred metrics discussed in section 3. Below, we provide the full set of 2G metrics traditionally reported on 2G CCU as well a view of incremental availability of 2G/3G1x metrics on 3G CCU. The full set available on 2G CCU (no change in any recent software release) include: - Pre-selector/Post-selector reverse frame counts to assist in RFER computation - Traffic channel power of the primary leg (in dgu)

Lucent Technologies Proprietary


Internal Distribution Only

Reverse Eb/No (dB) for each leg Forward Pilot Ec/Io (dB) for each leg Round trip delay (chips) for each leg Call status info: Cell site, antenna face, PN offset, type of leg (primary/secondary), priority group, and CE# for each leg

In R17.03, RFCT reports the following on 3G CCU: - For 2G calls, all above metrics with the exception of reverse Eb/No - For 3G calls, all the above metrics with the exception of Traffic channel power, and Reverse Eb/No In R17.10/R17.11/R17.12, RFCT reports the following on 3G CCU: - For 2G calls, full 2G-metric set as supported on 2G CCU. Specifically, it adds reverse Eb/No - For 3G calls, reverse frame counts for RFER calculation, call status info, and Fundamental traffic channel power (Ectf 1) are reported, while Reverse Eb/No, Pilot Ec/Io, and round trip delay are not available In R20, RFCT reports the following on 3G CCU: - For 3G calls, full 2G-metric set on 3G CCU. Specifically, it adds support for Reverse Eb/No, Pilot Ec/Io and round-trip delay. 2.2 RFCT capabilities for 3G1x High Speed Data (HSD) Release 18.0 RFCT introduces several new metrics to assist with the performance evaluation of a 3G1x HSD test call. These include: Average F-FCH traffic channel power (Ectf) for each leg Average F-SCH traffic channel power (Ects) for the anchor leg over each F-SCH rate Number of F-SCH frames transmitted by the anchor leg accumulated over each FSCH rate Pre-selector (per leg) and after-selection RSCH error frame counts accumulated over each RSCH rate Number of good after-selection R-SCH frames accumulated over each R-SCH rate

In addition to the above, it also carries over from R17.1 the reporting of per leg/after-selection frame counts for the R-FCH, which can be used to derive the R-FCH frame error rate. Each of the above counts is reported per the polling interval specified at run-time. An expanded list of metrics is available in Release 20, augmenting the performance monitoring capabilities for a 3G1x HSD call. It includes: - Average total power transmitted by the sector/carrier(s) supporting the FCH Active set - F-SCH DTx frame counts for the anchor leg accumulated over each F-SCH rate - After-selection R-SCH DTx counts accumulated over each R-SCH rate - Reverse Eb/No for each R-SCH leg for each R-SCH rate - Cumulative counts of total received F-SCH frames reported by mobile - Cumulative counts of received total and good LTU counts reported by the mobile - Cumulative counts of total transmitted R-SCH frames reported by mobile
1

Note that in 17.10, RFCT introduces traffic channel power (Ectf) for a 3G call. It is only available in the textformat output mode of RFCT. This represents the linear ratio of FCH Traffic channel power to Pilot power transmitted by cell site. It is reported for each leg in the Active set for that call. It is also reported in raw format starting release 18.0.

Lucent Technologies Proprietary


Internal Distribution Only

In addition, RFCT in R20 allows constraining the F-SCH and/or R-SCH rates for the test call being monitored. It overrides the minimum and maximum rates specified in the translation for this call. This can be used for performance characterization (such as Data coverage) on a per SCH rate basis. Note that if the cell does not have the resources, it will not allow a lower SCH rate, rather limit the transmission to FCH on that link. R21 introduces a powerful set of metrics designed to lend better understanding into SCH rate allocation. The R21 capability includes: - Information on a per burst basis up to a maximum of 12 FSCH bursts per polling interval o Timestamp o Requested and allocated burst rates o Allocated and actual burst duration o Radio Configuration o Type of burst denied or new or continuation o Resource Block / Rate Reduction Indicator o Continuation denial reason o Cell, sector and PN offset info for simplex and softer anchor legs o Early release reason o Softer or simplex mode o Simultaneous FFCH + FSCH flag - Information on a per burst basis up to a maximum of 12 RSCH bursts per polling interval o Timestamp o Requested and allocated burst rates o Allocated and actual burst duration o Radio Configuration o Type of burst denied or new o Resource Block / Rate Reduction Indicator o Early release reason - History of up to 10 Anchor Transfers per polling interval with time-stamps - Ects (for non-DTx frames) broken into simplex and softer burst durations - FSCH frames counts (DTx and non-DTx) broken into simplex and softer burst durations

Use of 3G RFCT metrics in RF optimization/performance troubleshooting Use of RFCT Metrics/Workarounds

In the following sub-sections, we discuss typical roles of various existing and planned RFCT metrics in RF optimization as well as performance troubleshooting. We treat Voice and Data metrics separately. When performing RF optimization, drive test data is often the primary source of RF information to help decide on parameter adjustments. Drive test data is typically collected with a test mobile via the Mobile Diagnostic Monitor (MDM) such as Qualcomms CAIT as well as RFCT. Below we discuss several important RFCT metrics, and their use in RF optimization/problem investigation. We also suggest some potential workarounds for the RFCT metrics not supported in initial 3G1x releases.

Lucent Technologies Proprietary


Internal Distribution Only

3.1

Use of RFCT metrics for 3G1x Voice RF optimization/performance troubleshooting

3.1.1 Reverse FCH Before-frame-selector (BFS) and After-frame-selector (AFS) frame counts These are a set of counts reported per soft handoff leg (BFS counts) as well as after the frame selector (AFS counts). They include good frame counts of each rate (full, half, eighth, quarter), insufficient quality (error frames) and full rate frames received with bit errors (often referred to as full rate likely frames). The primary use of this set of counts is in the computation of RFCH FER at the after-selector. This is defined as the ratio of sum of insufficient quality and full rate likely frames to the sum of all frame counts. Lucent considers RFCH FER as the most critical performance optimization metric provided by RFCT. It is used to identify areas of degraded reverse link performance, and is often used as a cluster acceptance metric. This metric is available for both 2G and 3G1x Voice calls (release 17.03 onwards for calls on 3G CCU), and can be utilized to evaluate the impact of RF optimization on the reverse link. This metric is very useful in evaluating reverse link coverage, when used together with the mobile transmit power as reported by MDM. This metric can also be utilized in special problem investigations. A potential use is in isolating the link causing a problem such as dropped call. For example, if the forward link coverage is good as evidenced by good forward FER, but the reverse FER is unacceptably high, then the root cause analysis can focus on the reverse link (reverse link power control translations, external interference on the uplink, other issues with reverse power control, etc.). 3.1.2 Reverse Eb/No

This metric is an indicator of energy received on the reverse-link traffic channel for a given call.. It is typically used for special problem investigation, such as diagnosing dropped calls that occur from non-RF reasons. It is not commonly used for RF optimization performed by Lucent engineers. The metric is not reported for 3G1x calls until release 18.0. In its absence, the mobile transmit power collected via a MDM can be used in conjunction with the Reverse FER metric discussed earlier. Taken together, these metrics form a good indicator of reverse link performance. For example, in regions where the reverse link runs out of coverage while the forward link performance is adequate, it would tend to exhibit high RFER along with high mobile transmit power. This condition would indicate a reverse link coverage limitation for which appropriate remedial measures can then be pursued. Another important use of this metric is in estimating reverse link capacity. When 2G reverse Eb/No is introduced on a 3G CCU in R17.10, it becomes possible to obtain a relative indication of 3G Eb/No by comparing the difference in mobile transmit power between concurrent 2G and 3G voice calls placed over the same drive route. This relative comparison is also possible in R17.03, if the 2G call is setup on a 2G CCU. 3.1.3 Traffic Channel power (Ectf)

This metric is an indication of the amount of traffic channel power transmitted from the cell site for an active call traced by RFCT. Traffic channel power is not reported for 3G calls until R17.10. While traffic channel power is not directly used for RF optimization, it can serve as a good indicator for
Lucent Technologies Proprietary
Internal Distribution Only

comparing traffic channel power requirements between 2G and 3G calls. In R17.10, 3G traffic channel power is available when RFCT logs are dumped in text mode (the raw output format is not available until R18.0). As R17.1 is deployed in more markets, it allows evaluating 3G traffic power requirements using RFCT. In the past, this metric has also been employed to validate OCNS values for simulated loading. While it will be desirable to validate per user power requirement for OCNS loading, the 2G loading values can be applied for 3G calls also. This is based on the rationale that the average interference to the test mobile tends to remain the same, whether it came from a relatively small population of 2G users, or larger number of 3G users each consuming less power. Additionally, based on the initial evidence, 2G optimized systems in general need not be optimized further for 3G Voice, and hence the absence of this metric should not have a major impact from the RF optimization viewpoint. Mobile reported metrics In the initial 3G1x releases, Lucent made a decision to avoid collecting metrics that are reported from the mobile due to efficiency reasons. This was to reduce the amount of signaling on both the links, as well as from the fact that a more accurate measurement could be obtained from the mobile directly using the MDM. Received pilot Ec/Io and round-trip delay are the two main data items and are mentioned below. These are re-introduced in release 20 to support customer requests. 3.1.4 Forward Pilot Ec/Io

This metric is obtained from Pilot Strength Measurement Message (PSMM) sent to the cell site by the mobile. Note that MDM also reports this information. In addition, MDM may report Pilot Ec/Io for additional Pilots as well, and at a finer resolution. Therefore, there is no major impact from not having this metric via the RFCT, other than the logistics of carrying out the necessary drive test to collect the MDM data. 3.1.5 Round-trip delay

This is the round-trip delay estimate to the cell site based on the earliest arriving energy from the mobile PN code. It can be used as an indicator of distance of the mobile from cell site. It is typically not used for RF optimization, but could be used for special problem investigation. Round-trip estimate from a concurrent 2G call, placed on the same 3G CCU carrying the 3G-test call, may be used as a potential workaround for estimating the round trip delay for 3G calls in any problem investigation. An alternate method is to use the GPS information saved from a test call with MDM logging, and use that along with the GPS coordinates of the cell-sites to obtain round-trip delay estimates via post-processing. 3.2 Use of RFCT metrics for 3G1x Data calls

Similar to Voice calls, the various metrics reported by RFCT for 3G1x Data can find use in cluster acceptance exit, general performance characterization as well as special problem troubleshooting. Similar to Voice calls, some of these metrics can be used in conjunction with those from the MDM to perform a more complete analysis. We briefly discuss some of these applications below.

Lucent Technologies Proprietary


Internal Distribution Only

3.2.1

Average FFCH traffic channel power (Ectf)

This is reported as ratio of traffic channel power sent by the cell site to the mobile on the forward fundamental channel of a data call, to the Pilot power transmitted on that sector-carrier. It is expressed as a linear ratio, and provided for each Active set leg to give an indication of power demanded by the mobile to meet target FFCH FER. Over a given drive test, it helps attain a view of average power requirement on the FFCH. It may also be used for special problem investigation. For example, Ectf combined with information such as FFCH Eb/No set point, measured FFCH FER, and forward power control commands obtained from the MDM, is useful to investigate a dropped call problem - it can indicate whether the cell site transmitted sufficient power to meet the mobiles power requirement. This combination of metrics can also be effective in identifying forward link power control issues at the cell site or the mobile. 3.2.2 Average FSCH traffic channel power (Ects)

This is expressed as linear ratio of supplemental channel power transmitted by the anchor cell to the mobile for each of the assigned rates, to the Pilot power on the forward link. It is averaged over all bursts of a given rate within the polling interval, and reported separately for each rate. Similar to the Ectf, it can be useful in characterizing power requirements to support transmission at each rate for various target FSCH FER levels, and under different RF conditions. One potential use of that may be to determine why higher FSCH rates are not assigned at a given location. For example, if power required for a given assigned rate is already reaching the maximum allowed levels, a higher rate may not be possible. There are a couple known issues with this metric in release 18. First, the Ects value is occasionally reported lower than the FSCH minimum gain actually allowed by the cell site. Second, sometimes a nonzero Ects gain value is reported with a zero F-SCH frame count for a given rate. Both these problems are attributed to how the cell site treats Discontinuous Transmission (DTx2) frames in the Ects computation, and also to a potential misalignment between the Ects and Frame Count reporting boundaries. While the Ects accuracy is sacrificed in the presence of DTx frames, the F-SCH frame count, discussed next, is still accurate, especially, when viewed independent of Ects. Both the problems were fixed in R19. Starting R21, the frame counts are reported separately to reflect FSCH transmission in simplex and softer modes. 3.2.3 Number of FSCH frames for each rate

This provides the number of FSCH frames per rate transmitted by the anchor cell, and makes it possible to estimate the average power over a longer duration by utilizing this metric in conjunction with the Ects metric. Without this information, a proportional average is not possible since each polling interval consists of different burst lengths at any given rate. Note that the Frame Count excludes DTx frames. Starting R21, the frame counts are reported separately to reflect FSCH transmission in simplex and softer modes.

DTx on the forward link is a special type of F-SCH frame discussed in section 4.2.7.

Lucent Technologies Proprietary


Internal Distribution Only

3.2.4

Before-frames selection (BFS)/After-frame selection (AFS) RSCH error frame counts

These represent the number of RSCH frames received in error and are provided per rate. Further, the BFS counts are reported per soft handoff leg. The primary value is provided by the AFS counts for their use in deriving an important RF performance metric called RSCH FER. It is defined as the ratio of the frames received in error to the total RSCH frames (both counts are after-selection). The total RSCH frame is computed by adding the frame error counts to the good RSCH frames received at the AFS (next metric discussed the latter). Similar to RFCH FER, RSCH FER is a critical metric for evaluating performance of the reverse link, and for special problem investigation. It also helps to characterize impact of any RF optimization procedures conducted in the network. The comparison of BFS and AFS error frame counts allows evaluating the effectiveness of softhandoff selection diversity similar to that for the voice RFCH counts. Normally, the individual BFS error frame counts for each active soft handoff leg will at least equal the AFS error frame count (per rate), similar to the case of RFCH error frame counts. However, unlike the RFCH case, the BFS RSCH counts can sometimes be lower than the AFS counts. This is per the design of the Lucent RSCH frame selection algorithm. The frame selector prefers an error frame to a DTx frame3. Hence, the BFS error frame count for a soft-handoff leg can be lower if it presented a DTx frame, but the frame selector chose an error frame from a different soft-handoff leg. The selection of error frame over DTx allows a more aggressive treatment of the reverse outer loop power control. Treating the frame as error allows increasing the RSCH Eb/No set point, and hence, mobile transmit power, compared to the case of DTx where cell site leaves the set point unchanged. This offers RSCH an opportunity to recover from a temporary impairment assuming the signal was weak in the first place making it difficult to differentiate a DTx frame from an error count. Note that in general, the frame selector chooses good frame over error or DTx frame, and an error frame over DTx. 3.2.5 Number of RSCH frames for each rate

As mentioned earlier, these frame counts are used in conjunction with the previous metric to provide average RSCH FER per rate. The use of this derived metric is discussed above. 3.2.6 Average total power transmitted by the sector/carrier(s) supporting the FCH Active set

This is short-term average power transmitted by the cell site relative to the Pilot power. It is reported for each leg in the FCH Active Set and pertains to the carrier the test call is active at the time of reporting. This provides an estimate of RF loading on the forward link. It can often be used in conjunction with Ectf and/or Ects to assess the fraction of cell site power consumed by the test call. This can prove useful in capacity planning. Since it is a ratio of two quantities both of which get scaled equally when AOC scaling kicks in, it represents an unscaled power ratio.

DTx on the reverse link is a special type of RSCH frame discussed in section 4.2.8. DTx frame counts are included in neither the BFS nor the AFS error frame counts. AFS DTx counts are available starting R20.

Lucent Technologies Proprietary


Internal Distribution Only

10

Converting the reciprocal of this metric into dB (that is, 10 * log10 (1/x)) provides a short-term estimate of another important parameter called transmit Pilot Ec/Io of the cell site. This derived metric can be used to facilitate analysis/RF optimization for the CDMA Inter-frequency Handoff Trigger Improvement (CIFHOTI) feature. One of the components of CIFHOTI trigger is the Loss metric which is defined as the difference between the cell site transmit Pilot Ec/Io and the sum of received Pilot Ec/Io for the Active set Pilots reported by the mobile. This difference is compared against a threshold to evaluate whether the one of the handoff criteria is met. Since the transmit Pilot Ec/Io will vary over the drive test, knowledge of this metric is important in proper computation of the loss metric to more accurately predict potential IFHO handoff locations based on the drive test data. 3.2.7 F-SCH DTx frame counts accumulated over each F-SCH rate

Discontinuous Frames (DTx) is a special type of SCH frame defined in IS2000. As the name suggests, transmission is interrupted, that is, no data is transmitted. Such short intervals of DTx frames are often more efficient than tear-down/subsequent set-up of bursts especially when the incoming data stream itself is bursty. This metric provides a count of F-SCH DTx frames transmitted by the anchor cell over the polling interval for each F-SCH rate. It can be employed to assess the efficiency of the cell site transmission. For example, too much DTx activity may be indicative of wastage of cell site hardware resources (CE, PP). It may also represent burstiness of the Data application. In general, the use of the metric is more in the evaluation of cell site transmission algorithm, not for RF optimization or performance troubleshooting. Starting R21, the frame counts are reported separately to reflect FSCH transmission in simplex and softer modes. 3.2.8 After-selection R-SCH DTx counts accumulated over each R-SCH rate

Similar to the forward link, there is provision in IS2000 for DTx frame transmission on the reverse link. The mobile utilizes DTx when it has no data to send. It can transmit certain maximum number of DTx frames before taking a reverse burst down. The cell site specifies this maximum via overthe-air messaging. RFCT will report R-SCH DTx frame counts per R-SCH rate as counted at the output of the frameselector. It can be employed to assess the efficiency of the cell site transmission. Another potential use of the metric is to estimate the burstiness of the data traffic generated by the client. The metric can also be used to attain a more accurate view of the physical layer throughput on the reverse link because prior to Release 20 only the good and error RSCH counts are available. Basically, the RLP throughput can be defined as ratio of the sum of good frames weighted for RSCH rate to the sum of total frames weighted for RSCH rate. The denominator becomes more complete with the knowledge of DTx counts.

Lucent Technologies Proprietary


Internal Distribution Only

11

3.2.9

Reverse Eb/No for each R-SCH leg for each R-SCH rate

Similar to the reverse measured Eb/No for each R-FCH leg, this metric will be reported for each leg supporting the R-SCH of the test data call. While this metric is not typically used for RF optimization, it can be used as an important input parameter for reverse link budget and capacity computations. Low reverse Eb/No (well below the minimum target R-SCH Eb/No translation value) is often an indication of excess pathloss and/or interference. Combined with mobile transmit power for the R-SCH, it can be help assess whether mobile is suffering from RF coverage limitations at the drive test location. If pathloss or interference levels are within the expected nominal range, then low measured Eb/No and high mobile transmit power can point to some cell site performance issues such as those associated with the reverse power control. Mobile reported counts Several mobile reported counts are introduced in R20 to help better evaluate DTx performance on both the links. These are discussed below. 3.2.10 Cumulative counts of total received F-SCH frames reported by mobile The metric reports the number of F-SCH frames received by the mobile. RFCT will periodically poll the mobile for this information. The counts include good frames only (frames with sufficient quality). They can be used in conjunction with the RFCT cell site transmit frame counts (which also include nonDTx frames only) to assess the overall error/DTx detection performance of the mobile on the forward link. In general, the value of the frame counts is more for mobile algorithm performance analysis than for any specific use in RF optimization. 3.2.11 Cumulative counts of received total and good LTU counts reported by the mobile LTU stands for Logical Transmission Unit. Each SCH frame consists of certain number of LTUs depending on the rate. For example, a 16x SCH frame consists of 8 LTUs, 2x SCH frame contains 1 LTU, etc. RFCT will periodically poll the mobile for the number of total as well as good received LTU counts (Note that a DTx frame has no LTUs). The difference between the two counts is the number of bad LTUs received at the mobile. This provides an indication of error performance of LTU reception over the forward link. This metric is analogous to frame error rate except that LTUs are of finer resolution especially for higher rate frames. In general, from RF optimization perspective, frame error rate of the F-SCH is sufficient. 3.2.12 Cumulative counts of total transmitted R-SCH frames reported by mobile The metric reports the number of R-SCH frames transmitted by the mobile. RFCT will periodically poll the mobile for this information. The counts include good frames only (non-DTx). They can be used in conjunction with the RFCT AFS received counts for good, error, DTx frames to assess the error and DTx detection performance of the cell site. In general, the value of the frame counts is more for cell site algorithm performance analysis than for any specific use in RF optimization.

Lucent Technologies Proprietary


Internal Distribution Only

12

3.2.13 Forward SCH Burst History This is a collection of attribute indicators for each FSCH burst. RFCT reports a history of up to 12 bursts per polling interval. Each burst is marked with CDMA timestamp in a format consistent with the Tick ID Low field in a RFCT reply message. A burst, as defined here, could be a continuation segment with gaps or freshly assigned after a run of FFCH only frames. The attribute indicators for each burst include the following information: Requested and allocated burst rates The rates can be 0, 2x, 4x, 8x or 16x. The requested rate reflects the rate returned after the backlog check. The allocated rate, as the name suggests, is the physical rate assigned to the burst after graduating through various resource manager checks. Allocated and actual burst duration The duration is in units of 20ms frames. The allocated duration signifies length of the burst originally granted by the cell site, as also communicated to the mobile via ESCAM. The actual duration counts the number of non-DTx frames physically transmitted as part of this segment. It could be smaller than the allocated duration due to an early release or DTx. Radio Configuration This field is self-explanatory. With the current implementation, this will typically be 3 or 4 to reflect RC3 or RC4. Allocation Flag This flag represents the type of burst. It can take on the values of 0 (undefined) or 1 (new) or 2 (continuation). A new burst is always preceded by a run of FFCH only frames; that is, no FSCH burst existed immediately prior to this burst. A continuation is an extension of the previous burst (which could also have been a continuation) without any FSCH transmission between the two. Undefined is typically when a burst is denied. Resource Block / Rate Reduction Indicator Anytime the burst is not assigned the maximum possible rate4 or FSCH is denied altogether, the corresponding reason code is pegged via this indicator. There are several reason codes defined in the RFCT most of which are selfexplanatory, as follows: o 0 undefined (typically used for continuations at max rate) o 1 backlog is not large enough to warrant a higher rate o 2 internal error at the secondary leg o 3 power limitation o 4 power overload o 5 processor overload o 6 walsh code limitation o 7 packet pipe limitation o 8 channel fragment limitation o 9 n/a o 10 mobile max rate less than the system max rate o 11 n/a o 12 can not grant the max rate because it is a continuation Continuation denial reason If FSCH transmission is not continued at the end of an existing burst, a corresponding reason code is pegged. The possible values are:

Max possible rate is the max system FSCH rate as configured in the translations

Lucent Technologies Proprietary


Internal Distribution Only

13

o 0 undefined (used for fresh bursts or when continuation is granted) o 1 to allocate a higher rate o 2 preempted by other user o 3 request arrives out of the scheduling window o 4 - backlog is not large enough to continue at this rate Cell, sector and PN offset info for simplex and softer anchor legs Early release reason If an existing burst is terminated prematurely, the corresponding reason code is pegged, as follows: o 0 undefined (for bursts released normally) o 1 power overload o 2 revoking of the walsh code o 3 packet pipe contention o 4 skew group contention o 5 channel fragment contention o 6 anchor transfer o 7 soft/softer leg added o 8 soft handoff anchor drop o 9 semi-soft handoff o 10 primary transfer o 11 rate upgrade o 12 rate downgrade o 13 n/a o 14 mobile drop call o 15 - DCS initiated o 16 no response from mobile o 17 internal error o 18 secondary leg release Softer flag The flag can take on following values: o 0 undefined (when the burst was denied) o 1 simplex FSCH o 2 softer FSCH Simultaneous FFCH + FSCH flag The flag can take on following values: o 0 FSCH only or no burst at all o 1 FFCH plus FSCH

3.2.14 Information on a per burst basis up to a maximum of 12 RSCH bursts per polling interval This is a collection of attribute indicators for each RSCH burst. RFCT reports a history of up to 12 bursts per polling interval. Each burst is marked with CDMA timestamp in a format consistent with the Tick ID Low field in a RFCT reply message. For RSCH, each burst is a fresh burst of infinite duration, typically terminated after a finite duration by the mobile (such as, when it runs out of data to send) or cell site (such as, when it runs out of resources, handoff transition, rate upgrade/downgrade, etc.).

Lucent Technologies Proprietary


Internal Distribution Only

14

There is no concept of continuation unlike FSCH. The attribute indicators for each burst include the following information: Requested and allocated burst rates The rates can be 0, 2x, 4x, 8x or 16x. The requested rate reflects the rate returned after the backlog check. Mobiles based on MSM5105 chipset, which support max RSCH rate of 8x, will never peg more than 8x for the requested rate. The allocated rate, as the name suggests, is the physical rate assigned to the burst after graduating through various resource manager checks. Allocated and actual burst duration The allocated duration signifies length of the burst originally granted by the cell site, as also communicated to the mobile via ESCAM. As mentioned earlier, all RSCH bursts are assigned with an infinite duration. The actual duration on the other hand counts the number of non-DTx 20ms frames physically transmitted as part of this burst. It will always be finite duration. Radio Configuration This field is self-explanatory. With the current implementation, this will typically be 3 to reflect RC3. Allocation Flag This flag represents the type of burst. It can take on the values of 0 (undefined) or 1 (new). A new burst is always preceded by a run of FFCH only frames; that is, no FSCH burst existed immediately prior to this burst. Undefined is typically when a burst is denied. As mentioned earlier, each allocated RSCH burst is a fresh one; there is no concept of continuations. Resource Block / Rate Reduction Indicator Anytime the burst is not assigned the maximum possible rate5 or RSCH is denied altogether, the corresponding reason code is pegged via this indicator. There are several reason codes defined in the RFCT most of which are selfexplanatory, as follows: o 0 undefined (typically pegs when system max rate allocated) o 1 backlog is not large enough to warrant a higher rate o 2 internal error at the secondary leg o 3 RSSI limitation o 4 reverse overload o 5 processor overload o 6 n/a o 7 packet pipe limitation o 8 channel fragment limitation o 9 n/a o 10 n/a o 11 mobile requested rate less than the system max rate o 12 n/a Early release reason As mentioned earlier, all RSCH burst are assigned with infinite duration and then terminated early. The early reason codes are as follows: o 0 undefined (should typically never happen with infinite burst durations) o 1 RSSI overload

Max possible rate is the max system RSCH rate configured in the translations

Lucent Technologies Proprietary


Internal Distribution Only

15

o o o o o o o o o o o o o o o o o

2 n/a 3 packet pipe contention 4 skew group contention 5 channel fragment contention 6 n/a 7 soft/softer leg added 8 n/a 9 semi-soft handoff 10 primary transfer 11 rate upgrade 12 rate downgrade 13 mobile initiated release (mobile sent SCRM with 0 backlog requesting RSCH release) 14 mobile drop call 15 DCS initiated 16 no response from mobile 17 internal error 18 secondary leg release

3.2.15 Anchor Transfer History This field reports a history of up to 10 anchor transfers within a polling interval. Along with the time stamp (format same as that for Tick ID Lo field) to mark an anchor setup, it reports the corresponding cell/sector/PN offset information for the new anchor.

References

[1] 3G1x RF Optimization Procedures and Guidelines for PCS and Cellular CDMA Systems, Lucent Technologies.

Lucent Technologies Proprietary


Internal Distribution Only

16

Appendix 1: RFCT metric to Release Mapping


Table 1 below presents the list of metrics that are typically reported via RFCT and the minimum Lucent software release needed to support them.
Release 17.03 Metric 2G CCU Yes Yes Yes
6

Release 17.1 2G CCU Yes Yes Yes N/A Yes N/A Yes N/A Yes N/A Yes Yes 3G CCU Yes Yes Yes Yes Yes No Yes No Yes No Yes Yes

Release 20.0 2G CCU Yes Yes Yes N/A Yes N/A Yes N/a Yes N/A Yes Yes 3G CCU Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes

3G CCU Yes Yes Yes No No No Yes No Yes No Yes Yes

Frame counts/RFER Call status info. Traffic power (2G) Traffic power Ectf (3G:FCH) Reverse Eb/No (2G call) Reverse Eb/No (3G call) Forward Pilot Ec/Io (2G call) Forward Pilot Ec/Io (3G call) Round trip delay (2G call) Round trip delay (3G call) Multiple Dial Number RFCT7 2G/3G simultaneous RFCT

N/A Yes N/A Yes N/A Yes N/A Yes Yes

Table 18: Voice RFCT capabilities across different software releases

6 7

As noted previously, this data is not available in the raw output format in R17.1, but will be available in R18.0 Up to 10 calls may be supported with some restrictions on the polling interval. For example, the polling interval has to be at least a minimum of 5 seconds when 10 calls are traced simultaneously. Text in bold reflects newly added functionality in the release

Lucent Technologies Proprietary


Internal Distribution Only

17

In Table 2 below, we provide similar mapping for 3G1X data calls.


Release 18.0 3G CCU Frame counts/RFER (RFCH) BFS/AFS Non-DTx Frame counts/RFER (RSCH) Non-DTx Frame counts (FSCH) Call status info. Traffic power Ectf (3G:FFCH)10 Traffic power Ects (3G FSCH) Reverse Eb/No (3G call: RFCH and RSCH) Forward Pilot Ec/Io (3G call) Round trip delay (3G call) Multiple Dial Number RFCT12 DTx counts (3G F-SCH) AFS DTx counts (3G RSCH) Good and total LTU counts received by mobile (3G FSCH) Total frames received by mobile (3G FSCH) Total frames transmitted by mobile (3G RSCH) Upgrading all forward link frame counts to include 307.2 kbps (RC4) (3G FSCH) Capability to specify minimum rate for the test call (3G FSCH and RSCH) FSCH/RSCH Burst History Anchor Transfer History Yes Yes Yes Yes Yes Yes No No No Yes No No No No No No No No No Release 20.0 3G CCU Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes No No Release 21.0 3G CCU Yes Yes Yes9 Yes Yes Yes11 Yes Yes Yes Yes Yes13 Yes Yes Yes Yes Yes Yes Yes Yes

Metric

Table 214: Data RFCT capabilities across different software releases

Added granularity for simplex and softer FSCH durations As noted previously, this data is not available in the raw output format in R17.1, but will be available in R18.0 Added granularity for simplex and softer FSCH durations Up to 10 calls may be supported with some restrictions on the polling interval. For example, the polling interval has to be at least a minimum of 5 seconds when 10 calls are traced simultaneously. Added granularity for simplex and softer FSCH durations Text in bold reflects newly added functionality in the release

10 11 12

13 14

Lucent Technologies Proprietary


Internal Distribution Only

18

Appendix 2: An overview of Lucent recommended optimization procedures


The primary use of the RFCT metrics is in the RF optimization phase. They help validate the performance as parameter adjustments are made. RFCT can also be effective in investigating special performance issues. To help better appreciate the role of RFCT metrics, below is a brief overview of Lucents guidelines for optimizing 3G Voice and HSD networks. 3G1x Voice optimization procedures Lucents view is that the existing markets optimized for 2G should not require any additional RF optimization within the core 3G1x Voice service area. In general, this applies to an existing 2G carrier upgraded to offer 3G1x service or a newly added 3G1x carrier. We note that for a new 3G1x deployment, the same procedures can be utilized to optimize the 3G1x network, as traditionally applied to a 2G network. However, some additional optimization may be needed at 3G1x to 2G Voice handoff borders. Note that as 3G1x penetration increases, some 3G1x translations may need adjustments (such as intergeneration load balance thresholds) to benefit from reduced 2G traffic. However, it is unlikely that the basic RF optimization will have to be re-executed especially since the existing network of cell sites is expected to remain the same even with pure 3G1x traffic. Our recommended optimization procedures consist of fine-tuning all aspects of air-interface performance by adjusting a series of RF parameters. These parameters can be classified as primary and secondary, based on the frequency of their usage and the scope of their impact, and are listed below. Typically, this adjustment process does not directly make use of RFCT as the primary tool for the optimization process. Nonetheless, RFCT is used as a subsequent tool to validate or verify that the prior optimization steps are indeed working correctly; and as a data collection and monitoring tool while troubleshooting specific RF problems, primarily related to the reverse link. Key Primary parameters: (for coarse adjustment of performance) - CBR/BCR attenuation - Antenna adjustments - Neighbor Lists and priorities (FCI and CDHNL) - Semi-Soft and Hard handoff thresholds Key Secondary parameters: (for fine-tuning performance in problem areas) - Soft handoff thresholds - Active and Neighbor set Search Window sizes - Cell site search windows - Pilot, Paging, Sync and Traffic channel levels - Access Probe sequence parameters - Traffic channel Allocation bias (for load balancing via call assignments) and the new intertechnology thresholds

Lucent Technologies Proprietary


Internal Distribution Only

19

There is another set of parameters, which are not adjusted in the course of regular deployment optimization. These fixed parameters often involve complex performance interactions with coverage, capacity, and call quality, and are not easy to characterize or quantify. They are typically determined based on controlled performance studies, simulations, and laboratory measurements. Lucent will continue to update recommended values for these parameters as necessary via RF Application Notes. Key Fixed parameters: (not adjusted for optimization) - Forward and reverse power control parameters (additional parameters for 3G compared to 2G) - Forward and reverse overload parameters - Reverse Pilot fraction - Remaining set Search Window size As is evident from above, the RF optimization process deals mainly with the primary and secondary parameters. For most part, these remain the same for 2G and 3G systems. Many of the fixed parameters are different for 3G, but they are not adjusted as a part of optimization. 3G1x HSD optimization procedures Many of the 3G1x Data optimization goals are common to that for 2G or 3G1x Voice. For example, both Voice and Data have a FCH, which pose similar RF optimization requirements in order to maintain performance good coverage, low dropped call rate, low access failures and good soft-handoff performance. They also share similar RF optimization parameters (e.g., Antenna attributes, BCR/CBR, neighbor lists, handoff thresholds, etc.) However, Data can differ in its demand on RF optimization compared to Voice calls. For example, high Data rates may stress coverage, and suffer from Pilot pollution or lack of dominant coverage. Optimizing for Data may also require different RF loading considerations. Initial Lucent experience suggests light to moderate potential for re-optimizing an existing Voice network when 3G1x Data offer is introduced. Note that the amount of optimization will depend on current level of optimization of the Voice network. Efforts will be to improve Data performance (throughput, SCH FER, etc.) while preserving performance of the Voice calls. Conceptually, the 3G1x Data optimization procedures consist of fine-tuning parameters similar to that for Voice only systems. The parameters can also be classified as Primary, Secondary and Fixed depending on their scope and frequency of usage. Some differences with respect to Voice parameters are stated below. Key Primary Parameters - Same parameters as that for Voice, but additional emphasis on resolving non-dominant coverage areas Key Secondary Parameters (in addition to those for Voice) - Inter-technology load preference delta for Data - Anchor hysterisis threshold and Simplex FSCH Burst threshold Fixed Parameters (in addition to those for Voice)

Lucent Technologies Proprietary


Internal Distribution Only

20

F-SCH and R-SCH rate assignment algorithm parameters F-SCH and R-SCH power control parameters Anchor monitoring interval and FSCH Softer Burst threshold

As stated earlier, it is important to preserve Voice performance when optimizing for Data. Therefore, it is necessary to monitor both Voice and Data performance. The Data optimization procedures discussed above apply equally when either re-optimizing an existing Voice system or optimizing a new 3G1x Voice/Data deployment.

Lucent Technologies Proprietary


Internal Distribution Only

You might also like