401-614-413(EVDO PCMD)

Alcatel-Lucent CDMA2000® 1xEV-DONetwork1xEV-DORelease 30.0

Feature Provisioning Guide

401-614-413Issue 5

May 2008

Alcatel-Lucent - ProprietaryThis document contains proprietary information of Alcatel-Lucent and

is not to be disclosed or used except in accordance with applicable agreements.

Copyright © 2008 Alcatel-LucentUnpublished and Not for Publication

All Rights Reserved

See notice on first age

Alcatel, Lucent, Alcatel-Lucent and the Alcatel-Lucent logo are trademarks of Alcatel-Lucent. All other trademarks are the property of theirrespective owners.

The information presented is subject to change without notice. Alcatel-Lucent assumes no responsibility for inaccuracies contained herein.

Copyright © 2008 Alcatel-Lucent. All Rights Reserved.

See notice on first age

Alcatel-Lucent - ProprietarySee notice on first page

Contents

About this information product

Purpose....................................................................................................................................................................................... xxiiixxiii

Intended audience................................................................................................................................................................... xxiiixxiii

To obtain technical support, documentation, and training or submit feedback............................................ xxiiixxiii

Reason for reissue.................................................................................................................................................................. xxivxxiv

Chapter distribution................................................................................................................................................................. xxvxxv

Operations and Maintenance Center - Radio Access Network (OMC-RAN) equivalents to commonElement Management System (EMS) screens....................................................................................................... xxviixxvii

Conventions used.................................................................................................................................................................... xxxixxxi

Related information.............................................................................................................................................................. xxxiixxxii

History of revisions ............................................................................................................................................................ xxxiiixxxiii

How to comment.................................................................................................................................................................. xxxivxxxiv

1 CDMA 3G-1x EVolution Data Optimized (1xEV-DO) Flexible Scheduler

Overview ...................................................................................................................................................................................... 1-11-1

Availability .................................................................................................................................................................................. 1-31-3

Prerequisites................................................................................................................................................................................ 1-41-4

Feature description................................................................................................................................................................... 1-51-5

Feature interactions.................................................................................................................................................................. 1-71-7

Impacts on the Element Management System (EMS).............................................................................................. 1-81-8

Impacts on the Operations and Maintenance Center - Radio Access Network (OMC-RAN)............... 1-161-16

Impacts on service measurements................................................................................................................................... 1-231-23

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


iii

Implementing the feature.................................................................................................................................................... 1-241-24

Activating the feature........................................................................................................................................................... 1-251-25

Configuring the Flexible Scheduler feature for Service Nodes.......................................................................... 1-261-26

Configuring the Flexible Scheduler feature for base stations.............................................................................. 1-281-28

2 CDMA 3G-1x EVolution Data Optimized (1xEV-DO) Radio Access Network Authentication(RAN)

Overview ...................................................................................................................................................................................... 2-12-1

Availability .................................................................................................................................................................................. 2-32-3

Prerequisites................................................................................................................................................................................ 2-42-4



Impacts on service measurements...................................................................................................................................... 2-82-8

Implementing the feature....................................................................................................................................................... 2-92-9

Activating the Feature.......................................................................................................................................................... 2-102-10

Configuring the feature using EMS................................................................................................................................ 2-112-11

Provisioning the Access Terminal................................................................................................................................... 2-162-16

Provisioning the RAN AAA server................................................................................................................................ 2-172-17

Provisioning the route for RAN AAA on the TP..................................................................................................... 2-182-18

3 Cell Swing Capability for EVolution Data Optimized (1xEV-DO)

Overview ...................................................................................................................................................................................... 3-13-1

Availability .................................................................................................................................................................................. 3-43-4

Prerequisites................................................................................................................................................................................ 3-53-5

Feature description: Cell Swing Capability for 1xEV-DO...................................................................................... 3-73-7

Feature interactions................................................................................................................................................................ 3-193-19

Issues and caveats.................................................................................................................................................................. 3-223-22

Implementing the features.................................................................................................................................................. 3-233-23


Contents

...................................................................................................................................................................................................................................

iv Alcatel-Lucent - ProprietarySee notice on first page

401-614-413Issue 5, May 2008

Confirming feature activation........................................................................................................................................... 3-263-26

Determining the NthIP......................................................................................................................................................... 3-273-27

Move a 1xEV-DO cell (intra-RNC)............................................................................................................................... 3-293-29

Move a 1xEV-DO cell (inter-RNC/Same Service Node)...................................................................................... 3-443-44

Move a converged 1xEV-DO cell (inter-RNC/Different Service Node)......................................................... 3-613-61

Rename a cell.......................................................................................................................................................................... 3-793-79

Move and Rename a cell (intra-RNC).......................................................................................................................... 3-933-93

Move and Rename a cell (inter-RNC)........................................................................................................................ 3-1083-108

Cell Swing backout procedure....................................................................................................................................... 3-1263-126

Verify OA&M on moved and/or renamed converged cell................................................................................. 3-1293-129

Verify service measurements reporting....................................................................................................................... 3-1323-132

Cleanup of old Cell Swing files.................................................................................................................................... 3-1343-134

Moving Base Stations from R1SR Based 1xEV-DO RNC APs to Universal Cabinet (UNC)-Based1xEV-DO RNC APs........................................................................................................................................................ 3-1363-136

4 CDMA 3G-1x EVolution Data Optimized (1xEV-DO) Handoff Matrix (HOM) Tool andRelated Features

Overview ...................................................................................................................................................................................... 4-14-1

Availability .................................................................................................................................................................................. 4-54-5

Prerequisites................................................................................................................................................................................ 4-64-6

Feature description: 1xEV-DO HOM Tool feature (FID 12146.0)...................................................................... 4-94-9

Feature description: BC0/BC1 Dual Band 1xEV-DO (FID 8219.7)................................................................. 4-124-12

Feature description: 1xEV-DO Support for Multi-Carrier Coverage Differences (FID 8219.9)........... 4-144-14

Feature description: Support of Multiple 1xEV-DO Carriers - IFHO feature (FID 8219.11)................ 4-184-18

evstarthom command............................................................................................................................................................ 4-194-19

evdisphom command............................................................................................................................................................ 4-224-22

Feature description: Six Sector Modular Cell 4.0B with Mixed 1x and 1xEV-DO (FID 8882.2)...... 4-304-30


Contents

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


v

Service measurements: 1xEV-DO Support for Multi-Carrier Coverage Differences (FID 8219.9).... 4-334-33


Implementing the 1xEV-DO HOM feature (FID 12146.0)................................................................................... 4-374-37

Activating the 1xEV-DO feature (FID 12146.0)....................................................................................................... 4-384-38

5 Per Call Measurement Data (PCMD) for CDMA 3G-1x EVolution Data Optimized(1xEV-DO)

Overview ...................................................................................................................................................................................... 5-15-1

Availability .................................................................................................................................................................................. 5-45-4

Prerequisites................................................................................................................................................................................ 5-55-5

PCMD terminology.................................................................................................................................................................. 5-65-6



How data is delivered to the OMP-FX v.2.................................................................................................................. 5-115-11

Post-processing tool guidelines........................................................................................................................................ 5-155-15

Description of 1xEV-DO per-connection performance data delivered to the OMP-FX v.2................... 5-265-26

Per-connection performance data output examples from the OMP-FX v.2................................................... 5-475-47

How data is accessed from the OMP-FX v.2............................................................................................................. 5-635-63

Using telnet to retrieve EV-DO PCMD data.............................................................................................................. 5-645-64

Using FTP to retrieve EV-DO PCMD data................................................................................................................. 5-665-66

Using the EV-DO PCMD viewer to view EV-DO PCMD data......................................................................... 5-685-68

EV-DO PCMD viewer command format and syntax.............................................................................................. 5-705-70



Activating the PCMD for 1xEV-DO feature.............................................................................................................. 5-745-74

6 High Rate Packet Data Radio Network Controller (HRPD RNC) Performance andCapacity Improvements

Overview ...................................................................................................................................................................................... 6-16-1

Contents

...................................................................................................................................................................................................................................

vi Alcatel-Lucent - ProprietarySee notice on first page

401-614-413Issue 5, May 2008

Availability .................................................................................................................................................................................. 6-36-3

Prerequisites................................................................................................................................................................................ 6-46-4



Issues and caveats.................................................................................................................................................................... 6-86-8

Implementing the feature....................................................................................................................................................... 6-96-9


Activating the Carrier Capacity Enhancement........................................................................................................... 6-116-11

Deactivating the feature....................................................................................................................................................... 6-136-13

7 EVolution Data Optimized (1xEV-DO) Basic Revision A (Rev. A) Feature Bundle

Overview ...................................................................................................................................................................................... 7-17-1

Availability .................................................................................................................................................................................. 7-57-5

Prerequisites................................................................................................................................................................................ 7-67-6

Feature description: Basic Rev. A Feature Bundle..................................................................................................... 7-77-7





8 Enhanced Data Only Revision A (DOrA) Application Quality of Service (QoS) Features

Overview ...................................................................................................................................................................................... 8-18-1

Availability .................................................................................................................................................................................. 8-68-6

Prerequisites................................................................................................................................................................................ 8-78-7

Feature descriptions: DOrA Application QoS Features............................................................................................ 8-98-9




Contents

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


vii



9 CDMA 3G-1x EVolution Data Optimized (1xEV-DO) Backhaul w/Multi Link Point-to-PointProtocol at Layer 2 Over T1/E1

Overview ...................................................................................................................................................................................... 9-19-1

Availability .................................................................................................................................................................................. 9-49-4

Prerequisites................................................................................................................................................................................ 9-59-5



Element Management System (EMS) configuration management.................................................................... 9-109-10





Provisioning cell2 RC/V form.......................................................................................................................................... 9-159-15

10 EVolution Data Only (1xEV-DO) Revision A (Rev. A) Voice Over Internet Protocol (VoIP)and Application Pricing

Overview .................................................................................................................................................................................... 10-110-1

Availability ................................................................................................................................................................................ 10-510-5

Prerequisites.............................................................................................................................................................................. 10-610-6

Feature description: 1xEV-DO Rev. A VoIP and Application Pricing (FID 12905.0)............................... 10-710-7

Feature description: 1xEV-DO Rev A Application Pricing Enhancements (FID 12905.1)................... 10-1310-13

Feature interactions: 1xEV-DO Rev. A VoIP and Application Pricing (FID 12905.0)........................... 10-1710-17

Feature interactions: 1xEV-DO Rev A Application Pricing Enhancements (FID 12905.1).................. 10-1910-19

Impacts on service measurements: 1xEV-DO Rev. A VoIP and Application Pricing (FID 12905.0)............10-2010-2010-20 10-20

Impacts on service measurements: 1xEV-DO Rev A Application Pricing Enhancements (FID 12905.1)........................................................................................................................................................................................ 10-2310-2310-23

Contents

...................................................................................................................................................................................................................................

viii Alcatel-Lucent - ProprietarySee notice on first page

401-614-413Issue 5, May 2008

License Key Installation................................................................................................................................................... 10-2410-24

11 Radio Network Controller (RNC) Grouping to Improve Idle Hand-off Performance

Overview .................................................................................................................................................................................... 11-111-1

Availability ................................................................................................................................................................................ 11-311-3

Prerequisites.............................................................................................................................................................................. 11-411-4

Feature description................................................................................................................................................................. 11-511-5


Impacts on service measurements................................................................................................................................. 11-1011-10

Impacts on TI messages.................................................................................................................................................... 11-1311-13

Issues and caveats................................................................................................................................................................ 11-1511-15

Implementing the feature.................................................................................................................................................. 11-1811-18

Radio Network Controller (RNC) Group Setup Scenarios in Element Management System (EMS)..........11-1911-1911-19 11-19

Radio Network Controller (RNC) Group Setup Scenarios in Operations and Maintenance Center -Radio Access Network (OMC-RAN)..................................................................................................................... 11-2611-26

12 EVolution Data Optimized (EV-DO) Performance Monitoring Tools Enhancements

Overview .................................................................................................................................................................................... 12-112-1

Availability ................................................................................................................................................................................ 12-512-5

Prerequisites.............................................................................................................................................................................. 12-612-6

Feature description: 1xEV-DO Performance Monitoring Tools Enhancements (FID 9253.1)............... 12-812-8

Feature description: 1xEV-DO Tool Interface between OMP-FX and 1xEV-DO RNC (FID 9253.2)........................................................................................................................................................................................ 12-1112-1112-11

Feature description: AT Trace Enhancement for Customer Use (FID 9253.3).......................................... 12-1312-13

Feature interactions............................................................................................................................................................. 12-1512-15




Activating the feature: 1xEV-DO Performance Monitoring Tools Enhancements................................... 12-2712-27

Contents

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


ix

Activating the feature: AT Trace Enhancement for Customer Use................................................................. 12-2812-28

Manual Pages: AT Trace Enhancement for Customer Use................................................................................ 12-2912-29

13 Intra-Radio Network Controller (RNC) Session Resource Balancing in EVolution DataOptimized (1xEV-DO)

Overview .................................................................................................................................................................................... 13-113-1

Availability ................................................................................................................................................................................ 13-313-3

Prerequisites.............................................................................................................................................................................. 13-413-4






14 Inter-User Priority for Best Effort Data Applications (IUPBEDA)

Overview .................................................................................................................................................................................... 14-114-1

Availability ................................................................................................................................................................................ 14-414-4

Prerequisites.............................................................................................................................................................................. 14-514-5



Sample call scenarios......................................................................................................................................................... 14-1014-10

Impacts on the AAA network element........................................................................................................................ 14-1514-15

Impacts on the OMC-RAN network element.......................................................................................................... 14-1714-17


Configuration and implementation considerations................................................................................................. 14-2614-26


Activating the feature......................................................................................................................................................... 14-3014-30

Confirming feature activation......................................................................................................................................... 14-3114-31

Adjusting the IUP weight assignments for the Service Node........................................................................... 14-3214-32

Contents

...................................................................................................................................................................................................................................

x Alcatel-Lucent - ProprietarySee notice on first page

401-614-413Issue 5, May 2008

Adjusting the IUP weight assignments for a BTS................................................................................................. 14-3414-34

Setting Inter-User Priority attribute in AAA subscriber profile....................................................................... 14-3614-36

Enabling the feature............................................................................................................................................................ 14-3714-37

15 Jurisdictional Priority for Public Safety Users of Best Effort Data Applications(JPPSUBEDA)

Overview .................................................................................................................................................................................... 15-115-1

Availability ................................................................................................................................................................................ 15-415-4

Prerequisites.............................................................................................................................................................................. 15-515-5


Feature interactions............................................................................................................................................................. 15-1015-10

Sample call scenarios......................................................................................................................................................... 15-1115-11

Impacts on the AAA network element........................................................................................................................ 15-1615-16

Impacts on the OMC-RAN network element.......................................................................................................... 15-1815-18

Configuration and implementation considerations................................................................................................. 15-2715-27


Activating the feature......................................................................................................................................................... 15-3515-35

Confirming feature activation......................................................................................................................................... 15-3615-36

Creating jurisdictions......................................................................................................................................................... 15-3715-37

Creating OMC-RAN user account restricted to jurisdiction.............................................................................. 15-3915-39

Creating jurisdictional policies....................................................................................................................................... 15-4515-45

Updating jurisdictional policies..................................................................................................................................... 15-4715-47

Making jurisdictional policy assignments................................................................................................................. 15-4915-49

Making BTS assignments for a jurisdiction............................................................................................................. 15-5615-56

Viewing BTS assignments for a jurisdiction............................................................................................................ 15-5915-59

Setting Subscriber Home Area attribute in AAA................................................................................................... 15-6215-62

Enabling the feature............................................................................................................................................................ 15-6415-64

Deactivating the feature.................................................................................................................................................... 15-6615-66

Contents

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


xi

16 Universal Traffic Processor (UTP) Protocol Acceleration in Hardware

Overview .................................................................................................................................................................................... 16-116-1

Availability ................................................................................................................................................................................ 16-316-3

Prerequisites.............................................................................................................................................................................. 16-416-4



Configuration management................................................................................................................................................ 16-716-7



17 Backhaul Enhancement in Support of Small Packets on the Reverse and Forward Linksin 1xEV-DO

Overview .................................................................................................................................................................................... 17-117-1

Availability ................................................................................................................................................................................ 17-517-5

Prerequisites.............................................................................................................................................................................. 17-717-7

Feature description: Backhaul Enhancement in Support of Small Packets on the Reverse Link in1xEV-DO (Phase 1a) (FID 12102.5).......................................................................................................................... 17-917-9

Feature description: Backhaul Enhancement in Support of Small Packets on the Forward Link in1xEV-DO (Phase 1b) (FID 12102.14)..................................................................................................................... 17-1017-10

Feature interactions: Backhaul Enhancement in Support of Small Packets on the Reverse and ForwardLinks in 1xEV-DO features.......................................................................................................................................... 17-1117-11

Implementing the features................................................................................................................................................ 17-1417-14

Activating the Backhaul Enhancement in Support of Small Packets on the Reverse and Forward Linksin 1xEV-DO features via EMS................................................................................................................................... 17-1517-15

Deactivating the Backhaul Enhancement in Support of Small Packets on the Reverse and ForwardLinks in 1xEV-DO feature via EMS........................................................................................................................ 17-1717-17

Activating the Backhaul Enhancement in Support of Small Packets on the Reverse and Forward Linksin 1xEV-DO features via OMC-RAN...................................................................................................................... 17-1817-18

Deactivating the Backhaul Enhancement in Support of Small Packets on the Reverse and ForwardLinks in 1xEV-DO features via OMC-RAN......................................................................................................... 17-2017-20

Glossary

Contents

...................................................................................................................................................................................................................................

xii Alcatel-Lucent - ProprietarySee notice on first page

401-614-413Issue 5, May 2008

Index

Contents

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


xiii

List of tables


1 Reason for Reissue................................................................................................................................................ xxivxxiv


1-1 Flexible Scheduler parameters............................................................................................................................ 1-91-9

1-2 Flexible Scheduler parameters on the BTS instance page.................................................................... 1-131-13

1-3 Flexible Scheduler parameters.......................................................................................................................... 1-171-17

1-4 Flexible Scheduler parameters on the BTS instance page.................................................................... 1-201-20

1-5 1xEV-DO service measurements..................................................................................................................... 1-231-23


2-1 1xEV-DO service measurements........................................................................................................................ 2-82-8

4 CDMA 3G-1x EVolution Data Optimized (1xEV-DO) Handoff Matrix (HOM) Tool andRelated Features

4-1 Error Codes for evstarthom Command......................................................................................................... 4-204-20

4-2 Error Codes for evdisphom Command......................................................................................................... 4-254-25

4-3 Header Variables for evdisphom Command............................................................................................... 4-264-26

4-4 Record Variables for evdisphom Command............................................................................................... 4-274-27

4-5 1xEV-DO Support for Multi-Carrier Coverage Differences Feature: New Service Measurements............................................................................................................................................................................ 4-334-334-33

....................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


xv


5-1 EV-DO terminology................................................................................................................................................. 5-75-7

5-2 Key service measurements................................................................................................................................. 5-165-16

5-3 SMs for DO SM Enhancements Phase 2..................................................................................................... 5-195-19

5-4 CFC values............................................................................................................................................................... 5-205-20

5-5 Normal connection qualifiers............................................................................................................................ 5-215-21

5-6 Dropped connection qualifiers.......................................................................................................................... 5-225-22

5-7 AT-Initiated/AN-Initiated Connection Failed - Subscriber.................................................................... 5-225-22

5-8 AT-Initiated/AN-Initiated Connection Failed - Cell................................................................................. 5-235-23

5-9 AT-Initiated/AN-Initiated Connection Failed - RNC............................................................................... 5-235-23

5-10 AT-Originated/AN-Originated Connection Failed - Network.............................................................. 5-245-24

5-11 EV-DO PCMD record data fields - Administrative................................................................................. 5-285-28

5-12 EV-DO PCMD record data fields - Session............................................................................................... 5-295-29

5-13 EV-DO PCMD record data fields - Connection....................................................................................... 5-315-31

5-14 EV-DO PCMD record data fields - RLP Layer........................................................................................ 5-365-36

5-15 EV-DO PCMD record data fields - Key Service Measurements....................................................... 5-365-36

5-16 EV-DO PCMD record data fields - Personality Type:........................................................................... 5-385-38

5-17 EV-DO PCMD record data fields - Additional Data.............................................................................. 5-385-38

5-18 DO PCMD RUM Fields ..................................................................................................................................... 5-425-42

5-19 Flow Data Fields.................................................................................................................................................... 5-445-44

5-20 Flow Final Classes (FFC) and FFC Qualifiers for Flow Reservation............................................. 5-465-46

5-21 evdo_pcmdaemon command options............................................................................................................. 5-705-70

7 EVolution Data Optimized (1xEV-DO) Basic Revision A (Rev. A) Feature Bundle

7-1 Protocols with Rev. A Physical Layer Feature: New and Modified Service Measurements.. 7-157-15

7-2 Inter and Intra-Radio Network Controller (RNC) Handoff Enhancement Feature: New ServiceMeasurements....................................................................................................................................................... 7-287-28

List of tables

...................................................................................................................................................................................................................................

xvi Alcatel-Lucent - ProprietarySee notice on first page

401-614-413Issue 5, May 2008

8 Enhanced Data Only Revision A (DOrA) Application Quality of Service (QoS) Features

8-1 RAN Quality of Service Enhancements for HRPD Rev. A Feature: New Service Measurements............................................................................................................................................................................ 8-258-258-25

8-2 More QoS Enhancements for the HRPD Rev. A Network: Modified Service Measurements............................................................................................................................................................................ 8-298-298-29

8-3 More QoS Enhancements for the HRPD Rev. A Network: New Service Measurements....... 8-308-30

8-4 More QoS Enhancements for the HRPD Rev. A Network: Existing Service MeasurementsPegged by Feature.............................................................................................................................................. 8-388-38

8-5 More QoS Enhancements for the HRPD Rev. A Network: Renamed Service Measurements............................................................................................................................................................................ 8-388-388-38

8-6 Data Over Signaling Protocol Feature: New Service Measurements............................................... 8-448-44

8-7 RNC sector carrier service measurements................................................................................................... 8-458-45

8-8 HCS sector carrier service measurements................................................................................................... 8-458-45

8-9 HDR sector carrier service measurements................................................................................................... 8-468-46

8-10 OHM-PageableProfileID service measurements....................................................................................... 8-488-48

8-11 OHM-PageableProfileID-PageAttempt service measurements............................................................ 8-488-48

8-12 OHM-PageableProfileID service measurements....................................................................................... 8-498-49

8-13 OHM-PageableProfileID-PageAttempt service measurements............................................................ 8-498-49

8-14 RNC-pgpf service measurements.................................................................................................................... 8-498-49

8-15 Valid Combinations for DoS Method and Paging Area Settings....................................................... 8-618-61


9-1 Related RC/V forms............................................................................................................................................. 9-109-10

9-2 Related fields in thecell2 page.................................................................................................................... 9-109-10

9-3 1xEV-DO service measurements - Data link counts............................................................................... 9-119-11

9-4 Fields to be populated in thecell2 form .................................................................................................. 9-159-15

10 EVolution Data Only (1xEV-DO) Revision A (Rev. A) Voice Over Internet Protocol (VoIP)and Application Pricing

10-1 1xEV-DO service measurements - BTS-HDR Counts......................................................................... 10-2010-20

List of tables

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


xvii

10-2 1xEV-DO service measurements - SECT-CARR-HDRC counts..................................................... 10-2010-20

10-3 1xEV-DO service measurements - SN-RNC counts............................................................................. 10-2110-21

11 Radio Network Controller (RNC) Grouping to Improve Idle Hand-off Performance

11-1 1xEV-DO service measurements - SECT-CARR-HDRC Counts.................................................... 11-1011-10

11-2 Other Service Measurement Impacts........................................................................................................... 11-1011-10

11-3 Modify Paging Parameters............................................................................................................................... 11-2011-20

11-4 Values for Auxiliary Service Node Control - 1...................................................................................... 11-2411-24

11-5 Modify Paging Parameters............................................................................................................................... 11-2711-27

11-6 Values for Auxiliary Service Node Control - 1...................................................................................... 11-3211-32

13 Intra-Radio Network Controller (RNC) Session Resource Balancing in EVolution DataOptimized (1xEV-DO)

13-1 1xEV-DO service measurements - OHM Counts..................................................................................... 13-813-8

13-2 1xEV-DO service measurements - SECT-CARR-HDRC Counts...................................................... 13-813-8

13-3 1xEV-DO service measurements - SECT-CARR-HDRC CI Counts................................................ 13-913-9


14-1 Related AAA subscriber profile attributes................................................................................................ 14-1514-15

14-2 3GPP2-Inter-User-Priority attribute format............................................................................................... 14-1514-15

14-3 Related fields in EvDO RNC FAF form................................................................................................... 14-1714-17


14-5 Related fields in Cell Site Configuration form....................................................................................... 14-2014-20

14-6 HCS service measurements............................................................................................................................. 14-2314-23

14-7 Example assignment of Inter-User Priority values................................................................................ 14-2614-26

14-8 Example of adjusting Inter-User Priority Weights to reduce impact of priorities.................... 14-2714-27

14-9 Example of adjusting Inter-User Priority Weights for specific user classes............................... 14-2814-28


15-1 Related AAA subscriber profile attributes................................................................................................ 15-1615-16

List of tables

...................................................................................................................................................................................................................................

xviii Alcatel-Lucent - ProprietarySee notice on first page

401-614-413Issue 5, May 2008

15-2 3GPP2-Inter-User-Priority attribute format............................................................................................... 15-1615-16

15-3 Lucent-VID-Home-Area attribute format″ ................................................................................................ 15-1715-17


15-5 Related fields in SN General form.............................................................................................................. 15-1915-19

15-6 Related fields in Serving Jurisdiction Main Details form.................................................................. 15-2015-20

15-7 Related fields in Serving Jurisdiction BTS Allocation Details form............................................. 15-2115-21

15-8 Objects in Serving Jurisdiction subtree...................................................................................................... 15-2215-22

15-9 Related fields in the BERoamPolTable Instance Details form......................................................... 15-2315-23

15-10 Related fields in Serving Jurisdiction RoamPolAssgn Details form.............................................. 15-2515-25

15-11 Sample Jurisdictional Policy – TreatAsLocal.......................................................................................... 15-3015-30

15-12 Sample Jurisdictional Policy – AdjustedService..................................................................................... 15-3115-31

15-13 Sample Jurisdictional Policy – StandardService..................................................................................... 15-3115-31

15-14 Sample Jurisdictional Policy – BasicService........................................................................................... 15-3215-32

15-15 Tasks permitted for OMC-RAN user account types............................................................................. 15-3315-33

List of tables

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


xix

List of figures


1-1 Service Nodes/Flexible Scheduler instance page........................................................................................ 1-91-9

1-2 BTS instance page................................................................................................................................................. 1-121-12

1-3 Service Nodes/Flexible Scheduler instance page...................................................................................... 1-161-16

1-4 BTS instance page................................................................................................................................................. 1-191-19


2-1 1xEV-DO RAN Authentication architecture................................................................................................. 2-62-6


5-1 EV-DO PCMD data delivery path.................................................................................................................. 5-125-12

5-2 Example raw data output from the OMP-FX v.2 with RUM disabled........................................... 5-485-48

5-3 Example raw data output from the OMP-FX v.2 with RUM enabled............................................ 5-485-48

5-4 Example raw data output from the OMP-FX v.2 with RUM and Flow enabled........................ 5-485-48


9-1 EVDO Network Configuration Diagram with a MLPPP........................................................................ 9-79-7

9-2 RC/V form cell2 ..................................................................................................................................................... 9-169-16


14-1 Example Application of the Inter-User Priority for Best Effort Data Applications feature.... 14-814-8

14-2 Establishment of New Data Session with Inter-User Priority........................................................... 14-1114-11

....................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


xxi

14-3 Reactivation of existing data session with IUPBEDA enabled........................................................ 14-1314-13

14-4 Snapshot of portion of EvDO RNC FAF form....................................................................................... 14-1814-18

14-5 Snapshot of portion of SN General form.................................................................................................. 14-2014-20

14-6 Snapshot of portion of Cell Site Configuration form........................................................................... 14-2214-22

14-7 Sample HCS service measurement report................................................................................................. 14-2514-25


15-1 Example Application of the Jurisdictional Priority feature.................................................................. 15-915-9

15-2 Establishment of New Data Session with Home Area Attribute..................................................... 15-1215-12

15-3 Reactivation of existing data session with JPPSUBEDA enabled.................................................. 15-1415-14

15-4 Snapshot of portion of EvDO RNC FAF form....................................................................................... 15-1915-19

15-5 Snapshot of portion of SN General form.................................................................................................. 15-2015-20

15-6 Snapshot of Serving Jurisdiction Main Details form........................................................................... 15-2115-21

15-7 Snapshot of Serving Jurisdiction BTS Allocation Details form...................................................... 15-2215-22

15-8 Snapshot of of Serving Jurisdiction subtree............................................................................................. 15-2315-23

15-9 Snapshot of of Serving Jurisdiction BERoamPolTable Details form............................................ 15-2415-24

15-10 Snapshot of Serving Jurisdiction RoamPolAssgn Details form....................................................... 15-2615-26

15-11 Example of geographic border splitting BTS service areas.............................................................. 15-2815-28

15-12 Example use of border jurisdiction.............................................................................................................. 15-2915-29

17 Backhaul Enhancement in Support of Small Packets on the Reverse and Forward Linksin 1xEV-DO

17-1 EMS SN General Screen.................................................................................................................................. 17-1617-16

17-2 OMC General Screen......................................................................................................................................... 17-1917-19

List of figures

...................................................................................................................................................................................................................................

xxii Alcatel-Lucent - ProprietarySee notice on first page

401-614-413Issue 5, May 2008

About this information productAbout this information product

Purpose

The 1xEV-DO Feature Provisioning Guide,401-614-413 is a new document forRelease 27.0 and later. It was developed based on the needs of the Service Providerwho requested all 1xEV-DO procedural information be accessible in one document. All1xEv-DO procedural features for R27.0 and later are documented in this guide.

This guide also includes all the feature information from the following 1xEV-DOFeature Description documents from earlier releases, including:

• 1xEV-DO Flexible Scheduler,401-614-400

• 1xEV-DO Radio Access Network Authentication,401-614-402

• Cell Swing Capability for 1xEV-DO,401-614-407

• 1xEV-DO Handoff Matrix (HOM) Tool and Related Features,401-614-409

• Per Call Measurement Data (PCMD) for 1xEV-DO,401-614-410

• HRPD RNC Performance and Capacity Improvements,401-614-412

Intended audience

This document is designed for system administrators and other technical personnel whoperform operations, administration, and maintenance (OA&M) on the elements of aCDMA2000® 1xEV-DOwireless networks.

To obtain technical support, documentation, and training or submit feedback

The Online Customer Support (OLCS) web site (http://support.lucent.com/) providesaccess to technical support, related documentation, related training, and feedback tools.The site also provides account registration for new users.

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008,


xxiii

http://support.lucent.com/

Reason for reissue

This document supports numerous 1xEV-DO features and their releases. New releases,software updates or Modification Requests (MRs) introduce new features or updatesreflected inTable 1, “Reason for Reissue” (p. xxiv)listed below. For content andchanges of previous issues see“History of revisions” (p. xxxiii):

Table 1 Reason for Reissue

FeatureIdentification (FID)

Number

Base Release/SURelease

Chapter Number Issue

Addition ofOMC-RANProcedures

R30 and later Multiple Chaptersthroughout thedocument

5

FID 8219.9 R30.0 and later Chapter 4 5


FID 10737.9 R30 and later Chapter 3 5

FID 12102.5 R29.0 and later Chapter 17(new)(wasdocument401-614-416)

5

FID 12102.14 R29.0 and later Chapter 17 (new)(was document401-614-416)

5

FID 12885.1 R30.0 and later Chapter 3, seeFeature Interactions

5



FID 12780.3 R30.0 and later Chapter 16 (new) 5

FID 13181.0* R30.0 and later Multiple Chaptersthroughout thedocument

5

*Impact of Support for up to 999 CDMA/3G-1x cells (FID 13181.0): The maximumnumber of cells that may be supported in a system is dependent upon which (if any)cell-numbering feature is implemented in that specific system. The base system allowsfor a maximum of 222 cells. Cell-numbering features may be implemented to increasethis maximum. Therefore, this document has been updated to generalize anyinformation about the maximum number of cells supported in a system, rather thanstate a possible limit (such as, 384 or 600, etc).


...................................................................................................................................................................................................................................

xxiv Alcatel-Lucent - ProprietarySee notice on first page

401-614-413Issue 5, May 2008

,

Chapter distribution

This document contains the following CDMA 3G-1x EVolution Data Optimized(1xEV-DO) procedural chapters which cover the CDMA2000® 1xEV-DOnetworks.

• Chapter 1,″1xEV-DO Flexible Scheduler,″ describes the 1xEV-DO FlexibleScheduler feature, FID 8948.0.

• Chapter 2,″1xEV-DO Radio Access Network Authentication,″ describes the1xEV-DO Radio Access Network Authentication feature, FID 8103.0.

• Chapter 3,″Cell Swing Capability for 1xEV-DO,″ describes the Cell SwingCapability for 1xEV-DO features:

– Cell Swing Capability for 1xEV-DO, FID 12188.0

– Cell Swing Capability for 1xEV-DO, FID 12188.1

– Privilege Minimization and Restrict Root Login in 1xEV-DO RNC APs , FID10737.9

• Chapter 4,″1xEV-DO Handoff Matrix (HOM) Tool and Related Features,″ providesservice providers with important information to assist in 1xEV-DO neighbor listadjustments needed to improve handoff performance. Related features include:

– 1xEV-DO Handoff Matrix (HOM) Tool, FID 12146.0

– BC0/BC1 Dual Band 1xEV-DO, FID 8219.7

– Dual Band 1xEV-DO Support for Coverage Differences, FID 8219.9

– Support for Multiple 1xEV-DO Carriers - Inter-frequency Handoff (IFHO), FID8219.11

– Six Sector Modular Cell 4.0B with Mixed 1x and 1xEV-DO, FID 8882.0

• Chapter 5,″Per Call Measurement Data (PCMD) for 1xEV-DO,″ describes the PerCall Measurement Data (PCMD) for 1xEV-DO and Enhancements features:

– CDMA2000 1xEV-DO Feature Provisioning GuidePCMD for 1xEV-DO, FID12269.0

– Enhancements to EVDO Per Call Service Measurements, FID 12269.2

– EVDO Service Measurements Enhancement - Phase 2, FID 12370.1

– Customer Critical Performance Measurements and Translations - Phase 3, FID12766.2

• Chapter 6,″High Rate Packet Data Radio Network Controller (HRPD RNC)Performance and Capacity Improvements,″ feature, FID 10607.3.

• Chapter 7,″1xEV-DO Rev. A Basic Feature Bundle,″ describes the following basic1xEV-DO Rev. A feature bundles and related features:Basic Rev. A Feature Bundle:

– Enhanced Reverse and Forward Links using Enhanced MAC Protocols withRev. A Subtype 2 Physical Layer, FID 12078.2

– Generic Attribute Update Protocol (GAUP) for Dynamic Parameters Update,FID 12078.3


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008,


xxv

– HRPD Rev. A Support on Modular Cell 1-3 BTS Platforms using SB-EVMm,FID 12078.4

– HRPD Rev. A Support on Modular Cell 4.0 BTS Platforms using SB-EVM,FID 12078.5

– Inter and Intra-RNC Handoff Enhancement, D 12078.7

• Chapter 8,″1xEV-DO Enhanced Rev. A Feature Bundle,″ describes the followingenhanced 1xEV-DO Rev. A feature bundle and related features using the 1xEV-DOEnhanced Rev. A (DOrA) application license:

– Application Based Quality of Service (QoS) Support for HRPD Rev. A, FID12078.9

– RAN Quality of Service Enhancements for HRPD Rev. A, FID 12078.10

– More Quality of Service (QoS) Enhancements for the High Rate Packet Data(HRPD) Revision A (Rev. A) Network FID 12078.11

– Data Over Signaling Protocol, FID 12078.12

– Enhanced Idle State Protocol, FID 12078.13

– 1xEV-DO Revision A (Rev. A): Data Over Signaling Protocol - FL FID12078.36

– Basic PTT on HRPD-A, FID 12184.1.

– HRPD PTT Paging Enhancements, FID 12184.5

– Push-to-Talk (PTT) Enhancements FID 12184.7

– Reference to Backhaul Enhancement in Support of Small Packets on theReverse and Forward Links in 1xEV-DO. Detailed feature description of FID12102.5 can be found in Chapter 17 of this document..

• Chapter 9,″CDMA 3G-1x EVolution Data Optimized (1xEV-DO) Backhaul withMulti Link Point-to-Point Protocol (MLPPP) at Layer 2 Over T1/E1″, describesFID 12304.11.

• Chapter 10, “CDMA 3G-1x EVolution Data Optimized (1xEV-DO) Only RevisionA (Rev. A) Voice Over Internet Protocol (VoIP) and Application Pricing″, describesthe following features:

– 1xEV-DO Only Rev. A Voice Over Internet Protocol (VoIP) and ApplicationPricing, FID 12905.0

– 1xEV-DO Rev. A Application Pricing Enhancements FID 12905.1

• Chapter 11, “Radio Network Controller (RNC) Grouping to Improve Idle Hand-offPerformance″, describes FID 12456.1.


...................................................................................................................................................................................................................................

xxvi Alcatel-Lucent - ProprietarySee notice on first page

401-614-413Issue 5, May 2008

,

• Chapter 12, “EVolution Data Optimized (1xEV-DO) Performance Monitoring ToolsEnhancements″, describes the following features:

– 1xEV-DO Performance Monitoring Tools Enhancements, FID 9253.1

– 1xEV-DO Tool Interface between Operations and Maintenance Platform forFlexent (OMP-FX) and 1xEV-DO Radio Network Controller (RNC), FID9253.2

– Access Terminal (AT) Trace Enhancement for Customer Use, FID 9253.3Updates for post R28.0 General Availability (GA) and later. Added this new FID9253.1 per customer concerns that a portion of a 1xEV-DO R27 feature wasmissed. Issue was resolved in (AR1-1652484).

• Chapter 13, “Intra-Radio Network Controller (RNC) Session Resource Balancing in1xEV-DO”, describes FID 12458.0.

• Chapter 14, “Inter-User Priority for Best Effort Data Applications (IUPBEDA)”,describes FID 12171.4.

• Chapter 15, “Jurisdictional Priority for Public Safety Users of Best Effort DataApplications (JPPSUBEDA)”, describes FID 12171.5.

• Chapter 16, “Universal Traffic Processor (UTP) Protocol Acceleration inHardware”, describes FID 12780.3.

• Chapter 17, “Backhaul Enhancement in Support of Small Packets on the Reverseand Forward Links in 1xEV-DO”, describes the following features:

– Backhaul Enhancement in Support of Small Packets on the Reverse Link in1xEV-DO (Phase 1a) FID 12102.5

– Backhaul Enhancement in Support of Small Packets on the Forward Link in1xEV-DO (Phase 1b) FID 12102.14

• The “Glossary” defines technical terms and abbreviations that are used in thisdocument.

Operations and Maintenance Center - Radio Access Network (OMC-RAN) equivalents tocommon Element Management System (EMS) screens

All the information that was available about EV-DO network elements on EMS isavailable on the OMC-RAN Graphical User Interface (GUI). However, there is not aone-to-one correspondence between equivalent views in EMS and on the OMC-RAN.Listed here are the most commonly-used ways to find certain information on EMS andwhere to find the equivalent information on the OMC-RAN. Remember that as apowerful Windows-based application, the OMC-RAN often has several different waysto access the same data. This“Operations and Maintenance Center - Radio AccessNetwork (OMC-RAN) equivalents to common Element Management System (EMS)screens” (p. xxviii)shows one way to access the most commonly used information.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008,


xxvii

For a detailed reference table mapping individual EMS parameters to individualOMC-RAN parameters, see the CDMA2000® 1xEV-DO Configurations ParametersGuide,401-614-324.

For this function in EMS you go to... on the OMC-RAN you go to...

Starting out OMP Web screen Desktop

Monitoring all BTSsin a Service Node

Base TransceiverSystems (BTSs) screen

The following places

• CellSiteTable under the DOObject (lists all DO cells).Look at theCsCabTable andSectorTable and other tablesfor more information

• For CDMA BTSs that areDO-capable, theBTS Overview

• BTS group in the NetworkManager tree under the ORCAGroup Note that DO-capableBTSs have a blue icon besidesthem that says “DO”.

Finding alarms on aBTS

Base TransceiverSystems (BTSs) screen

The following places

• Alarm Manager

• CellSiteTable under the DOObject (lists all DO cells)

• For CDMA BTSs that areDO-capable, theBTS Overview

• Go to the Detail view screenfor an individual networkelement

• BTS group in the NetworkManager tree under the ORCAGroup. Note that DO-capableBTSs have a blue icon besidesthem that says “DO”.

Note that the Highest SeverityAlarm (HSA) for each networkelement shows up as an icon inthe NM tree.

Monitoring anindividual

Drill down from the BaseTransceiver Systems(BTSs) screen

Use theNE view Detail viewscreen for the network element.


...................................................................................................................................................................................................................................

xxviii Alcatel-Lucent - ProprietarySee notice on first page

401-614-413Issue 5, May 2008

,



Monitoring allEV-DO RNCs in aService Node

Start with theCDMA2000EV-DO Radio NetworkControllers (EV-DO RNCs)screen and drill down tothe AP Summary

The following places:

• Look at theRackview (Notethat in OMC-RAN Release28.0, SU 2, both TPs in eachdrawer will show up on theRackview ). Right-click or runyour cursor over a networkelement to get maintenancestates. Right-click and selectDetails from the drop downmenu to get detailedinformation

• On each EV-DO DO-RNC,expand theHDRFrame Table inthe NE view

• On each EV-DODO-RNCHDRFrame Table, right clickand selectAP Table from thedrop-down menu.

Monitoring anindividual EV-DORNC

Drill down from the APSummary View

Find the DO Object, the namewith a lowercase “do” in themiddle:

• Drill down to the networkelement view by clicking onthe right arrow on the HMtree, expand the DO Object inthe network element view, thendouble click on the AP Tableand TP Table .

Working withconfiguration data fora BTS

Configuration Data tables Go to the following places:

• Go to theCellSiteTable underthe DO Object, then right-clickto do Expand ALL from theCellSiteTable , then doubleclick on any network elementor table to get a Detail viewscreen


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008,


xxix



Working withconfiguration data fora Service Node

Configuration Data tables Go to the following places:

• In R29 and earlier,FxApxVNE (the FxApx listed at thebottom of the ORCA Group)gives a global SN general viewfor all EV-DO RNCs on oneFxApx. On FxApx VNE,proceed to the networkelement view, highlight thenetwork element, right click onDetails.

• In R30 and later,x:R30 GlobalConfig DO wherex is theFxApx for the ORCA Group)gives a global SN general viewfor all EV-DO RNCs on oneFxApx. UseR30 Global ConfigDO, proceed to the networkelement view, highlight thenetwork element, right click onDetails .

• Use System CLI to enterconfiguration commands.

Working withconfiguration datasingle frame

Drill down from theConfiguration Datatables

Go to the following places:

• Go to the HDR frame Detailview screen

• Use System CLI to enterconfiguration commands.

See Appendix 7 ofAlcatel-Lucent 9271 EV-DO Radio Network Controller,401-614-102 for basic information in order to:

• understand the OMC-RAN,

• understand the layout of EV-DO information on the OMC-RAN, and

• provisioning activities on EV-DO network and elements from the OMC-RAN.

For more information about the different 1xEV-DO OA&M interfaces that are used inperforming OA&M tasks on the EV-DO controller and it’s managed resources,including the purpose of each interface and how to access it, seeAlcatel-Lucent 9271EV-DO Radio Network Controller,401-614-102, Chapter 3,″User Interfaces″.


...................................................................................................................................................................................................................................

xxx Alcatel-Lucent - ProprietarySee notice on first page

401-614-413Issue 5, May 2008

,

Conventions used

The following conventions are used throughout this document:

Typographic conventions

This document presents different types of information in different typefaces toemphasize the nature of the information:

• Literal user input.Keystrokes that you are to enter character by character exactlyas shown in the text appear inmonospace bold type. For example:Enter the following command:apappsconfig

• Variable user input.Input values that vary from one execution or instance toanother appear inmonospace bold italic type. For example:cd directoryWhere:directory = the directory to which to change.

• Literal system output.The names of files, directories, forms, messages, and otherinformation that a system outputs exactly as shown in the text appear inmonospace regular type. For example:RST SPA=cnam REQUEST ACKNOWLEDGED

• Variable system output.Values that vary from one instance to another in systemoutput appear inmonospace italic type. For example:RST SPA=SPA_NAME REQUEST COMPLETEDWhere:SPA_NAME = the name of the Service Package Application (SPA) that is successfullyrestored.

• The names of keys on a terminal keyboard are indicated bybold letters. Forexample:Press theF4 (Enter Query) function key.

• The Ctrl (Control) key is signified by the carat (^ ) symbol. When the symbolprecedes the name of another key (as in^e), press theCrtl key and the other keysimultaneously.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008,


xxxi

Actions for user input

In this document, the following words specify what action you should perform to inputdata or execute commands:

• The wordentermeans to key in the specified keystrokes (such as a command) andthen press theEnter or Return key. For example:Enter the following command:apappconfig

• The wordpressmeans to push down the specified key or keys on the keyboard.For example:Press theF4 (Enter Query) function key.

• The wordtypemeans to key in the specified keystrokes (such as a value in thefield of a form) without pressing theEnter or Return key. For example:In the IP address field, type the IP address of the host server.

Related information

The following documents are either referenced in this document or provide additionalinformation that relates 1xEV-DO:

• System Capacity Monitoring & Engineering Guidelines (SCME),401-610-009

• Wireless Networks Input Messages,401-610-055

• Wireless Networks Output Messages,401-610-057

• Automatic Message Accounting (AMA) Format Descriptions,401-610-133

• Wireless Networks Service Measurements.,401-610-135,

• Inter-MSC Cell Swing,401-612-150

• CDMA2000® 1xEV-DO RAS Planning and Implementation Guide,401-614-101

• Alcatel-Lucent 9271 EV-DO Radio Network Controller Operations, Administration,and Maintenance (OA&M),401-614-102

• CDMA2000® 1xEV-DO Configurations Parameters Guide,401-614-324

• CDMA 2000® 1xEV-DO EMS Configuration Management Bulk Provisioning,401-614-325

• CDMA2000® 1xEV-DO Service Measurements,401-614-326

• 5ESS® Digital Cellular Switch (DCS) documents

– Hardware Change Procedures: Growth,235-105-231

– Hardware Change Procedures: Degrowth,235-105-331

– Packet Switch Wireless Applications Operations, Administration, andMaintenance (OA&M),235-200-100,

• Wireless Networks Element Management System (EMS) User’s Guide,401-710-110

• Mobility Manager Compact System Capacity Monitoring and EngineeringGuidelines,401-710-729


...................................................................................................................................................................................................................................

xxxii Alcatel-Lucent - ProprietarySee notice on first page

401-614-413Issue 5, May 2008

,

History of revisions

This is a history of the reissues for this document.

Issue 4.1

The following list summarizes the major changes or additions in this document for1xEV-DO Release 29.1:

• Introduced FID 12171.4 in new chapter 14.

• Introduced FID 12171.5 in new chapter 15.

• Introduced FID 12458.0 in new Chapter 13.

Issue 4


• Introduced FIDs 12102.5, 12078.11, 12078.36, and 12184.11 in existing Chapter 8.

• Introduced FID 12905.1 in existing Chapter 10.


• Full feature description of FID 12102.5 was introduced in new document,BackhaulEnhancement in Support of Small Packets on the Reverse and Forward Links in1xEV-DO,401-614-416.

• Moved FID 9253.2 from existing Chapter 4 to existing Chapter 12.

Issue 3



Issue 2.2



Issue 2.1


• Updates for post R28.0 General Availability (GA) and later to existing Chapter 5,PCDM table updates.

• Updates for post R28.0 General Availability (GA) and later to existing Chapter 8,FID 12078.13 update (T_page1 parameter) value is″off″.

• Updates for post R28.0 General Availability (GA) and later to existing Chapter 11per updates to FID 12456.1.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008,


xxxiii

Issue 2



• Introduced FIDs 12078.9, 12078.10, 12078.12, and 12078.13 in new Chapter 8.

• Introduced FIDs 12184.1 and 12184.5 in new Chapter 8.




Issue 1


• Moved document 401-614-400, into 401-614-413 as new Chapter 1 (FID 8948.0).


• Moved document 401-614-407, into 401-614-413 as new Chapter 3 (FIDs 12188.0and 12188.1).

• Moved document 401-614-409, into 401-614-413 as new Chapter 4 (FIDs 12146.0,8219.11, and 8882.0).

• Moved document 401-614-410, into 401-614-413 as new Chapter 5 (FIDs 12269.0and 12269.2).


• Introduced FIDs 12078.2, 12078.3, 12078.4, 12078.5, and 12078.7 in new Chapter7.

How to comment

To comment on this information product, go to theOnline Comment Form(http://www.lucent-info.com/comments/enus/) or e-mail your comments to theComments Hotline ([email protected]).


...................................................................................................................................................................................................................................

xxxiv Alcatel-Lucent - ProprietarySee notice on first page

401-614-413Issue 5, May 2008

,

http://www.lucent-info.com/comments/enus/

http://www.lucent-info.com/comments/enus/

1 1CDMA 3G-1x EVolution DataOptimized (1xEV-DO) FlexibleScheduler

Overview...................................................................................................................................................................................................................................

Purpose

This optional feature description describes the CDMA 3G-1x EVolution DataOptimized (1xEV-DO) Flexible Scheduler optional feature in wireless networks.

Feature summary

The Flexible Scheduler feature allows the selection of a scheduling algorithm to beused for forward link data.

Feature Identifier (FID)

The Feature Identifier (FID) of the of the Flexible Scheduler feature is FID 8948.0.

Impacts on user interfaces

The Flexible Scheduler affects the user interfaces that are listed in the following table.

User interface Feature impact

Element Management System(EMS)

See“Impacts on the Element Management System(EMS)” (p. 1-8).

Operations and MaintenanceCenter - Radio Access Network(OMC-RAN)

See“Impacts on the Operations and MaintenanceCenter - Radio Access Network (OMC-RAN)”(p. 1-16).

Service measurements See“Impacts on service measurements” (p. 1-23).

Automatic Message Accounting(AMA) subsystem

None

Technician Interface (TI)(input/output messages)

None

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


1-1



Contents

Availability 1-3

Prerequisites 1-4

Feature description 1-5

Feature interactions 1-7

Impacts on the Element Management System (EMS) 1-8

Impacts on the Operations and Maintenance Center - Radio AccessNetwork (OMC-RAN)

1-16

Impacts on service measurements 1-23

Implementing the feature 1-24

Activating the feature 1-25

Configuring the Flexible Scheduler feature for Service Nodes 1-26

Configuring the Flexible Scheduler feature for base stations 1-28

CDMA 3G-1x EVolution Data Optimized (1xEV-DO)Flexible Scheduler

Overview

...................................................................................................................................................................................................................................

1-2 Alcatel-Lucent - ProprietarySee notice on first page

401-614-413Issue 5, May 2008


Availability...................................................................................................................................................................................................................................

Release availability

The Flexible Scheduler feature is available in Release 22.0 and later.

Market availability

The Flexible Scheduler feature is available in all regions.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


1-3

Prerequisites...................................................................................................................................................................................................................................

Introduction

The Flexible Scheduler feature has the following prerequisites.

Supported technologies

The Flexible Scheduler feature is supported in the following air-interface technologies:

• CDMA cellular

• CDMA PCS

Software requirements

The Flexible Scheduler feature requires 1xEV-DO Release 22.0 or later.

Hardware requirements

The Flexible Scheduler feature requires no hardware beyond the standard hardware in aCDMA2000® 1xEV-DO network.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Feature description...................................................................................................................................................................................................................................

Introduction

The following information describes the functionality, benefits, and operation of theFlexible Scheduler feature.

Functionality

The Flexible Scheduler feature allows the provider to select from four different forwardlink scheduler algorithms:

• Proportional Fair (PF)The default choice and the algorithm in use before this feature was available.

• Min/Max Rate ControlThis algorithm allows the provider to control the minimum and maximum averagethroughput rate for the user.

• G-FairThis algorithm allows control of one user’s thoughput in relation to other users’throughput.

• Random Activity FactorThis algorithm is used with the Test Application feature for supporting MinimumPerformance Standard testing.

Benefits

The Flexible Scheduler feature allows providers to match the forward link scheduleralgorithm to market needs. This feature gives providers more control over users’throughput based on different service classes.

• User throughput controlThe 1x-EV-DO system can guarantee a user’s minimum throughput. It can alsorestrict a user’s maximum throughput so that the user can have a relatively steadydata throughput experience.

• Hooks for future Quality of Service needsThe Flexible Scheduler Feature provides hooks to support Quality of Service (QoS)needs in the future.

How the feature operates

The forward link consists of a single data channel only. At any one time, only oneuser’s data is being transmitted. The Access Terminal (AT) requests the best servingsector and the data rate through the Data Rate Control (DRC) channel. (The DRC isthe data rate that the AT requests for service. The better the RF conditions, the better


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


1-5

the DRC. The DRC rates that are supported on the forward link are 2457.5 kbps,1843.2 kbps, 1228.8 kbps, 921.6 kbps, 614.4 kbps, 307.2 kbps, 153.6 kbps, 76.8 kbps,and 38.4 kbps.)

The Radio Access Network (RAN) transmits packet data at the rate requested by theAT. When multiple users are requesting data, a scheduler uses the DRCs received todetermine the order and the data rate at which to transmit to users on the forward link.

The Flexible Scheduler attempts to take advantage of the temporal variations in thechannel by scheduling transmissions to ATs during the time periods where the AT seesstrong signal levels. The scheduler sends data to the mobile that has the highestDRC/R, where DRC is the rate requested by the mobile in a given slot, and R is theaverage rate transmitted to the mobile over a window of time. This way each user isserved in slots in which its requested rate is closer to the peak, as compared withrecent requests.

The four Flexible Scheduler algorithms supported are

• PF (default)

• Min/Max Rate Control

• G-Fair

• Random Activity Factor

These algorithms and their associated parameters are set on the Service Nodes/FlexibleScheduler instance page in the Element Management System (EMS) ConfigurationManagement set of pages. The Flexible Scheduler meets the throughput requirementsfor the algorithm that has been chosen.


Feature description

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Feature interactions...................................................................................................................................................................................................................................

Introduction

The Flexible Scheduler feature does not interact with other features.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


1-7

Impacts on the Element Management System (EMS)...................................................................................................................................................................................................................................

Configuration Management pages

The Flexible Scheduler feature affects these Configuration Management pages in theElement Management System:

• Service Nodes/Flexible Scheduler instance page (new page)

• Base Transceiver Station (BTS) instance page (additional parameters)

The Flexible Schedule Feature can be configured at the service node level for all basestations in that service node. If the Flexible Scheduler feature is configured at the basestation level using the BTS instance page, those settings take precedence over settingsat the service node level. (The settings at the service node level take precedence forany Flexible Scheduler parameters which are blank, however.)

For detailed procedures, see CDMA2000® 1xEV-DO Radio Access System Planningand Implementation Guide,401-614-101.

For detailed procedures regarding the impact of OMC-RAN becoming a mandatoryplatform for EV-DO in R29.1 and later, see Appendix 7 ofAlcatel-Lucent 9271 EV-DORadio Network Controller,401-614-102.

Service Nodes/Flexible Scheduler instance page

The Flexible Scheduler feature can be configured for all base stations in a service nodethrough the Service Nodes/Flexible Scheduler instance page.

Important! If the Flexible Scheduler feature for a base station is configured at thebase station level using the BTS instance page, those settings take precedence overthe settings at the service node level.

The Service Nodes/Flexible Scheduler instance page is shown in the following figure.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

An asterisk (*) by a parameter indicates that parameter is required. A greenexclamation point (!) by a parameter indicates that parameter is dynamicallyupdateable. If you change the value of the dynamically parameter, you do not have toreboot the application for the new value to take effect.

Important! All Flexible Scheduler parameters except for Flexible Scheduler Choice(FSC) are dynamically updateable. If you change the FSC parameter, you have toreset the modem for the new FSC to take effect.

The configuration parameters on the Service Node/Flexible Scheduler instance page aredescribed inTable 1-1, “Flexible Scheduler parameters” (p. 1-9).

Table 1-1 Flexible Scheduler parameters

Parameter name Description Allowed values

Flexible SchedulerChoice

The FSC specifies the scheduleralgorithm to be used on forwardlink transmission.

This parameter is notdynamically updateable. If youchange the FSC parameter, youhave to reset the modem for thenew FSC to take effect.

PF (default)

Min/Max Rate ControlG-Fair

Random Activity Factor

Figure 1-1 Service Nodes/Flexible Scheduler instance page


Impacts on the Element Management System (EMS)

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


1-9

Table 1-1 Flexible Scheduler parameters (continued)


Minimum ThroughputTarget (Rmin)

When the FSC is Min/Max RateControl, this parameter indicatesthe minimum user throughput thescheduler should try to achievefor any individual user.

0 to 64 kbps in steps of4k

Default = 0

Restrict ThroughputAfter Reaching Rmax

When the FSC is Min/Max RateControl, this parameter indicatesif the scheduler should strictlyenforce the maximum throughputbound Rmax.

Non-strict enforcement allowssome users’ throughputs to goabove Rmax, but only in caseswhen all users’ throughputs arealready at or above Rmax.

Strict enforcement caps eachuser’s throughput at Rmax at alltimes, even if this requires thattimeslots would be underused.

Unspecified

Non-strict (default)Strict

Out-of-Range

G-Fair Control Function If the FSC is set to G-Fair, thisparameter indicates the h()function to be used by thescheduler. Every h() function hasa different expected throughput.

Unspecified

h(x)=x(proportional_fair)

(default)

h(x)=2*x

h(x)=4*x

Out-of-Range

Min/Max Rate ControlDirection

If the FSC is set to Min/MaxRate Control, the directionparameter indicates the scheduleralgorithm optimization directionafter the minimum threshold ismet for all users in the sector.

PFMR = Proportional Fair aftermeeting Minimum User RateTarget

MTMR = Maximum SectorThroughput after meetingMinimum User Rate Target

Unspecified

PFMR (default)

MTMR

Out-of-Range



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008



Maximum ThroughputThreshold (Rmax)

When the FSC is set to Min/MaxControl, this parameter indicatesthe desired bound on themaximum user throughput. Thisbound is enforced non-strictly orstrictly, depending on the entryfor the parameter″RestrictThroughput After ReachingRmax.″

The Rmax must be at least twotimes larger than Rmin.

2457.6 (default)

9.6 to 2457.6 kbps insteps of 4.8 kbps

Rmin Hog PreventionFactor

When the FSC is set to Min/MaxControl, this parameter indicatesthe prevention factor used in thealgorithm to prevent a bad RFuser from hogging the systemresources when Rmin is beingenforced.

Off (default)

1.5 to 2.5 in steps of0.1

Out-of-Range

BTS instance page

The Flexible Scheduler feature adds several configuration parameters to the BTSinstance page, shown in the following figure. If the Flexible Scheduler feature for abase station is configured at the base station level using the BTS instance page, thosesettings take precedence over the settings at the service node level.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


1-11


Important! All Flexible Scheduler parameters except for FSC are dynamicallyupdateable. If you change the FSC parameter, you have to reset the modem for thenew FSC to take effect.

Figure 1-2 BTS instance page



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

The Flexible Scheduler parameters on the BTS instance page are shown inTable 1-2,“Flexible Scheduler parameters on the BTS instance page” (p. 1-13).

Table 1-2 Flexible Scheduler parameters on the BTS instance page

Field name Description Allowed values




Unspecified (default)

Proportional Fair

Min/Max Rate Control

G-Fair







PFMR

MTMR

Out-of-Range





default =blank



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


1-13

Table 1-2 Flexible Scheduler parameters on the BTS instance page(continued)






Out-of-Range




default =blank






Non-strict

Strict

Out-of-Range




h(x)=2*x

h(x)=4*x

Out-of-Range



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

References

For information on how to configure the parameters for this feature, see“Configuringthe Flexible Scheduler feature for Service Nodes” (p. 1-26)in this chapter. For moreinformation about configuration parameters, see the following document:

• 1xEV-DO Configuration Parameters Guide,401-614-324



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


1-15

Impacts on the Operations and Maintenance Center - RadioAccess Network (OMC-RAN)...................................................................................................................................................................................................................................

Configuration Management pages

The Flexible Scheduler feature affects this OMC-RAN Screen:

• FxApx

For detailed procedures regarding the impact of OMC-RAN becoming a mandatoryplatform for EV-DO in R29.1 and later, see Appendix 7 ofAlcatel-Lucent 9271 EV-DORadio Network Controller OA&M,401-614-102.

FxApx OMC-RAN Screen

The Flexible Scheduler feature can be configured for all base stations in a service nodethrough the Service Nodes/Flexible Scheduler instance page.

Important! If the Flexible Scheduler feature for a base station is configured at thebase station level using the BTS instance page, those settings take precedence overthe settings at the service node level.

The Service Nodes/Flexible Scheduler instance page is shown in the following figure.


Figure 1-3 Service Nodes/Flexible Scheduler instance page


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Important! All Flexible Scheduler parameters except for Flexible Scheduler Choice(FSC) are dynamically updateable. If you change the FSC parameter, you have toreset the modem for the new FSC to take effect.

The configuration parameters on the Service Node/Flexible Scheduler instance page aredescribed inTable 1-3, “Flexible Scheduler parameters” (p. 1-17).

Table 1-3 Flexible Scheduler parameters





PF (default)

Min/Max Rate ControlG-Fair





Default = 0





Unspecified

Non-strict (default)Strict

Out-of-Range


Impacts on the Operations and Maintenance Center -Radio Access Network (OMC-RAN)

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


1-17




Unspecified


(default)

h(x)=2*x

h(x)=4*x

Out-of-Range





Unspecified

PFMR (default)

MTMR

Out-of-Range




2457.6 (default)




Off (default)


Out-of-Range



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

BTS instance page

The Flexible Scheduler feature adds several configuration parameters to the BTSinstance page, shown in the following figure. If the Flexible Scheduler feature for abase station is configured at the base station level using the BTS instance page, thosesettings take precedence over the settings at the service node level.


Important! All Flexible Scheduler parameters except for FSC are dynamicallyupdateable. If you change the FSC parameter, you have to reset the modem for thenew FSC to take effect.

Figure 1-4 BTS instance page



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


1-19

The Flexible Scheduler parameters on the BTS instance page are shown inTable 1-4,“Flexible Scheduler parameters on the BTS instance page” (p. 1-20).

Table 1-4 Flexible Scheduler parameters on the BTS instance page






Proportional Fair

Min/Max Rate Control

G-Fair







PFMR

MTMR

Out-of-Range





default =blank



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Table 1-4 Flexible Scheduler parameters on the BTS instance page(continued)






Out-of-Range




default =blank






Non-strict

Strict

Out-of-Range




h(x)=2*x

h(x)=4*x

Out-of-Range



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


1-21

References

For information on how to configure the parameters for this feature, see“Configuringthe Flexible Scheduler feature for Service Nodes” (p. 1-26)in this chapter. For moreinformation about configuration parameters, see the following document:

• 1xEV-DO Configuration Parameters Guide,401-614-324



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Impacts on service measurements...................................................................................................................................................................................................................................

Introduction

The Flexible Scheduler feature affects the following categories of servicesmeasurements:

• 1xEV-DO service measurements

1xEV-DO service measurements

The Flexible Scheduler feature adds the 1xEV-DO service measurements that areidentified in Table 1-5, “1xEV-DO service measurements” (p. 1-23).

Table 1-5 1xEV-DO service measurements

Count abbreviation Brief description

EVM_AVG_PCNT_SLOTS_BELOW_RMIN Average percentage of time slotswhen any user’s averagethroughput is below Rminthreshold for the selector/carrierby 10%

EVM_AVG_PCNT_SLOTS_ABOVE_RMAX Average percentage of time slotswhen any user’s averagethroughput is above thetranslation parameter Rmaxsetting by 10%

EVM_AVG_ELIG_USER Average number of active userseligible to be selected by thescheduler for the sector/carrier

EVM_TOTAL_BUSY_PCNT_SLOT Total number of busy slotspercentage used for user trafficdata transmission

EVM_TOTAL_PCNT_SLOTS_RMIN_HOGGING_EFFECTIVE

Total percentage of slots whenthe Rmin Hogging Preventionalgorithm takes effect

References

For detailed information about 1xEV-DO service measurements, see ,CDMA2000®1xEV-DO Service Measurements,,401-614-326.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


1-23

Implementing the feature...................................................................................................................................................................................................................................

Overview

To implement the Flexible Scheduler feature, perform the following procedures insequence:

“Activating the feature” (p. 1-25)

“Configuring the Flexible Scheduler feature for Service Nodes” (p. 1-26)

“Configuring the Flexible Scheduler feature for base stations” (p. 1-28)


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Activating the feature...................................................................................................................................................................................................................................

Purpose

This procedure activates the Flexible Scheduler feature in aCDMA2000® 1xEV-DOwireless network.



Procedure

Perform the following steps:

...................................................................................................................................................................................................

1 Ask your account executive to activate the following entry in your Feature ActivationFile (FAF):

1xEV-DO Flexible Scheduler Capacity

...................................................................................................................................................................................................

2 Proceed to“Configuring the Flexible Scheduler feature for Service Nodes” (p. 1-26).

E N D O F S T E P S...................................................................................................................................................................................................


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


1-25

Configuring the Flexible Scheduler feature for Service Nodes...................................................................................................................................................................................................................................

Purpose

This procedure provisions the Flexible Scheduler feature for Service Nodes using theEMS Service Nodes/Flexible Scheduler instance page.

Procedure


...................................................................................................................................................................................................

1 Access the Operations and Maintenance Platform (OMP) Web page according to yourlocal practices.

...................................................................................................................................................................................................

2 Click on the Configuration Data icon.

Result: The Configuration Data page appears.

...................................................................................................................................................................................................

3 Click on the link to Service Nodes.

Result: The Service Node Summary page appears.

...................................................................................................................................................................................................

4 Click on the Service Node ID for the service node you want to provision for FlexibleScheduler.

Result: The following page appears.

...................................................................................................................................................................................................

5 In the window, scroll down to Flexible Scheduler and click on that link.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Result: The Flexible Scheduler instance page appears.

...................................................................................................................................................................................................

6 Configure the Flexible Scheduler Parameters for this Service Node. Refer toTable 1-1,“Flexible Scheduler parameters” (p. 1-9)for the description and values for eachparameter.

...................................................................................................................................................................................................

7 Click the Submit button at the bottom of the page when you have finished configuringthe parameters. (Scroll down until you see the blue Submit button.)

...................................................................................................................................................................................................

8 If you wish to configure the Flexible Scheduler feature for base stations, continue withthe following procedure:“Configuring the Flexible Scheduler feature for base stations”(p. 1-28).

E N D O F S T E P S...................................................................................................................................................................................................


Configuring the Flexible Scheduler feature for ServiceNodes

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


1-27

Configuring the Flexible Scheduler feature for base stations...................................................................................................................................................................................................................................

Purpose

This procedure provisions the Flexible Scheduler feature for base stations using theEMS BTS instance page.

Procedure


...................................................................................................................................................................................................

1 If you have not already accessed the EMS Configuration Data pages in the followingprocedure, do so as follows:

• Access the OMP Web page according to your local practices.

• Click on the Configuration Data icon.

...................................................................................................................................................................................................

2 In the column of blue navigation buttons on the left side of this page, click on BTSs.

Result: The BTS container page appears.

...................................................................................................................................................................................................

3 Using filters if needed, access the BTS instance page for the BTSs you want toconfigure.

Important! You can set up different schedulers for different base stations if youwish. Keep in mind that any base station value takes precedence over the servicenode value unless the base station value is blank. In that case, the service nodevalue is used.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Result: A BTS instance page appears.

...................................................................................................................................................................................................

4 Configure the Flexible Scheduler Parameters for this base station. Refer toTable 1-4,“Flexible Scheduler parameters on the BTS instance page” (p. 1-20)for the descriptionand values for each parameter related to this feature.

...................................................................................................................................................................................................

5 Click the Submit button at the bottom of the page when you have finished configuringthe Flexible Scheduling parameters on this page.

E N D O F S T E P S...................................................................................................................................................................................................


Configuring the Flexible Scheduler feature for basestations

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


1-29

2 2CDMA 3G-1x EVolution DataOptimized (1xEV-DO) RadioAccess Network Authentication(RAN)

Overview...................................................................................................................................................................................................................................

Purpose

This chapter describes the CDMA 3G-1x Evolution Data Optimized (1xEV-DO) RadioAccess Network (RAN) Authentication feature inCDMA2000® 1xEV-DO networks.

Feature summary

The 1xEV-DO RAN Authentication feature allows wireless service providers to verifythat an Access Terminal (AT) is a legitimate user of the service.


A unique FID is assigned to each feature. The FID of the 1xEV-DO RANAuthentication feature is FID 8103.0.


The 1xEV-DO RAN Authentication affects the user interfaces that are listed in thefollowing table.


Element ManagementSystem (EMS)

See“Implementing the feature” (p. 2-9)

Operations andMaintenance Center -Radio Access Network(OMC-RAN)

For information on configuring the OMC-RAN, see“Implementing the feature” (p. 2-9)

Service measurements See“Impacts on service measurements” (p. 2-8).

Automatic MessageAccounting (AMA)subsystem

The RAN Authentication feature allows for retrieval of theInternational Mobile Station Identity (IMSI) assigned to theAccess Terminal (AT). This enables IMSI-based billing.

....................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


2-1


Technician Interface(TI) (input/outputmessages)

None



Contents

Availability 2-3

Prerequisites 2-4





Activating the Feature 2-10

Configuring the feature using EMS 2-11

Provisioning the Access Terminal 2-16

Provisioning the RAN AAA server 2-17

Provisioning the route for RAN AAA on the TP 2-18

CDMA 3G-1x EVolution Data Optimized (1xEV-DO) RadioAccess Network Authentication (RAN)

Overview

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Availability...................................................................................................................................................................................................................................


The 1xEV-DO RAN Authentication feature is available in Release 22 and later.

Market availability

The 1xEV-DO RAN Authentication feature is available in all regions.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


2-3

Prerequisites...................................................................................................................................................................................................................................

Introduction

The 1xEV-DO RAN Authentication feature has the following prerequisites.


The 1xEV-DO RAN Authentication feature is supported in the following air-interfacetechnologies:

• CDMA2000® 1xEV-DO


The 1xEV-DO RAN Authentication feature requires Release 22 or later. The 1xEV-DORAN Authentication feature is not dependent on other features.


The 1xEV-DO RAN Authentication feature requires the standard hardware in aCDMA2000® 1xEV-DO network including at least one RADIUS Accounting,Authentication, and Authorization (AAA) server.

RAN AAA application can co-exist in the same platform with PDSN AAA. However,having a separate platform for RAN AAA is recommended. Having the RAN AAA andthe PDSN AAA application on separate platforms has these benefits:

• If the AAA server crashes or needs to be taken out of service and they are on thesame platform, both the PDSN AAA functions and the RAN AAA functions areimpacted. When the PDSN function is impacted, there is no way to make1xEV-DO calls on the system. If the RAN AAA and the PDSN AAA applicationsare kept separate, the service provider could still service 1xEV-DO calls bydisabling the RAN functionality from the EMS temporarily.

• Internet Protocol (IP) network management and growth become more manageable.

• Subscriber Provisioning can be done independently for RAN AAA and PDSN AAAby different provisioning personnel. This keeps AT information more secure.

Interface requirements

This feature requires a 1xEV-DO A12 software interface on the AAA.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Introduction

The following information describes the functionality, benefits, and operation of the1xEV-DO RAN Authentication feature. This feature is implemented as defined inTIA/EIA/IS-878 standards.

Functionality

The 1xEV-DO RAN Authentication feature allows authentication of AT devices. TheAT device authentication is separate from the user authentication performed at thePacket Data Serving Node-Accounting, Authentication and Authorization server(PDSN-AAA) after the Point-to-Point Protocol (PPP) link to the PDSN is established.

Benefits

The 1xEV-DO RAN Authentication feature provides the following benefits:

• With this feature, the provider can verify that an AT is a legitimate user of theservice.

• When a Wireless Service Provider (WSP) does not provide the Internet ServiceProvider (ISP) function and does not own the PDSN-AAA, this feature provides away of provisioning and controlling access to the network via an additional AAAowned by the WSP.

• This feature provides a way to obtain the Mobile Node Identifier (MN-ID),Equipment Serial Number (ESN), and Intelligent Network (IN) information. Thisinformation can be used for billing customers.


Figure 2-1, “1xEV-DO RAN Authentication architecture” (p. 2-6)shows the A12-AAAserver as a logical entity without implying specific location or implementation. There isone A12 connection to the A12-AAA on the 1xEV-DO RNC. It is the operator’s choiceto have a centralized A12-AAA serving the entire 1xEV-DO network with multiple1xEV-DO RNCs or having a network of A12-AAA servers interconnected. It is also animplementation choice to have the A12-AAA and the PDSN-AAA running as softwareapplications collocated on the same hardware platform. A maximum of two RAN AAAservers can be connected to the 1xEV-DO network.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


2-5

The service provider has a more secure access network once the RAN Authenticationis implemented. Once the feature is implemented, there are two steps to gaining accessto the 1xEV-DO network. First, the RAN Authentication capability authenticates theaccess device, then the PDSN AAA does a user level authentication.

RAN Authentication ensures that 1xEV-DO resources are better utilized, since all RNCresources are released once RAN authentication is unsuccessful. Without this feature,RNC resources could be held onto by an unauthorized subscriber trying gain accessusing the user name/password authentication from the PDSN AAA.

This feature should be considered for deployment at the beginning of 1xEV-DOdeployment. Otherwise, the service provider must recall all 1xEV-DO ATs to programthe CHAP login and password. ATs without the CHAP login and password cannotmake 1xEV-DO calls once RAN Authentication is enabled.

Subscriber perspective

The subscriber does not have to do anything for RAN authentication. All RANparameters are provisioned by the service provider.

When the subscriber initiates a 1xEV-DO call, RAN authentication is attempted first. Ifthis is successful, PDSN Authentication is attempted. If RAN Authentication fails, thesubscriber receives an error on the 1xEV-DO dial-up screen.

Figure 2-1 1xEV-DO RAN Authentication architecture


Feature description

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Introduction

There are no feature interactions for this feature.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


2-7


Introduction

The 1xEV-DO RAN Authentication feature affects the following categories of servicesmeasurements:

• 1xEV-DO service measurements

1xEV-DO service measurements

The 1xEV-DO RAN Authentication feature introduces the RAN Authentication countsidentified in Table 2-1, “1xEV-DO service measurements” (p. 2-8).

Table 2-1 1xEV-DO service measurements

Count abbreviation Count name

RAN_AUTH_TOTAL_ATTMPT Total RAN AuthenticationAttempts

RAN_AUTH_SUCCESSFUL_ATTMPT Successful RAN AuthenticationAttempts

RAN_AUTH_FAILURE_AAA_REJECT_RSP RAN Authentication Rejections

RAN_AUTH_FAILURES_STREAM_SELECTION_FAILED

RAN Authentication StreamSelection Failures

RAN_AUTH_FAILURES_LCP_RELATED_PPP_EST_FAILED

RAN AuthenticationConfigure-Ack Related PPPEstablishment Failures

RAN_AUTH_FAILURES_CONFIGURE_NAK_PPP_EST_FAILED

RAN AuthenticationConfigure-NAK Related PPPEstablishment Failures

RAN_AUTH_INVALID_AT_CONFIGURE_REQ_PPP_EST_FAILED

RAN Authentication Invalid APConfiguration Request PPPEstablishment Failures

RAN_AUTH_FAILURES_NO_AT_CHALLENGE_RSP

RAN Authentication Failures Dueto Missing AT ChallengeResponse

AAA_SERVER_FAILURES AAA Server Failures

References

For detailed information about service measurements, see

• CDMA2000® 1xEV-DO Network Service Measurements,401-614-326


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Overview

The following interface must be available before RAN Authentication can beimplemented:

• a 1xEV-DO A12 software interface on the AAA

To implement the 1xEV-DO RAN Authentication feature, perform the following EMSprocedures:

“Activating the Feature” (p. 2-10)

“Configuring the feature using EMS” (p. 2-11)

“Provisioning the Access Terminal” (p. 2-16)

“Provisioning the RAN AAA server” (p. 2-17)

“Provisioning the route for RAN AAA on the TP” (p. 2-18)

Operations and Maintenance Center - Radio Access Network (OMC-RAN) configurationmanagement

For more information about the different 1xEV-DO OA&M interfaces that are used inperforming OA&M tasks on the EV-DO controller and it’s managed resouces,including the purpose of each interface and how to access it, seeAlcatel-Lucent 9271EV-DO Radio Network Controller,401-614-102, Chapter 3,″User Interfaces″.





Also see the “About this information product” at the beginning of this document forthe most commonly-used ways to find certain information on EMS and where to findthe equivalent information on the OMC-RAN, or CDMA2000® 1xEV-DOConfigurations Parameters Guide,401-614-324.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


2-9

Activating the Feature...................................................................................................................................................................................................................................

Purpose

This procedure activates the 1xEV-DO RAN Authentication feature in aCDMA2000®

1xEV-DO network. Follow the steps for a standalone OMP-FX or a shared OMP-FX,depending on your configuration.

Procedure for a standalone OMP-FX

If you have a standalone OMP-FX, perform the following steps:

...................................................................................................................................................................................................

1 Contact your Customer Technical Advocate (CTA) about the generation of an OMPFeature Activation File (FAF).

...................................................................................................................................................................................................

2 Proceed to“Configuring the feature using EMS” (p. 2-11).

Procedure for a shared OMP-FX

If you have a shared OMP-FX, perform the following steps:

...................................................................................................................................................................................................

1 Ask your account executive to activate the following entry in your FAF:

A12 RAN Authentication

...................................................................................................................................................................................................

2 Proceed to“Configuring the feature using EMS” (p. 2-11).

E N D O F S T E P S...................................................................................................................................................................................................


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

E N D O F S T E P S...................................................................................................................................................................................................

Configuring the feature using EMS...................................................................................................................................................................................................................................

Purpose

Use this procedure to configure the 1xEV-DO RAN Authentication feature for a servicenode using the EMS Graphical User Interface (GUI).

Procedure


...................................................................................................................................................................................................

1 Verify IP connectivity to the RNC. From the RAN AAA server, ping the TrafficProcessor (TP) external ports. If the ping is successful, proceed with EMSprovisioning. If the ping fails, do arouteadd on the TP. The procedure to add routesto the TP is described in the CDMA2000® 1xEV-DO Radio Access System Planningand Implementation Guide,401-614-101.

...................................................................................................................................................................................................

2 Access the OMP Web page according to your local practices.

Result: The OMP Web page appears.

...................................................................................................................................................................................................

3 Click on the Configuration Data Icon.

Result: The Configuration Data page appears. It lists the components that can beconfigured.

...................................................................................................................................................................................................

4 Click on the link to AAA Servers.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


2-11

Result: A page similar to the following appears.

...................................................................................................................................................................................................

5 Click on the AAA IP Address for the AAA you want to configure for RANAuthentication.

Result: The AAA Server Instance page appears. (The blue navigation buttons arenot shown in the rest of the examples.)


Configuring the feature using EMS

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

...................................................................................................................................................................................................

6 Configure the AAA server parameters as follows:

• Click on the value you wish to use forA12 Shared Secret Format. The default isASCII format.

• Enter a value forA12 Shared Secret.

– The length of Shared Secret data is a fixed length of 16 for ASCII format and afixed length of 32 for hexadecimal format.

...................................................................................................................................................................................................

7 Click the Submit button.

...................................................................................................................................................................................................

8 In the list of blue navigation buttons on the left side of this EMS page, click on thelink to Service Nodes. (You may need to scroll down to see that link.)

Result: The Service Nodes Summary page appears.

...................................................................................................................................................................................................

9 Click on the Service Node you want to configure for RAN Authentication. On theresulting screen, scroll down in the window until you see the link to A12 RANAuthentication.

Result: The following example shows the link to the A12 RAN Authenticationparameters for Service Node 3.

...................................................................................................................................................................................................

10 Click on the link for A12 RAN Authentication.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


2-13

Result: The RAN Authentication Instance Page for that service node appears.

...................................................................................................................................................................................................

11 Configure the A12 RAN Authentication parameters as follows:

• Enable RAN AuthenticationThis parameter indicates the status of the RAN authentication feature:

– Click the radio button besideEnabled .

• A12 Retry TimerThis timer indicates the allowed interval for receiving either an Access Accept orAccess Reject message from the A12 AAA before retrying the Access Requestmessage and re-reaching0.

– Enter a number from1 to 4. The default is2 seconds.

• AAA Server Out-of-Service Retry TimerIf an AAA server has been declared out of service by the Radio Network Controller(RNC), this timer sets the interval after which the TP attempts an A12 AccessRequest to the AAA server to test if it is back in service. This timer does not applyif all provisioned A12 AAA servers are declared out of service. In this example″allprovisioned″ means is only one server is provisioned and it is out of service or iftwo servers are provisioned and they are both out of service.

– Enter a number from1 to 900. The default is900 seconds.

• A12 Retry CountThis parameter indicates the number of times the RNC can reset the A12 RetryTimer before declaring an AAA server out of service. If an alternate A12 AAAserver has been provisioned, this counter is reset to0 when the RNC sends its firstAccess Request message to the alternate AAA for a given CHAP identifier.

– Enter a number from1 to 3. The default is3.

...................................................................................................................................................................................................

12 Click the Submit button at the bottom of the page. (Scroll down to see this button, ifit is not visible on the screen.)



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Result: You have submitted the RAN Authentication parameters for that servicenode.

E N D O F S T E P S...................................................................................................................................................................................................



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


2-15

Provisioning the Access Terminal...................................................................................................................................................................................................................................

Purpose

Use this procedure to provision the AT for RAN Authentication.

Procedure


...................................................................................................................................................................................................

1 Provision the International Mobile Station Identity (IMSI).

...................................................................................................................................................................................................

2 Provision the CHAP username. This should match the username format in the RANAAA server.

...................................................................................................................................................................................................

3 Provision the CHAP Authentication password. This should match the password in theRAN AAA server.

...................................................................................................................................................................................................

4 Provision any other AT parameters at your discretion.

E N D O F S T E P S...................................................................................................................................................................................................


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Provisioning the RAN AAA server...................................................................................................................................................................................................................................

Purpose

Use this procedure to provision the RAN AAA server.

Procedure


...................................................................................................................................................................................................

1 Make sure you are running NAVIS Radius 4.3.2 or later.

...................................................................................................................................................................................................

2 Provision the Shared Secret Data to match what is provisioned in the EMS.

...................................................................................................................................................................................................

3 Create a profile for each device. In the profile, Call Back ID is a mandatory field thatshould be returned by the RAN AAA when RAN AAA is successful. All other fieldsare optional.

Enter a Callback ID for each profile and any of the optional fields:

1. Call Back ID, which is0 (zero) plus15 digit IMSI. Call Back ID must be definedas a stringfor the functionality to work.

2. RAN AAA username as defined by the service provider. This should be differentfrom the username for PDSN AAA authentication.

E N D O F S T E P S...................................................................................................................................................................................................


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


2-17

Provisioning the route for RAN AAA on the TP...................................................................................................................................................................................................................................

Purpose

Use this procedure to provision the route for the RAN AAA on the traffic processor.

Procedure


...................................................................................................................................................................................................

1 Do a routeadd on the TPs for each RNC to route to the RAN AAA server.

For more information, see CDMA2000® 1xEV-DO Radio Access System Planning andImplementation Guide,401-614-101.

E N D O F S T E P S...................................................................................................................................................................................................


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

3 3Cell Swing Capability forEVolution Data Optimized(1xEV-DO)

Overview...................................................................................................................................................................................................................................

Purpose

This chapter describes the following optional features inCDMA2000® 1xEV-DOnetworks. The Feature Identifiers (FIDs) of the feature in this chapter is:

• Cell Swing Capability for 1xEV-DO (FID 12188.1)

Cell Swing Capability for 1xEV-DO removed in Release 29.0

Important! As of Release 28.0, Pre-Converged Cell Swings (FID 12188.0) are nolonger applicable once all the cells are converged, or the OMP-FX has beenupgraded to Release 28.0 software, whichever comes first. The instructions for CellSwings and the deprecated objects were removed from this document in R29.0,maintaining only the FAF activation and any background information that helps theunderstanding of this feature.

This document will acknowledge that if the EVDO RNC is managed by OMC-RAN,nothing changes with respect to Cell Swing. Release 28.0 feature OMP-FX BulkProvisioning Capability for OMC-RAN Managed DO-RNCs, (FID 9123.2), providesthe functionality for BP to still work on the OMP-FX regardless of whether the RNC ismanaged by EMS or OMC-RAN (and BP [and therefore Cell Swing] still runs on theOMP-FX in both cases).

Information about migrating the RNC from EMS to OMC-RAN is described inCDMA2000® 1xEV-DO Radio Access System Planning and Implementation Guide,401-614-101.


Feature summary

Following is the high-level summary of the feature covered in this chapter:

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-1

Cell Swing Capability for 1xEV-DO (FID 12188.1)

The Cell Swing Capability for 1xEV-DO feature provides the ability to:

• move one or more 1xEV-DO Base Transceiver Stations (BTSs), along with all oftheir related managed objects and call processing data, from one pair of FMS-APsto another pair of FMS-APs

– on the same RNC frame, or

– between two RNC frames within the same or different Service Node(s)

• rename one or more 1xEV-DO BTS(s) without moving the BTS(s) off of theFMS-AP pair

• performing a move and rename in one procedure for one or more 1xEV-DO BTSs

• updating specific fields of specific forms associated with the cell data in the1xEV-DO RNC call processing databases for cells that are moving/renaming

• updating the Source and Target Dynamic Host Configuration Protocol (DHCP)tables, netmask files, andT1 network files

This feature also moves mixed-mode cells in a network that supports Cell Operations,Administration and maintenance (OA&M) Convergence.


Feature User interface Feature impact

Cell Swing Capability for1xEV-DO (FID 12188.1)

Element ManagementSystem (EMS) andOperations andMaintenance Center -Radio Access Network(OMC-RAN)

See“Activating thefeature” (p. 3-24)

Service measurements None


None


None



Cell Swing Capability for EVolution Data Optimized(1xEV-DO)

Overview

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Contents

Availability 3-4

Prerequisites 3-5

Feature description: Cell Swing Capability for 1xEV-DO 3-7


Issues and caveats 3-22

Implementing the features 3-23


Confirming feature activation 3-26

Determining the NthIP 3-27

Move a 1xEV-DO cell (intra-RNC) 3-29

Move a 1xEV-DO cell (inter-RNC/Same Service Node) 3-44

Move a converged 1xEV-DO cell (inter-RNC/Different Service Node) 3-61

Rename a cell 3-79

Move and Rename a cell (intra-RNC) 3-93

Move and Rename a cell (inter-RNC) 3-108

Cell Swing backout procedure 3-126

Verify OA&M on moved and/or renamed converged cell 3-129

Verify service measurements reporting 3-132

Cleanup of old Cell Swing files 3-134

Moving Base Stations from R1SR Based 1xEV-DO RNC APs toUniversal Cabinet (UNC)-Based 1xEV-DO RNC APs

3-136


Overview

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-3

Availability...................................................................................................................................................................................................................................


Feature Available in

Cell Swing Capability for 1xEV-DO Releases 26.0 SU2 and later

(Cell Release 25)

Market availability


Cell Swing Capability for 1xEV-DO all markets


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Prerequisites...................................................................................................................................................................................................................................

Introduction

The 1xEV-DO Cell Swing features have the following prerequisites.

Important! Per the impact of 1xEV-DO Gold BCMCS (FID 10862.5) feature theBroadcast/Multicast Service (BCMCS) carrier activation must bedeactivatedbefore attempting a cell swing. If not the cell swing will be aborted and the or theresult will be an aborted and the Source RNC Database must be restored.


The 1xEV-DO Cell Swing features are supported in the following air-interfacetechnologies:

• 1xEV-DO


The Cell Swing Capability for 1xEV-DO software capabilities are listed below:

Cell Swing Capability for 1xEV-DO feature

The Cell Swing Capability for 1xEV-DO feature requires Platform Release 25.0 orlater, and the following features to be activated:

• Bulk Provisioning (FID 9123.0)

• 1xEV-DO Bulk Provisioning Enhancements (FID 9123.1)

To support mixed-mode cells, the folowing features are required:

• Inter-MSC Cell Swing (FID 2794.0)

• Inter-MSC Cell Swing Modular Cell 4.0/HD4.0 (FID 2794.1)

Important! 1xEV-DO Cell Swing is activated by a single FAF entry (see“Activating the feature” (p. 3-24)).

RRL (Restricted Root Login)

In RRL on mode, you need to be a system administrator or you have to have the useraccount access that is assigned thersysadm system administrator role.


The Cell Swing Capability for 1xEV-DO feature requires no hardware beyond thestandard hardware in a wireless network.

Supported BTS types are:CDMA2000®, 1xEV-DO modular cells and Alcatel-LucentCDMA Base Stations.

The Cell Swing Capability for 1xEV-DO hardware capabilities are listed below:


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-5


The Cell Swing Capability for 1xEV-DO feature requiresroot login access on theOperations and Maintenance Platform (OMP) and the FMS-AP interfaces to enter the1xEV-DO cell swing tool(s).


Prerequisites

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Feature description: Cell Swing Capability for 1xEV-DO...................................................................................................................................................................................................................................

Introduction

The following information describes the functionality and operation of the 1xEV-DOCell Swing feature.

Functionality

The 1xEV-DO Cell Swing feature facilitates:

• moving one or more 1xEV-DO Base Transceiver Stations (BTSs), along with all oftheir related managed objects and call processing data, from one pair of FMS-APsto another pair of FMS-APs

– on the same RNC frame

– between two RNC frames within the same Service Node

– between two RNC frames residing on different Service Node(s)

• renaming one or more 1xEV-DO BTS(s) without moving the BTS(s) off theFMS-AP pair

• perform a move and rename in one procedure for one or more 1xEV-DO BTSs

• updating specific fields of specific forms associated with the cell data in the1xEV-DO RNC call processing databases for cells that are moving/renaming

• updating the Source and Target Dynamic Host Configuration Protocol (DHCP)tables, netmask files, andT1 network files

• Additionally, theevdoswing tool has been updated to generate backout scripts forthe Neighbor SN″NeighborSector″ managed objects. The backout scripts are to beused in the event a cell is not successful.


The 1xEV-DO Cell Swing feature is comprised of several tools run on the OMP for(OMP-FX). The tools, restricted toroot login permission, accomplish a 1xEV-DO cellmove by accessing the following tasks by creating/deleting/modifying information asneeded:

• Source Bulk Provisioning (BP) database table dumps

• Target Bulk Provisioning database table dumps (if Target RNC is different from theSource RNC)

• Neighboring Service Node (SN) Bulk Provisioning Neighbor Sector table dumps

• Source network files

• Target network files on the Source OMP (copied from the Target system to theSource OMP if Target RNC is different from the Source RNC)


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-7

The Cell Swing Capability for 1xEV-DO feature also examines the value ofBTSConvergence Flag to determine if a particular cell has gone through the Cell OA&MConvergence conversion process.BTS Convergence Flag is a read-only attribute,available on the Element Management System (EMS) or if the RNC was migrated tothe OMC-RAN, go to the OMC-RAN GUI, used to indicate the Cell OA&MConvergence status of the Base Transceiver Station (BTS).

For cells that have gone through convergence (BTS Convergence Flag is ″yes″), thetool migrates only the following cell data:

• Cell

• Sector

• NeighborSector

• IFHO Targets

• Sector Carriers

Tool Set

Tool Description

evdodump Tool to extract the 1xEV-DO RNCFMS-AP database tables/data used byevdoswing; run on the OMP of theSource, Target, and Neighboring servicenode system.

evdoswing Tool used to create the BP scripts to movethe BTS translation data from the Sourceto the Target system; run on the SourceOMP.

evdomkdir Creates a directory structure forevdonetwork to use.

evdonetwork Tool used to delete/update the networkfiles on both the Source and Target RNCFMS-APs; run on the Source OMP. Itcreates scripts which have to betransferred to both the Source and TargetLead FMS-APs and run on those systemsto delete/create the corresponding entriesfor the moved/renamed BTS.

Note: The tools reside on the OMP, under the/omp/bindirectory.


Feature description: Cell Swing Capability for 1xEV-DO

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Logfiles

Logfiles for all tools are housed in:/omp-data/logs/evdotools/

Logfile names:

• evdodump.log

• evdoswing.log

• evdonetwork.log

• runBPmmddyyyy.log

Preliminary setup

The user prepares for the move by:

1. Logging on to the Source OMP asroot in the order shown

2. See Step6 for the explanation of the Restrict Root Login (RRL).In the RRL off mode make a backup copy of the FMS-AP usingdbunload, locatedin: /flx/ONEXEVc/current/release/utilIn the RRL on mode , log on to the database FMS-AP with a user account andassumersysadm role. Choose a directory underrsysadm home /roles/rsysadm/dbbackup.Important! If this directory does not exist, then it should be created:

• mkdir –p /roles/rsysadm/dbbackup

• cd /roles/rsysadm/dbbackup

• $HDRROOT/release/util/dbunload

3. Obtaining a list of active generics on the Source and Target systems (to ensure thatthe cell generics installed on the cell to be swung are available on the Target RNC)

4. Enabling the BP tools environment

5. Making a temporary directory to contain the user-created input files and BP dumpoutput files

6. Starting with Release 30.0, DO RNC security feature Restrict Root Login (RRL)(FID 10737.9) restricts access to DO RNCroot andonexev accounts on APs.However, the steps on OMP are still performed with an OMProot account. But inthe RRL on mode , you will need access to the RNC user account that has access tothe rsysadm role or you are the privileged system administrator. Specific stepswithin this chapte’s procedures indicate theRRL on mode and theRRL off mode . Inthe RRL on mode , there are specific steps to be done on a DO RNC AP with a roleuser account like taking backing and transferring the swing scripts. There arespecific steps that are needed to be executed as thersysadm role in this mode.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-9

If person1 were to log on DO RNC lead AP and has access to thersysadm rolethe following is an example of how to login and access thersysadm role:

• Type and enter:ssh person1@flx121

• Type and enter:su – rsysadm

• Type and enter a password:Enter the rsysadm role password on the prompt to get access.

evdodump

The user changes directory (cd) to the temporary directory made during the initialsetup. The user enters theevdodump tool from within the temporary directory. The useris then prompted for the SN OMP type (s for Source,n for Neighbor, ort for Target)and the SN ID. The tool invokes the Bulk Provisioning (BP) tool, creating BP dumpscripts which automatically dump data using Bulk Provisioning on the Source, Target,or Neighboring SN’s OMP. On the Source SN OMP, all the tables will be dumped.

Important! Never breakout ofevdodump after the command has been started. Oncethe command has been entered, information is transmitted to the database interface.Using the Break Key or using<CNTL> -c does not stopevdodump from executing,it will only prevent you from seeing any output (success or failure) messages thatwould have been displayed on the OMP. This feature allows the moving/renamingof converged cells. When moving/renaming converged cells, the-c option ismandatory on the command line.

For additional information, see″Bulk Data Provisioning - Limitations″ section ofCDMA2000® 1xEV-DO Networks EMS Configuration Management BulkProvisioning Guide,401-614-325.

On the Target SN OMP, only the AP and Neighbor Sector tables will be dumped. Onthe Neighboring SN OMP, only the AP and the Neighbor Sector tables will be dumped.

The evdodump tool utilizes the following information:

1. A user-created file (calledcell_file) defining the changeable cell attributes

Example command lines:

evdodump -d evdo_dumpdir -i cell_file

evdodump -h

Where:

evdo_dumpdir Top node of directory structure where BPunloads data; Use$bpPath variable.

cell_file user-created cell input file



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

-c dumps tables for converged cells

-h prints theevdoswing command usagehelp message

Sample BP dump output

This sample shows all the Source BTS Identifier-related forms. The first script dumpsAP table, which is later parsed to gather the FMSFrameId (needed to dump all otherscripts by frame ID).

output stored AP for which (hdrsnID=xx) to ″APxx.txt″;

output stored Cell for which (hdrsnId = xx, FMSFrameId = yy) to

″Cellxxyy.txt″;

output stored CellCabinet for which (hdrsnId = xx, FMSFrameId = yy) to

″CellCabinetxxyy.txt″;

output stored Sector for which (hdrsnId = xx, FMSFrameId = yy) to

″Sectorxxyy.txt″;

output stored NeighborSector for which (hdrsnId = xx, FMSFrameId = yy)

to ″NeighborSectorxxyy.txt″;

output stored CDM for which (hdrsnId = xx, FMSFrameId = yy) to

″CDMxxyy.txt″;

Forms and key fields

Form (in growth order) Key Fields

Cell hdrsnId, FMSFrameId, CellSiteId

Sector hdrsnId, FMSFrameId, CellSiteId, SectorId

NeighborSector hdrsnId, FMSFrameId, CellSiteId,SectorId, NbrId

IFHOTarget hdrsnId, FMSFrameId, CellSiteId,SectorId, CarrierId, TargetId

SectorCarrier hdrsnId, FMSFrameId, CellSiteId,SectorId, CarrierId

Form (in degrowth order) Key Fields

SectorCarrier hdrsnId, FMSFrameId, CellSiteId,SectorId, CarrierId



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-11

Form (in degrowth order) Key Fields

IFHOTarget hdrsnId, FMSFrameId, CellSiteId,SectorId, CarrierId, TargetId

NeighborSector hdrsnId, FMSFrameId, CellSiteId,SectorId, NbrId

CDM hdrsnId, FMSFrameId, CellSiteId,CellSiteCabId, CdmId

Sector hdrsnId, FMSFrameId, CellSiteId, SectorId

CellCabinet hdrsnId, FMSFrameId, CellSiteId,CellSiteCabId

Cell hdrsnId, FMSFrameId, CellSiteId

For cells that have not gone through the convergence process, the tool continues tomigrate all of the cell-related data supported by the 1xEV-DO Cell Swing feature.

evdoswing

The evdoswing tool is entered on the Source OMP to create the insert, delete, andreplace BP scripts to move the BTS translation data. Theevdoswing tool utilizes threepieces of information:

1. A user-created file (calledcell_file) defining the changeable cell attributes

2. A user-created file (calledsn_file) defining the service nodes for the Source SN,Target SN, and each of the Neighbor SNs affected by the moving of cells on theSource SN

3. The path to the temporary directory (used in theevdodump command) where thetable data was dumped

It also allows the moving/renaming of cells.

cell_file file

The cell_file file is a user-created file that defines the changeable cell attributes. Thefirst row of the file is a required header row containing a comma-separated list of keyfield names, entered in any order. The subsequent rows contain lists ofcomma-separated data values and must match the same order as the header row. Thedata value rows may contain a new value or ann. Then value means″no change″ andcan be used as a place holder for any of the optional fields, in case some of the fieldschange for some but not all of the BTSs.

• Required fields are:CellSiteIdOld, CellSiteNew, FMSFrameIdNew,and convFlag

• Optional fields are:apIDNew, hdrHWSrvrIdNew, andbtsNameNew



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Samplecell_file file:

CellSiteIdOld,CellSiteIdNew,FMSFrameIdNew,convFlag,apIdNew,hdrHWSrvrIdNew,btsNameNew

11,205,20,1,193,418,farHills

107,203,20,1,194,426,N

166,263,20,1,192,410,N

Important! All cells in the user-createdcell_file must be converged.

Important! The convFlag value must be set to one,″1″, designating convergedcells.

Important! The btsNameNew value included in the input file cannot be the sameas anybtsNameNew that exists on the Target system.

Important! Optional field hdrHWSrvrIdNew should be provided with a value of800 for a converged cell whose currenthdrHWSrvrId is not 800 , whenever the cellis swung to a different frame.

Important! This work around can be used only to correct theHWSrvrId of onlyONE converged cell with a non-800HWSrvrId. For all other converged cells whichare swung in this tool execution, thehdrHWSrvrIdNew should ben.

sn_file file

The sn_file file is a user-created file that defines the affected service nodes. This filedoes not have a header line. The file contains a single comma-separated list of nodenames (numbers):Source Service Node, Target Service Node, Neighbor Service Node 1,Neighbor Service Node 2,. . ., Neighbor Service Node 10 .

• Required fields are:Source Service Node and Target Service Node (Target SN is requiredonly if it is different from theSource SN or if a Neighbor SN is entered).

• Optional fields are:Neighbor Service Node #

Samplesn_file file:

3,1,2

Where:

3 = Source SN

1 = Target SN

2 = Neighbor SN

Important! If Neighbor Service Node IDs are not entered, then it is assumed thatthey are not affected and therefore scripts will not be generated for them.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-13

Important! All OMPs (including the Source 1xEV-DO RNC FMS-AP, the Target1xEV-DO RNC FMS-AP, and the Neighboring cells) must be on the same softwarerelease and software update. If the Neighbor cell(s)/OMP(s) are on a differentrelease, the Neighbor lists must be manually updated.

Path to the temp directory

The temporary directory contains the output of the BP dump scripts (one .txt file foreach applicable cell-related form). When executing the EVDO cell swing tools, the -dfield requires the user to specify the path the temporary directory. The$bpPathenvironment variable may be substituted for the full path in the command line.


The command is typed on a single continuous line at the OMP interface:

evdoswing -d evdo_dumpdir -i cell_file -s sn_file [-v]

evdoswing -h

Where:



sn_file user-created service node file

-v prints further details ofevdoswingprocess (optional)


evdomkdir

The evdomkdir command is run once on the Source OMP. Theevdomkdir commandcreates a directory structure to be used when transferring the network files, which arelater used byevdonetwork. For each Source service nodeXXX, evdomkdir creates thedirectory top_node/sXXX/fYY. Likewise, for each Target service nodeXXX andFMSFrameIdNewYY, evdomkdir creates the directorytop_node/s XXX/fYY.

If the directory is already present, the tool will report that this is the case. If there areproblems creating the directory, or if a file (instead of directory) is already present,errors will print.



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

evdonetwork

The evdonetwork tool is run once on the Source OMP. Theevdonetwork tool createsscripts that

• Deletev entries for each cell being modified

• Deletedhcpentries for each cell being modified

• Deletenetmasksentries for each cell being modified

• Createnetmasksentries

• Createdhcpentries

• CreateT1 entries

• Adds T1 entries

Scriptnames are in the format

t1fileDel<SNID><FMSID>

dhcpDel<SNID><FMSID>

netmskDel<SNID><FMSID>

netmskAdd<SNID><FMSID>

dhcpAdd<SNID><FMSID>

t1fileCrt<SNID><FMSID>

t1entryAdd<SNID><FMSID>

network_file file

The network_filefile is a user-created file that defines the Source and Target frameIDs. The first row of the file is a required header row containing key field names,entered in any order. The second row is a data value row and must match the sameorder as the header row.

• Required fields are:FMSFrameIdOld, FMSFrameIdNew, CellSiteIdOld, CellSiteNew, andNthIp

• Optional fields are:CellSubnet, CellNetmask, T1IpAddr_1, T1SubnetMask_1, T1IpAddr_2,

T1SubnetMask_2, T1IpAddr_3, T1SubnetMask_3, T1IpAddr_4, T1SubnetMask_4, EthernetBH, EthernetBH_Subnet, EthernetBH_Netmask, btsNameNew,andCdmNo (CDM number in multi-carrier cell: value range = 1 to 3)

Samplenetwork_filefile:

CellSiteIdOld,CellSiteIdNew,FMSFrameIdOld,FMSFrameIdNew,CdmNo,NthIp

242,542,5,8,1,2



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-15

The Nth IP variable is determined by subtracting the last three digits of theT1_IP_address from the Client IP address. Refer to the“Determining the NthIP”(p. 3-27)procedure for specific details.

NthIP

The Nth IP variable is determined by subtracting the last three digits of theT1_IP_address from the Client IP address. Refer to the“Determining the NthIP”(p. 3-27)procedure for specific details.


evdonetwork -n evdo_dumpdir -i network_file -s sn_file

evdonetwork -h

Where:


network_file user-created network input file


-h prints theevdonetwork command usagehelp message

Backout scripts

The evdoswing tool to generates backout scripts for the Neighbor Service Node BTS″Neighbor Sector″ managed objects which can be used in the event a cell swing is notsuccessful:

Example:

NeighborSectorXXXYYBackoutZ)

Where:

XXX = three-digit value for the Service Node ID

YY = two-digit value for the Frame ID

The backout scripts are housed in the same directory as the Add/Delete/Create scripts.When entered, the backout scripts delete the new Neighbors and then add back theoriginal Neighbors.



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Service-provider perspective

The 1xEV-DO Cell Swing feature requires service providers to ensure that:

• The Bulk Provisioning feature is available to dump and load 1xEV-DO RNC tabledata,

• Sufficient disk space is available on the OMP to dump the 1xEV-DO RNC tabledata (disk space requirement should be based on table data sizes as known by localcraft),

• All OMPs (including the Source 1xEV-DO RNC FMS-AP, the Target 1xEV-DORNC FMS-AP, and the Neighboring cells) are on the same software release andsoftware update (if the Neighbor cell(s)/OMP(s) are on a different release, theNeighbor lists must be manually updated),

• The OMP and FMS-AP are networked and have a means to transfer data files viathe network commandsftp, and

• The FMS-APs must have the same software revision numbers.

Modifiable BTS information

Non-key attributes of the BTS and its contained managed objects may be modified.These attributes are:

• BTS primary FMS-AP number

• BTS (cell) name

• BTS (cell) cabinet - hardware server ID

Networking information may also be modified; specifically:

• Primary FMS-AP IP address

• Cell IP address (cell subnet)

• Cell netmask

• T1 IP address

• T1 subnet mask

• Ethernet Backhaul Subnet

• Ethernet Backhaul Netmask

Important! If the user does not provide this information, then the existinginformation provisioned on the Source RNC is used.

Skill Sets Required

When moving cells, the Cell Swing tools user should be familiar with:

• the database backup command/operation

• the database copy forward command/operation

• OMP ROP files

• cell translations for various cell configurations



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-17

• CDMA Cell Swing tools

• Bulk Provisioning



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Cell Swing Capability for 1xEV-DO feature

The Cell Swing Capability for 1xEV-DO feature interacts with the following features:

• 1xEV-DO Rev. A Software License (FID 12078.2)

• Bulk Provisioning (FID 9123.0)

• Universal Cabinet (UNC) Based 1xEV-DO RNC Infrastructure (FID 12885.1)

• 1xEV-DO Cell OA&M Convergence (FID 11003.1)

• Inter-MSC Cell Swing (FID 2794.0)

• Inter-MSC Cell Swing Modular Cell 4.0/HD4.0 (FID 2794.1)

• 1xEV-DO Gold BCMCS (FID 10862.5)

1xEV-DO Rev. A Software License (FID 12078.2)

The 1xEV-DO Rev. A software license key, introduced by FID 12078.2, is required toactivate Rev. A on Rev. A capable BTS carriers. When a Rev. A “converged cell” is tobe swung, the user must check that there are available Rev. A software licenses on thetarget RNC so that the Rev. A will be active on this cell after it is swung.

If Rev. A is not active on the target RNC, then Rev. A must be deactivated on thecell(s) before the cell swing tools are used.

If there are not enough Rev. A software licenses available on the target RNC, and thecell is swung to that RNC, then the cell will come up as a Rev0 cell.

If more Rev A licenses are needed, the user has to install a new Rev. A softwarelicense key. The procedure to install the Rev A software license key is described in theActivating the 1xEV-DO Rev. A serviceschapter of the CDMA2000® 1xEV-DO RadioAccess System Planning and Implementation Guide,401-614-101.

Bulk Provisioning (FID 9123.0)

The Bulk Provisioning feature allows configuration of multiple cells (via a script)without going through individual cell provisioning via EMS screens. The 1xEV-DOCell Swing feature uses the Bulk Provisioning feature to dump and load 1xEV-DORNC table data. For details, see CDMA2000® 1xEV-DO EMS ConfigurationManagement Bulk Provisioning Guide,401-614-325.

Universal Cabinet (UNC) Based 1xEV-DO RNC Infrastructure (FID 12885.1)

The Universal Cabinet (UNC) Based 1xEV-DO RNC Infrastructure completes anddelivers the 1xEV-DO RNC in the Universal Cabinet (UNC).


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-19

This feature introduces the next generation 1xEV-DO Radio Network Controller(RNC), which will be housed in a Universal Network Cabinet (UNC). The UNC-basedRNC is intended to provide a significant capacity increase compared to theR1SR-based RNC. It is anticipated that the UNC-based RNC will support up to 6001xEV-DO Carriers.

In order to provide the increased capacity, the UNC-based 1xEV-DO RNC cabinetutilizes two new 48-port Ethernet switches (Extreme), up to 8 new Applicationprocessors (AP CP2500) and up to 10 Universal Traffic Processors (UTP).

Important! Only UTPs are supported in UNCs (that is no 690s or 752s).

The configuration management of the UNC-based RNC is performed only via theOMC-RAN (using OMC-RAN Graphical User Interface (GUI)). Information aboutmigrating the RNC from EMS to OMC-RAN is described in CDMA2000® 1xEV-DORadio Access System Planning and Implementation Guide,401-614-101

1xEV-DO Cell OA&M Convergence (FID 11003.1)

The 1xEV-DO Cell OA&M Convergence feature allows 1xEV-DO cell hardwarecomponents to reside in the RC/V database instead of the 1xEV-DO database. Once acell has been moved to the RC/V database, it is considered″converged.″ The BTSConvergence Flag attribute, introduced by FID 11003.1, is used by the 1xEV-DO CellSwing feature to determine cell convergence status. When moving a″converged″ cell,only the BTS, BTS Cabinet, CDM, Sector, and Neighbor Sector objects will be moved.

Inter-MSC Cell Swing / Inter MSC Cell Swing Modular Cell 4.0/HD4.0 (FID 2794.1)

The Inter-MSC Cell Swing / Inter MSC Cell Swing Modular Cell 4.0/HD4.0 featuresallow move/rename of CDMA modular cells. When 1xEV-DO cells are in mixed mode,that is, CDMA Modular cells with 1xEV-DO cells in the same cell, it is expected thatboth the Inter-MSC Cell Swing tool for the CDMA cells and the 1xEV-DO Cell Swingfor 1xEV-DO cells will be executed. For more information on the Inter-MSC CellSwing tools, seeInter-MSC Cell Swing,401-612-150. Converged and unconvergedcells must be moved separately.

1xEV-DO Gold BCMCS (FID 10862.5)

Important! Must disable BCMCS carrier on the cell before running the cell swingtool.


Feature interactions

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

When the 1xEV-DO Gold BCMCS feature is aligned with a cell swing:

• If bcmcsActivationflag was set toActivate, prior to the cell swing , theoperator must set the flag toDeactivate before proceeding with a cell swingprocedure.

• If the operator executes the cell swing tool and one of the carriers being swung hasa bcmcsActivationflag set toActivate the cell swing is aborted. Subsequently,the database at the source RNC must be restored, using the database restorationprocedure.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-21

Issues and caveats...................................................................................................................................................................................................................................

Introduction

The 1xEV-DO Cell Swing feature is subject to the following special issues and/orcaveats.

Issues

The 1xEV-DO Cell Swing feature supports only configurations where all OMPs(including the Source 1xEV-DO RNC FMS-AP, the Target 1xEV-DO RNC FMS-AP,and the Neighboring 1xEV-DO RNC FMS-APs) are on the same software release andsoftware update. If the Neighbor 1xEV-DO RNC FMS-AP(s)/OMP(s) are on a differentrelease, the Neighbor lists must be manually updated.

Caveats

• Any router configuration updates that might be necessary as a result of cellmovement is beyond the scope of the 1xEV-DO Cell Swing feature and beyond thescope of this chapter.

• However, note that when cells are being moved inter-RNC under the sameServiceNode (which requires router changes), change the current″IPhelperaddress/dhcp relay IP address″ and do not just add it to the current routerconfiguration. If the router has both the new and the previous IP helper/dhcp relayaddresses in the router configuration(s), then it can cause the cell not to dhcp orstable clear (or can take hours to finally dhcp because the router would be going tothe previous lead FMS-AP for the BTS’s IP address). This applies to both primaryand secondary routers when there is a redundancy.

• It is recommended that the service provider swing no more than 10 cells during asingle maintenance window. This applies to either pre-converged or convergedcells.

• Refresh any BTS Summary Page opened before or during Cell Swing activities toensure current BTS Cell Status is displayed. Using only one instance of the BTSSummary Page will minimize display performance issues.

• A converged cell that is swung using the EVDO Cell Swing tool cannot be backedout and converted into a non-converged cell once it is in the new system. Unless itis done using the manual procedures.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Implementing the features...................................................................................................................................................................................................................................

Process

To implement the 1xEV-DO Cell Swing feature, perform the following procedures insequence:


“Confirming feature activation” (p. 3-26)

“Determining the NthIP” (p. 3-27)

“Move a 1xEV-DO cell (intra-RNC)” (p. 3-29)

“Move a 1xEV-DO cell (inter-RNC/Same Service Node)” (p. 3-44)

“Move a converged 1xEV-DO cell (inter-RNC/Different Service Node)” (p. 3-61)

“Rename a cell” (p. 3-79)

“Move and Rename a cell (inter-RNC)” (p. 3-108)

“Move and Rename a cell (intra-RNC)” (p. 3-93)

“Cell Swing backout procedure” (p. 3-126)

“Verify OA&M on moved and/or renamed converged cell” (p. 3-129)

“Verify service measurements reporting” (p. 3-132)

“Cleanup of old Cell Swing files” (p. 3-134)


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-23


Purpose

This procedure activates the 1xEV-DO Cell Swing feature in a wireless network.

Important! If the RNC is managed by EMS, procedures as stated in this documentare valid, going through the GUI. If the RNC has been migrated to the OMC-RAN,the customer has to go through the OMC-RAN GUI to see maintenance statedisplays, because Fault Management on EMS GUI will be shutdown for suchRNCs. If all the RNCs for a release were migrated to the OMC-RAN, the customermust go to the OMC-RAN GUI to look at database data on a GUI screen, BUTthat data is always available to Bulk Provisioning users on the OMP-FX.

For detailed procedures regarding the impact of OMC-RAN becoming a mandatoryplatform for EV-DO in R29.1 and later, see Appendix 7 ofAlcatel-Lucent 9271EV-DO Radio Network Controller,401-614-102.

Configuration management: Operations and Maintenance Center - Radio Access Network(OMC-RAN)







Procedure


...................................................................................................................................................................................................


1xEV-DO Cell Swing (EVDOSWING)


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

...................................................................................................................................................................................................

2 Proceed to“Confirming feature activation” (p. 3-26).

E N D O F S T E P S...................................................................................................................................................................................................


Activating the feature

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-25

Confirming feature activation...................................................................................................................................................................................................................................

Purpose

This procedure confirms the successful activation of the 1xEV-DO Cell Swing featurein a wireless network.

Procedure

Important! Per the impact of 1xEV-DO Gold BCMCS (FID 10862.5) feature theBCMCS carrier activation must bedeactivated before attempting a cell swing. Ifnot the cell swing will be aborted and the or the result will be an aborted and theSource RNC Database must be restored.


...................................................................................................................................................................................................

1 For a stand-alone OMP, log in asroot on all Source, Target, and Neighboring OMPs.For a shared OMP, log in asroot on the ECP.

...................................................................................................................................................................................................

2 At the prompt, enter:fafprint | grep EVDOSWING

Result: If the 1xEV-DO Cell Swing feature is active, the system returns:

1xEV-DO Cell Swing (EVDOSWING), then this procedure is complete and you maylog off the root login.

...................................................................................................................................................................................................

3 If the system returns only a prompt, then the FAF was not activated. Rerun the“Activating the feature” (p. 3-24)procedure.

E N D O F S T E P S...................................................................................................................................................................................................


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Determining the NthIP...................................................................................................................................................................................................................................

Purpose

This procedure calculates theNthIP variable used by theevdonetwork command.

When to perform

Perform this procedure prior to attempting to move/rename a cell, as the informationobtained during this procedure will be used during a cell move/rename.

Procedure



...................................................................................................................................................................................................

1 Log onto the lead FMS-AP:

• In RRL off mode assumeonexev on lead AP and assume root id by entering:su - root.

• In RRL on mode login with user account and then assumersysadm role on lead APby entering:su - rsysadm.

...................................................................................................................................................................................................

2 Enter:grep ″Cell <cell_id>″ /etc/netmasks

Where: <cell_id> is the ID of the cell being modified.

Example: grep ″Cell 155″ /etc/netmasks

Result: A list of IP addresses are output.

Example:

10.150.200.20 255.255.255.224 #Cell 155

10.200.35.200 255.255.255.252 #first T1 for Cell 155

10.200.35.204 255.255.255.252 #second T1 for Cell 155

10.200.35.208 255.255.255.252 #third T1 for Cell 155

10.200.35.212 255.255.255.252 #fourth T1 for Cell 155

...................................................................................................................................................................................................

3 Write down the value of the first T1_IP_address (column 1 in the grep output fromStep 2) for the cell being modified.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-27

Example: 10.200.35.200

...................................................................................................................................................................................................

4 Enter:pntadm -P <T1_IP_address>

Where:

<T1_IP_address> is the T1_IP_address fromStep 3.

Example: pntadm -P 10.200.35.200

Result: Output example as follows:

Client ID Flags Client IP Server IP LeaseExpiration

Macro Comment

00 01 10.200.35.202 10.208.172.59 Forever mod5150

...................................................................................................................................................................................................

5 Write down the value of the Client IP from the output of thepntadm command inStep4.

Example: 10.200.35.202

...................................................................................................................................................................................................

6 Subtract the last set of digits of the T1_IP_address from the Client IP address.

Example: 202 - 200 = 2

Result: The resulting value (in this example, 2) will be used as theNthIPargument in thenetwork_file.

E N D O F S T E P S...................................................................................................................................................................................................


Determining the NthIP

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Move a 1xEV-DO cell (intra-RNC)...................................................................................................................................................................................................................................

Purpose

This procedure moves a 1xEV-DO cell from one FMS-AP pair to another FMS-AP pairon the same RNC (intra-RNC). The Source OMP and Target OMP are the same for anintra-RNC move.

Important! Mixed-mode EV-DO cells, that is, CDMA cells with EV-DO cells inthe same cell, may be moved by executing both the Inter-MSC Swing tools for theCDMA cells (seeInter-MSC Cell Swing,401-612-150) and the EV-DO Cell Swingtools for the EV-DO cells.

Important! Before performing an EVDO cell swing, contact the SecurityAdministrator to ensure that security settings for the cell site EVDO CDMs areproperly set before the swing occurs.

Required skills and personnel

This procedure is best performed by an expert system administrator.

Related documentation

For detailed information on Inter-MSC Cell Swing, seeInter-MSC Cell Swing,401-612-150.

For detailed information regarding 1xEV-DO Bulk Provisioning, see CDMA2000®

1xEV-DO Network EMS Configuration Management Bulk Provisioning Guide,401-614-325.

Prerequisites

To use the 1xEV-DO cell swing tools, you must have the following:

• root login access on the Operations & Maintenance Platform (OMP)

• In RRL on mode, you need to be a system administrator or you have to have theuser account access that is assigned thersysadm system administrator role.

• 1xEV-DO Cell Swing feature activated.

To use the Bulk Provisioning tool, you must have the following:

• Access to the OMP shell

• Appropriate permissions


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-29

Important! For information on setting up a login on the OMP, seeAlcatel-Lucent9271 EV-DO Radio Network Controller,401-614-102.

• In addition, certain EMS provisioning steps must be completed before attempting touse the Bulk Provisioning tool:

– The Service Node and Frame must already be known to EMS by havingcompleted the″AP Configuration″ process. (See the CDMA2000® 1xEV-DORadio Access System Planning and Implementation Guide,401-614-101).

– The Configuration Database must be installed and operational (see theCDMA2000® 1xEV-DO Radio Access System Planning and ImplementationGuide,401-614-101).

– Data supplied to the configuration database should meet the known parameterconfiguration guidelines. (See the CDMA2000® 1xEV-DO Radio Access SystemPlanning and Implementation Guide,401-614-101).

• Ensure that all systems are stable before attempting an actual cell move.

Procedure



...................................................................................................................................................................................................

1 Log on to the Source OMP asroot.

Important! EVDO Cell Swings need to be done asroot, and use a secured shellenvironment.

...................................................................................................................................................................................................

2 In the RRL off mode , log on to the database FMS-AP of the Source OMP and make abackup copy of the database as per standard procedures viadbunload. Run thiscommand in a new directory in the/app2 filesystem.

Important! /app2/DBbackup/swing<yyyymmdd>/ should be created and used asthe destination for the database backup.

For backup procedures, seeAlcatel-Lucent 9271 EV-DO Radio Network Controller,401-614-102.

In the RRL on mode , log on to the database FMS-AP with a user account andassumersysadm role. Choose a directory underrsysadm home /roles/rsysadm/dbbackup.


Move a 1xEV-DO cell (intra-RNC)

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Important! If this directory does not exist, then it should be created:




...................................................................................................................................................................................................

3 Log off of the DO-RNCAPs (returning to the OMP).

...................................................................................................................................................................................................

4 Skip this step if no network changes are being made. Otherwise, back up the networkfiles that may/will be modified on the lead FMS-APs.

In RRL off mode:

1. Log on to AP01 asonexev

2. mkdir -p /app2/swing/<yyyymmdd>/scripts

3. mkdir -p /app2/swing/<yyyymmdd>/backup

4. cd /app2/swing/<yyyymmdd>/backup

5. cp /etc/netmasks /app2/swing/<yyyymmdd>/backup

6. cp /var/dhcp/* /app2/swing/<yyyymmdd>/backup

7. Repeat Substeps1 - 6 for AP02

8. Log off all DO-RNC APs

In RRL on mode:

1. Log on to AP01 as with the a user login

2. mkdir -p /<home_DIR>/<login_ID>/swing/<yyyymmdd>/scripts

3. mkdir -p /<home_DIR>/<login_ID>/swing/<yyyymmdd>/backup

4. Log on to AP01 as user login account and create a swing dir under the loginaccount.cd /<home_DIR>/<login_ID>/swing/<yyyymmdd>/backup

5. cp /etc/netmasks /<home_DIR>/<login_ID>/swing/<yyyymmdd>/backup

6. cp /var/dhcp/* /<home_DIR>/<login_ID>/swing/<yyyymmdd>/backup


8. Log off all DO-RNC APs

Result: Temporary directories for the scripts and for saving a backup copy of thenetwork files are created. Backup copies of the/etc/netmasksfiles and of the entire/var/dhcp/* directory are made. Note that the scripts directory will be used later.

...................................................................................................................................................................................................

5 Repeat Main ProcedureStep 1-Step 3for the Neighboring OMPs/RNCs.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-31

...................................................................................................................................................................................................

6 On the OMP, make a temporary directory where the necessary input and output filesfor this procedure will be stored.

Example: mkdir -p /home/swing/<yyyymmdd>

Where: <yyyymmdd>is the date in year/month/day format.

Result: The temporary directories are created, wherein the input files will be storedand the cell swing tools will be run.

...................................................................................................................................................................................................

7 Change directory into the temporary directory just created.

Example: cd /home/swing/<yyyymmdd>

Result: The user is in the temporary directory.

...................................................................................................................................................................................................

8 Important! If the directory is already present, the tool will report that this is thecase. If there are problems creating the directory, or if a file (instead of directory)is already present, errors will print.

When creating the input files, use the exact syntax for the attributes. Capital lettersneed to be used where specified.

Create thecell_file, sn_file, andnetwork_fileinput files in the temporary directorycreated in Main ProcedureStep 6on the Source OMP. For file formatting instructions,refer to“cell_file file” (p. 3-12), “ sn_file file” (p. 3-13) , and“ network_file file”(p. 3-15).

Result: The user creates the input files to be used by the cell swing tools.

...................................................................................................................................................................................................

9 Important! Cell swing template files may be found in$cstempsafter the BPenvironment is enabled for theroot user.

The temporary directory fromStep 6is now defined as$bpPath.

Enable the BP tools environment.

Example:

1. exec /usr/bin/ksh

2. . BP_user_setup

3. Enter: Y



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Result: The BP tools environment is enabled.

...................................................................................................................................................................................................

10 On the OMP in the temporary directory,

Enter: evdodump -d evdo_dumpdir -i cell_file

Where:





Result: An explanation of what will be done is displayed and the user is prompted:″Are you ready to run 1xEV-DO Bulk-Provisioning commands via ’runBP’

(y/n)?″

...................................................................................................................................................................................................

11 At the prompt,

Enter: Y

Result: The evdodump tool continues running on the OMP.

...................................................................................................................................................................................................

12 When prompted for the Service Node OMP, enters (for ″Source″).

...................................................................................................................................................................................................

13 For EMS GUI Users : Enter the Service Node ID (SNID) for the OMP. If you do notknow the SNID, access the EMS GUI for the OMP, click the Configuration Data icon,and click the Service Nodes link.

Important! Once the SNID is entered, therunBP tool is automatically entered andmay run for several minutes, depending on how many cells and Neighbor lists arebeing dumped.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-33

Result: The SNID for the OMP is displayed if needed and entered. TherunBP toolthen automatically extracts the information needed from the Source system.

For OMC-RAN Users or BP Users: Enter the Service Node ID (SNID) for theOMP. If you do not know the SNID, setup your Bulk Provisioning environmentand then execute the following command:

Enter: runBP -C ’output stored ServiceNode’ | grep hdrsnId

...................................................................................................................................................................................................

14 If the cell to be moved has Neighbors on other RNCs or different SNs, log into theNeighbor OMP(s) and enterStep 6- Step 12(run evdodump for those systems,specifying the appropriate SN type (n for Neighbor) in Main ProcedureStep 12.

Result: The evdodump tool is run for all Neighboring OMPs for which a handoffcan occur.

...................................................................................................................................................................................................

15 Transfer the files generated for the Neighbor OMPs to the temporary directory (createdin Step 6) on the Source OMP viasftp.

Important! If you cannotsftp as theroot user, use theomptech login and putthe files in /tmp. Go back to the Source OMP and copy the transferred files from/tmp to $bpPath

...................................................................................................................................................................................................

16 At the prompt,

Enter: evdoswing -d evdo_dumpdir -i cell_file -s sn_file [-v]

Where:


cell_file user-created network input file



Result: The evdoswing script files for deleting and adding the cell components arecreated, along with the replace scripts for updating the Neighbor sectors on otherRNCs/SNs.

...................................................................................................................................................................................................

17 Skip to Step 27if no networking changes are being made. Otherwise, run theevdomkdir tool.



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Example: evdomkdir -d evdo_dumpdir -i network_file -s sn_file

Result: A directory structure is created to be used when transferring the networkfiles.

...................................................................................................................................................................................................

18 On the OMP, go to the Source SNID/Frame ID directory that was created byevdomkdir.

Example:

cd $bpPath/sXXX/fYY

Where:



Result: A directory structure to be used when transferring the network files iscreated.

...................................................................................................................................................................................................

19 In RRL off mode start a sftp to AP01 asonexev.

In RRL on mode start a sftp to AP01 as login user.

...................................................................................................................................................................................................

20 Go to thedhcpdirectory and get a copy of theSUNWfiles1_dhcptabfile.

Example:

1. cd /var/dhcp

2. get SUNWfiles1_dhcptab

Result: Copy of theSUNWfiles1_dhcptabfile is obtained.

...................................................................................................................................................................................................

21 Go to the/etc directory and get a copy of thenetmasksfile.

Example:

1. cd /etc

2. get netmasks

Result: Copy of theSource netmasksfile is obtained.

...................................................................................................................................................................................................

22 Exit sftp by enteringbye or quit and pressing theEnter key.

...................................................................................................................................................................................................

23 At the prompt,



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-35

Enter: cd $bpPath

...................................................................................................................................................................................................

24 At the prompt,

Enter: evdonetwork -n evdo_dumpdir -i network_file -s sn_file

Where:




Result: The evdonetwork script files for deleting, creating, and adding the networkcomponents are created.

...................................................................................................................................................................................................

25 Important! Add scripts using eitherput or mput commands.

Transfer the network addition, creation, and deletion scripts (T1, dhcp, netmasks) to thefirst two FMS-APs in the cluster and make them executable.

Where:



In RRL off mode:

1. cd $bpPath/sXXX/fYY

2. Start ansftp to AP01 asonexev

3. cd /app2/swing/<yyyymmdd>/scripts

4. Transfer the scripts usingsftp

5. Exit sftp by enteringbye or quit; press theEnter key

6. Repeat Substeps 2 - 5 for AP02, but entern for the files that begin withnetmsk,as these files are not needed on AP02

7. cd $bpPath

In RRL on mode:


2. Start ansftp to AP01 as login user account

3. cd /<home_DIR>/<login_ID>/swing/<yyyymmdd>/scripts




...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


6. Repeat Substeps2 - 5 for AP02, but entern for the files that begin withnetmsk,as these files are not needed on AP02

7. cd $bpPath

Result: The network deletion scripts are transferred to the first two FMS-APs inthe cluster.

...................................................................................................................................................................................................

26 Change permissions on the script files.

In RRL off mode:



3. chmod +x *

4. Log off of AP01


In RRL on mode:

1. Log on to AP01 as login user


3. chmod +x *

4. Log off of AP01


Result: The network addition and deletion scripts are made executable.

...................................................................................................................................................................................................

27 Important! If you cannotsftp as theroot user, use theomptech and put the filesin /tmp. Go back to the Source OMP and copy the transferred files from/tmp to$bpPath.

If they were generated, transfer the Neighbor sector replacement scripts viasftp fromthe temporary directory on the Source OMP to the temporary directory created on theNeighboring OMPs whereevdodump was run.

Sample filename:NeighborSectorXXXYYReplace<BPfile#>

Where: XXX = three-digit value for the Service Node ID




...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-37

Result: The scripts used to update the Neighbor sectors on Neighboring RNCs/SNsare transferred.

...................................................................................................................................................................................................

28 Important! If the -V is omitted, the script will be executed.

Do not proceed if any script execution reports an error or is not″OK!″

Run each script individually in validate mode (-V) to confirm syntax.

Example: runBP -i -O /omp-data/logs/evdotools/runBPmmddyyyy.log -A -V scriptname

Where:

scriptname is in the format

<element><SNID><FMSID>Add<BPfile#>

<element><SNID><FMSID>Delete<BPfile#>

<element><SNID><FMSID>Replace<BPfile#>

NeighborSector<SNID><FMSID>Replace<BPfile#> (run on Neighboring OMPs)

...................................................................................................................................................................................................

29 Take only the EVDO CDMs unconditionally out of service (OOS) to divert call traffic.Repeat this Step for all the CDMs in a multicarrier cell.

Example:

TICLI> rmv:cell #, cdm <CDM ID>, crc; ucl

Result: The EVDO CDM is OOS and call traffic diverted.

...................................................................................................................................................................................................

30 Important! Do not proceed if any script execution reports an error or is not″OK!″

Run the BP Delete scripts, found in the/home/swing/<yyyymmd> directory, in normalmode (without the-V command line parameter) in degrowth order on the Source OMPfor the cell components.

Refer to the Degrowth Table,“Forms and key fields” (p. 3-11)for the degrowth orderon the Source OMP for the cell components. For more information on BP, seeCDMA2000® 1xEV-DO EMS Configuration Management Bulk Provisioning,401-614-325.

Example:

runBP -i -O /omp-data/logs/evdotools/runBPmmddyyyy.log -A <element><SNID><FMSID>Delete<BPfile#>



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Result: The cell is deleted from the database of the Source RNC.

...................................................................................................................................................................................................

31 If no network changes were made, skip toStep 33. Otherwise, run the deletion scriptsasroot on the first two DO-RNC-APs.

Where:



In RRL off mode:

1. Log on to AP01 asonexev and become theroot user(su - root)


3. Run thet1 deletion script ./t1fileDelXXXYY

4. Run thedhcpdeletion script ./dhcpDelXXXYY


6. Log off of AP02

7. Log on to AP01 asroot and run thenetmasksdeletion script:

/flx/ONEXEVc/current/release/tools/cfg/modifyNetmasks DELETE < /app2/swing/<yyyymmdd>/scripts/netmskDelXXXYY

8. Stop and restart DHCP on AP01 (asroot):

/etc/init.d/dhcp stop

/etc/init.d/dhcp start

9. Log off of AP01.

10. Log on to AP02 and repeat Substep 8.

11. Log off of AP02 and log back onto the OMP asroot.

In RRL on mode:

1. Log on to AP01 as login user and assumersysadm role

2. cd /flx/ONEXEVc/current/release/tools/cfg

3. Run thet1 deletion script./bpproxy /<home_DIR>/<login_ID>/swing/<yyyymmdd>/scripts/t1fileDelXXXYY

4. Run thedhcpdeletion script./bpproxy /<home_DIR>/<login_ID>/swing/<yyyymmdd>/scripts/dhcpDelXXXYY


6. Log off of AP02



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-39

7. Log on to AP01 as login user and assumersysadm and run thenetmasksdeletion script:

/flx/ONEXEVc/current/release/tools/cfg/modifyNetmasks DELETE < /<home_DIR>/<login_ID>/swing/<yyyymmdd>/scripts/netmskDelXXXYY

8. Stop and restart DHCP on AP01:



9. Log off of AP01.

10. Log on to AP02, assumersysadm role and repeat Substep 8.


Result: The network entries for the cell being moved are deleted from the SourceRNC.

...................................................................................................................................................................................................

32 Make any applicable network changes to support the cell swing (for example,(multiple) router changes between the cell and the Source/Target FMS-APs).

...................................................................................................................................................................................................


On the OMP, run the BP Add scripts (not in validate mode...remove the -V commandline parameter) in growth order on the Target OMP for the cell components.

Refer to the Growth Table,“Forms and key fields” (p. 3-11)for the growth order onthe Target OMP for the cell components. For more information on BP, see CDMA2000® 1xEV-DO EMS Configuration Management Bulk Provisioning,401-614-325.

Example:

runBP -i -O /omp-data/logs/evdotools/runBPmmddyyyy.log -A <element><SNID><FMSID>Add<BPfile#>

Result: The cell is added back into the database.

...................................................................................................................................................................................................

34 If no network changes were made, skip to the next Step. Otherwise,run the networkaddition and creation scripts asroot on the first two FMS-APs.

Where:



In RRL off mode:





...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

3. Run thenetmasksaddition script

/flx/ONEXEVc/current/release/tools/cfg/modifyNetmasks ADD < /app2/swing/<yyyymmdd>/scripts/netmskAddXXXYY

4. Run thedhcpaddition script ./dhcpAddXXXYY

5. Run thet1 creation script ./t1fileCrtXXXXYY

6. Run thet1 addition script ./t1entryAddXXXYY

7. Repeat Substeps1 - 2 and 4 - 6 forAP02

8. Log off of AP02




10. Log off of AP01.

11. Log on to AP02 and repeat Substep 9

12. Log off of AP02 and log back onto the OMP asroot

In RRL on mode:

1. Log on to AP01 as user account and assumersysadm role



/flx/ONEXEVc/current/release/tools/cfg/modifyNetmasks ADD < /<home_DIR>/<login_ID>/swing/<yyyymmdd>/scripts/netmskAddXXXYY

4. Run thedhcpaddition script./bpproxy <home_DIR>/<login_ID>/<yyyymmdd>/scripts/dhcpAddXXXYY

5. Run thet1 creation script./bpproxy <home_DIR>/<login_ID>/<yyyymmdd>/scripts/t1fileCrtXXXYY

6. Run thet1 addition script./bpproxy <home_DIR>/<login_ID>/<yyyymmdd>/scripts/t1entryAddXXXYY


8. Log off of AP02





11. Log on to AP02, assumersysadm role and repeat Substep 9




...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-41


...................................................................................................................................................................................................

35 If they were generated, run the BP Neighbor Sector Replace scripts on all of theNeighboring OMPs to update the Neighbor sectors on the Neighbor FMS-APs.

Example:

runBP -i -O /omp-data/logs/evdotools/runBPmmddyyyy.log -A

NeighborSectorXXXYYReplace<BPfile#>

Where:

NeighborSectorXXXYYReplace<BPfile#> contains:



Result: The Neighbor sectors on the Neighboring SNs/OMPs are updated for thecell that has been moved.

...................................................................................................................................................................................................

36 Restore the CDM from theTICLI. Restore each of the CDMs in case of a multi-carriercell.

Example:

TICLI> rst:cell #, cdm <CDM ID>, crc; ucl

...................................................................................................................................................................................................

37 Wait for the cell to come up on the new FMS-AP pair. Monitor the cell status fromwhichever interface is appropriate: EMS GUI if the RNC is EMS managed, or theOMC-RAN GUI if the RNC is managed by the OMC-RAN.

Important! The cell may take up to 30 minutes to come up, as the cell has tocome up either on a new system, with a new name, or both. If the cell does notcome up after 30 minutes, contact WTSC for further assistance.

...................................................................................................................................................................................................

38 Enter the“Verify OA&M on moved and/or renamed converged cell” (p. 3-129)procedure.

...................................................................................................................................................................................................

39 Verify successful cell move by placing a call on the new cell. Start a continuous pingto a good system, and perform handoffs across the faces of the cell.



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Result: A call is placed and intra-cell handoffs are completed.

...................................................................................................................................................................................................

40 If a Neighbor cell is available, start a new session on the moved cell and perform threeactive handoffs between the moved cell and a Neighbor cell.

Result: Handoffs between the moved cell and the Neighbor cell are done.

...................................................................................................................................................................................................

41 After 5 days of verified stability, enter the“Cleanup of old Cell Swing files” (p. 3-134)procedure.

E N D O F S T E P S...................................................................................................................................................................................................



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-43

Move a 1xEV-DO cell (inter-RNC/Same Service Node)...................................................................................................................................................................................................................................

Purpose

This procedure moves a 1xEV-DO cell from an FMS-AP pair on one RNC to anotherFMS-AP pair on another RNC (inter-RNC move). Source and Target OMPs may bedifferent (inter-SN).

Important! Mixed-mode EV-DO cells, that is, CDMA cells with EV-DO cells inthe same cell, may be moved by executing both the Inter-MSC Swing tools for theCDMA cells (seeInter-MSC Cell Swing,, 401-612-150) and the EV-DO CellSwing tools for the EV-DO cells.







1xEV-DO EMS Configuration Management Bulk Provisioning Guide,401-614-325.

Prerequisites








Important


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

For information on setting up a login on the OMP, seeAlcatel-Lucent 9271 EV-DORadio Network Controller,401-614-102.




– Data supplied to the configuration database should meet the known parameterconfiguration guidelines. (See the CDMA2000® 1xEV-DO ConfigurationsParameters Guide,401-614-324).


Procedure



...................................................................................................................................................................................................


Important! For an Inter-RNC Cell Swing, the DO-RNCs need to have the sameload.

...................................................................................................................................................................................................






Move a 1xEV-DO cell (inter-RNC/Same Service Node)

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-45





...................................................................................................................................................................................................

3 Log off of the FMS-APs (returning to the OMP).

...................................................................................................................................................................................................

4 Back up the network files that may/will be modified on the lead FMS-APs.

In RRL off mode:







7. Repeat Substeps 1 - 6 for AP02

8. Log off all FMS-APs

In RRL on mode:

1. Log on to AP01 as login account



4. cd /<home_DIR>/<login_ID>/swing/<yyyymmdd>/backup

5. cp /etc/netmasks /<home_DIR>/<login_ID>/<yyyymmdd>/backup





...................................................................................................................................................................................................

5 Repeat Main ProcedureStep 2- Step 4for the Target DO-RNC.



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

...................................................................................................................................................................................................

6 Repeat Main ProcedureStep 1- Step 3for the Neighboring OMPs (SNs) withDO-RNCs.

...................................................................................................................................................................................................

7 ThroughTICLI, obtain list of active generics on the cells being moved.

Example:

TICLI

TICLI> op:cell #,generic

TICLI> quit

Result: A list of active generics on the cells are displayed and sent to the ROP andthe TICLI session is terminated.

...................................................................................................................................................................................................

8 Confirm Target RNC’s cell generic:

1. Log on to the Target FMS-AP

2. cd /flx/ONEXEVc/versions

3. ls -d cell_generic

Where: cell_generic is the name of the active generic obtained from theop:bts #,generic command entered in Main ProcedureStep 7

4. If generic is the same as the Source OMP, then this sub-procedure is complete.Go to Step 9.

If the result is:cell_generic: No such file or directory then install thesame generic as is found on the Source OMP on the Target OMP’s system. SeeSection 8, ofAlcatel-Lucent 9271 EV-DO Radio Network Controller,401-614-102,for cell generic installation procedures.

...................................................................................................................................................................................................

9 On the Source OMP, make a temporary directory where the necessary input and outputfiles for this procedure will be stored.


Where: <yyyymmdd> is the date in year/month/day format.


...................................................................................................................................................................................................




...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-47



...................................................................................................................................................................................................

11 Create thecell_file, sn_file, andnetwork_fileinput files in the temporary directorycreated in Main ProcedureStep 9on the Source OMP. For file formatting instruction,refer to“cell_file file” (p. 3-12), “ sn_file file” (p. 3-13), and“ network_file file”(p. 3-15).

Important! If the directory is already present, the tool will report that this is thecase. If there are problems creating the directory, or if a file (instead of directory)is already present, errors will print.

Result: The user creates the input files to be used by the cell swing tools

...................................................................................................................................................................................................

12 Important! The BP tool requires ksh (Korn Shell) to be running.

Cell swing template files may be found in$cstemps after the BP environment isenabled for theroot user.



Example:


2. . BP_user_setup

3. Enter: Y


...................................................................................................................................................................................................

13 In the temporary directory,

Example: evdodump -d evdo_dumpdir -i cell_file

Where:







...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


(y/n)?″

...................................................................................................................................................................................................

14 At the prompt,

Enter: Y


...................................................................................................................................................................................................

15 When prompted, enters (for ″Source″).

...................................................................................................................................................................................................






...................................................................................................................................................................................................

17 At the prompt,

Enter: Y


...................................................................................................................................................................................................

18 When prompted for the Service Node OMP, entert (for ″Target″)

...................................................................................................................................................................................................

19 If the cell to be moved has Neighbors on other RNCs or different SNs, log into theNeighbor OMP(s) and enter Main ProcedureStep 9-Step 16(run evdodump for thosesystems, specifying the appropriate SN type (n for Neighbor) inStep 15.

Important! If no Neighbors, skip toStep 21.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-49


...................................................................................................................................................................................................

20 Transfer the files generated for the Neighbor OMPs to the temporary directory (createdin Main ProcedureStep 9) on the Source OMP viasftp.

Important! If you cannotsftp as theroot user, use theomptech login and put thefiles in /tmp. Go back to the Source OMP and copy the transferred files from/tmpto $bpPath.

...................................................................................................................................................................................................

21 Enter:


Where:






...................................................................................................................................................................................................

22 Run theevdomkdir tool.

Example:

evdomkdir -d evdo_dumpdir -i network_file -s sn_file

Where:






...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


...................................................................................................................................................................................................


Example:

cd $bpPath/sXXX/fYY




...................................................................................................................................................................................................


In RRL on mode start a sftp to AP01 a user account.

...................................................................................................................................................................................................


Example:

1. cd /var/dhcp



...................................................................................................................................................................................................


Example:

1. cd /etc

2. get netmasks

Result: Copy of netmasksfile is obtained.

...................................................................................................................................................................................................


...................................................................................................................................................................................................

28 Repeat Main ProceduresStep 23andStep 27for the Target RNC, replacing alloccurrences of Source with Target.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-51

...................................................................................................................................................................................................

29 At the prompt,

Enter: cd $bpPath

...................................................................................................................................................................................................

30 At the prompt,

Enter:evdonetwork -n evdo_dumpdir -i network_file -s sn_file

Where:





...................................................................................................................................................................................................


Transfer the network deletion scripts (T1, dhcp, netmasks) to the first two FMS-APs ofthe Source system.

Where:



Example:







7. cd $bpPath



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


...................................................................................................................................................................................................

32 Transfer the network addition and creation scripts (T1, dhcp, netmasks) to the first twoFMS-APs of the Target system.

Important! If the Target RNC is on a different OMP, the creation and additionscripts will have to be transferred to the$bpPath directory of the Target OMP.After that, they can then be transferred to the first two FMS-APs of the Targetsystem.

Add scripts using eitherput or mput commands.

Where:



In RRL off mode:







7. cd $bpPath

In RRL on mode:







7. cd $bpPath


...................................................................................................................................................................................................

33 Change permissions on the script files (transferred inStep 31for the Source RNC).



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-53

In RRL off mode:



3. chmod +x *

4. Log off of AP01


In RRL on mode:



3. chmod +x *

4. Log off of AP01


Result: The network deletion scripts are made executable.

...................................................................................................................................................................................................

34 Change permissions on the script files (transferred inStep 32for the Target RNC).

Example:



3. chmod +x *

4. Log off of AP01



...................................................................................................................................................................................................

35 Important! If you cannotsftp as theroot user, use theomptech login and put thefiles in /tmp. Go back to the Source OMP and copy the transferred files from/tmpto $bpPath.







...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


...................................................................................................................................................................................................



Run each script individually in validate mode (-V) to confirm syntax.

Example:

runBP -i -O /omp-data/logs/evdotools/runBPmmddyyyy.log -A -Vscriptname

Where:






...................................................................................................................................................................................................

37 Take the 1xEV-DO CDMs unconditionally out of service (OOS) to divert call traffic.Repeat this Step for all the CDMs in a multicarrier cell.

Example:


...................................................................................................................................................................................................


Run the BP Delete scripts, found in the/home/swing/<yyyymmdd> directory, in normalmode (without the-V command line parameter) in degrowth order on the Source OMPfor the cell components.


Example:




...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-55


...................................................................................................................................................................................................

39 Run the deletion scripts asroot on the first two Source FMS-APs.

Where:



In RRL off mode:






6. Log off of AP02


/flx/ONEXEVc/current/release/tools/cfg/modifyNetmasks DELETE

</app2/swing/<yyyymmdd>/scripts/netmskDelXXXYY




9. Log off of AP01.



In RRL on mode:






6. Log off of AP02




...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008





9. Log off of AP01.




...................................................................................................................................................................................................


...................................................................................................................................................................................................


Run the BP Add scripts (not in validate mode, remove the -V command line parameter)in growth order on the Target OMP for the cell components.

Refer to the Growth Table,“Forms and key fields” (p. 3-11)for the growth order onthe Target OMP for the cell components. For more information on BP, see CDMA2000® 1xEV-DO EMS Configuration Management Bulk Provisioning,401-614-325.

Example:

runBP -i -O /omp-data/logs/evdotools/runBPmmddyyyy.log -A<element><SNID><FMSID>Add<BPfile#>

Result: The cell is added into the database of the Target RNC.

...................................................................................................................................................................................................

42 Run the network addition and creation scripts asroot on the first two TargetFMS-APs.

Where:



In RRL off mode:



3. Run thenetmasksaddition script:



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-57





7. Repeat Substeps 1 - 2 and 4 - 6 for AP02

8. Log off of AP02







In RRL on mode:





4. Run thedhcpaddition script./bpproxy <home_DIR>/<login_ID>/swing/<yyyymmdd>/scripts/dhcpAddXXXYY

5. Run thet1 creation script./bpproxy <home_DIR>/<login_ID>/swing/<yyyymmdd>/scripts/t1fileCrtXXXYY

6. Run thet1 addition script./bpproxy <home_DIR>/<login_ID>/swing/<yyyymmdd>/scripts/t1entryAddXXXYY


8. Log off of AP02









...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Result: The network entries for the cell being moved are deleted from the TargetRNC.

...................................................................................................................................................................................................


Example:



Where: NeighborSectorXXXYYReplace<BPfile#> contains:




...................................................................................................................................................................................................

44 Restore the CDM from theTICLI. Restore each of the CDMs in case of a multi-carriercell.

Example:


...................................................................................................................................................................................................



...................................................................................................................................................................................................


...................................................................................................................................................................................................




...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-59


...................................................................................................................................................................................................



...................................................................................................................................................................................................


E N D O F S T E P S...................................................................................................................................................................................................



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Move a converged 1xEV-DO cell (inter-RNC/Different ServiceNode)...................................................................................................................................................................................................................................

Purpose

This procedure moves a converged 1xEV-DO Modular Cell from one FMS-AP pair toanother FMS-AP pair on a different service node RNC (inter-RNC).

Important! Mixed-mode EV-DO cells, that is, CDMA modular cells with EV-DOcells in the same cell, may be moved by executing both the Inter-MSC Swing toolsfor the CDMA cells (see 401-612-150,Inter-MSC Cell Swing) and the EV-DO CellSwing tools for the EV-DO cells.







1xEV-DO Network EMS Configuration Management Bulk Provisioning Guide,401-614-325.

Prerequisites








Important


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-61



– The Service Node and Frame must already be known to EMS by havingcompleted the″AP Configuration″ process. (See the CDMA2000® 1xEV-DORadio Access System Planning and Implementation Guide,401-614-101.

– The Configuration Database must be installed and operational (see theCDMA2000® 1xEV-DO Radio Access System Planning and ImplementationGuide,401-614-101.

– Data supplied to the configuration database should meet the known parameterconfiguration guidelines. (See the CDMA2000® 1xEV-DO NetworkConfigurations Parameters Guide,401-614-324).


Procedure



...................................................................................................................................................................................................


Important! For inter-RNC Cell Swing, the DO-RNCs need to have the same load.RCS-APs (CDMA) also need to have the same load.

...................................................................................................................................................................................................






Move a converged 1xEV-DO cell (inter-RNC/DifferentService Node)

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008





...................................................................................................................................................................................................


...................................................................................................................................................................................................


In RRL off mode:









In RRL on mode:




4. cd /<home_DIR>/<login_ID>/<yyyymmdd>/backup






...................................................................................................................................................................................................

5 Repeat Main ProcedureStep 1-Step 4for the Target OMPs.

...................................................................................................................................................................................................

6 Repeat Main ProcedureStep 1- Step 3for the Neighboring OMPs.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-63

...................................................................................................................................................................................................

7 ThroughTICLI, obtain list of active generics on the cells being moved.

Example: TICLI

TICL> op:cell #,generic

TICLI> quit


...................................................................................................................................................................................................

8 Confirm Target RNC’s cell genericConfirm Target RNC’s cell generic:

1. Log on to Target FMS-AP

2. cd /flx/ONEXEVcs/versions


Where: cell_generic is the name of the active generic obtained from theop:cell #,generic command entered in main procedureStep 7.

4. If generic is the same as the Source OMP, then this sub-procedure is complete.Go to Step 9.

If result is: cell_generic: No such file or directory then install the samegeneric as is found on the Source OMP on the Target OMP’s system. See Section8, of Alcatel-Lucent 9271 EV-DO Radio Network Controller,401-614-102, for cellgeneric installation procedures.

...................................................................................................................................................................................................

9 On the Source OMP, make a temporary directory where the necessary input and outputfiles for this procedure will be stored.



Result: The temporary directories are created, wherein the input files are storedand the cell swing tools will be run.

...................................................................................................................................................................................................




...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008



...................................................................................................................................................................................................

11 Important! If the directory is already present, the tool will report that this is thecase. If there are problems creating the directory, or if a file (instead of directory)is already present, errors will print.

If this is the Target OMP, just copy the cell_file file from the Source OMP to theTarget OMP. Do not create any other files on the Target OMP.

Create thecell_file, sn_file, andnetwork_fileinput files in the temporary directorycreated in Main ProcedureStep 9on the Source OMP. For file formatting instructions,refer to“cell_file file” (p. 3-12), “ sn_file file” (p. 3-13), and“ network_file file”(p. 3-15).


...................................................................................................................................................................................................



The temporary directory fromStep 9is now defined as$bpPath


Example:


2. . BP_user_setup

3. Enter: Y


...................................................................................................................................................................................................

13 Important! Parameter -c is not optional.

On the Source OMP, in the temporary directory,


Where:





...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-65




(y/n)?″

...................................................................................................................................................................................................

14 At the prompt,

Enter: Y


...................................................................................................................................................................................................

15 When prompted for the Service Node OMP, enters (for ″Source″), t (for ″Target″), orn (for ″Neighbor″) as appropriate.

...................................................................................................................................................................................................






...................................................................................................................................................................................................

17 Repeat Main ProcedureStep 9- Step 16on the Target OMP, then transfer thefollowing files back to the temporary directory created inStep 9on the Source OMP:

Example: APXXX.txtNeighborSectorXXXYY.txt

Where: XXX = Target SN ID

YY = Target Frame ID



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

...................................................................................................................................................................................................

18 If the cell to be moved has Neighbors on other RNCs or different SNs, log into theNeighbor OMP(s) and enter Main ProcedureStep 9- Step 16(run evdodump for thosesystems, specifying the appropriate SN type (n for Neighbor) in Main ProcedureStep15 .

Important! If no Neighbors, skip to Step Important!


...................................................................................................................................................................................................

19 Transfer the files generated for the Neighbor OMPs to the temporary directory (createdin Main Procedure Step 9) on the Source OMP viasftp.


...................................................................................................................................................................................................

20 On the Source OMP, enter:


Where:






...................................................................................................................................................................................................

21 On the Source OMP, run theevdomkdir tool.

Example:




...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-67

Where:





...................................................................................................................................................................................................

22 On the Source OMP, go to the Source SNID/Frame ID directory that was created byevdomkdir

Example:

cd $bpPath/sXXX/fYY

Where:




...................................................................................................................................................................................................



...................................................................................................................................................................................................


Example:

1. cd /var/dhcp



...................................................................................................................................................................................................


Example:

1. cd /etc

2. get netmasks



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Result: Copy of thenetmasksfile is obtained.

...................................................................................................................................................................................................


...................................................................................................................................................................................................

27 Repeat Main ProcedureStep 22-Step 26for the Target OMP, replacing all occurrencesof Source with Target.If the Target OMP is different, save the files on the Target OMPin $bpPath directory and transfer the network files viasftp to the appropriatedirectory ($bpPath/s<TargetSNID>/f<TargetFrameID>) on the Source OMP.

...................................................................................................................................................................................................

28 On the Source OMP,

Enter: cd $bpPath

...................................................................................................................................................................................................


Example: evdonetwork -n evdo_dumpdir -i network_file -s sn_file

Where:





...................................................................................................................................................................................................



Where:



In RRL off mode:






...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-69




7. cd $bpPath

In RRL on mode:







7. cd $bpPath


...................................................................................................................................................................................................

31 Transfer the network addition and creation scripts (T1, dhcp, netmasks) to the first twoFMS-APs of the Target system.

Important! If the Target RNC is on a different OMP, the creation and additionscripts will have to be transferred to the$bpPath directory of the Target OMP.After that, they can then be transferred to the first two FMS-APs of the Targetsystem.


Where:



In RRL off mode:









...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

7. cd $bpPath

In RRL on mode:







7. cd $bpPath


...................................................................................................................................................................................................

32 Change permissions on the script files for the Source RNC.

In RRL off mode:



3. chmod +x *

4. Log off of AP01


In RRL on mode:



3. chmod +x *

4. Log off of AP01



...................................................................................................................................................................................................

33 Change permissions on the script files for the Target RNC.

Example:



3. chmod +x *



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-71

4. Log off of AP01



...................................................................................................................................................................................................

34 Transfer the Add scripts to the Target OMP,/home/swing/<yyyymmdd>

...................................................................................................................................................................................................







...................................................................................................................................................................................................



On the Source OMP, run the Delete scripts in validate (-V) mode to confirm syntax.

Example:


Where:



...................................................................................................................................................................................................



On the Target OMP, run the BP Add and Replace scripts in validate (-V) mode.



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Example:


Where:




...................................................................................................................................................................................................



If they were generated, run the Neighbor OMP, run the NeighborSector Replace scriptsin validate (-V) mode, on the neighboring MOPs.

Example:

runBP -i -O /omp-data/logs/evdotools/runBPmmddyyyy.log -A -V


Where:




...................................................................................................................................................................................................

39 Take the 1xEV-DO CDMs unconditionally out of service (OOS) to divert call traffic.Repeat this Step for all the CDMs in a multicarrier cell.

Example:


...................................................................................................................................................................................................


On the Source OMP, run the BP Delete scripts, found in the/home/swing/<yyyymmdd>directory, in normal mode (without the-V command line parameter) in degrowth orderon the Source OMP for the cell components.




...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-73

Example:

runBP -i -O /omp-data/logs/evdotools/runBPmmddyyyy.log -A<element><SNID><FMSID>Delete<BPfile#>


...................................................................................................................................................................................................

41 On the Source OMP, run the deletion scripts asroot on the first two SourceFMS-APs.

Where:



In RRL off mode:






6. Log off of AP02






9. Log off of AP01.



In RRL on mode:







...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


6. Log off of AP02






9. Log off of AP01.




...................................................................................................................................................................................................

42 Make any applicable network changes to support the cell swing (for example,(multiple) router changes between the cell and the Source/Target FMS-APs). Refer to“Issues and caveats” (p. 3-22)for more information.

Important! Prior to entering the BP ADD scripts, the CDMA portion of the cellshould be swung, up and made operational.

...................................................................................................................................................................................................


Run the BP Add scripts (not in validate mode remove the-V command line parameter)in growth order on the Target OMP for the cell components.

Refer to the Growth Table,“Forms and key fields” (p. 3-11)for the growth order onthe Target OMP for the cell components. For more information on BP, seeCDMA2000® 1xEV-DO EMS Configuration Management Bulk Provisioning,401-614-325.

Example:


Result: The cell is added back into the database of the Target RNC.

...................................................................................................................................................................................................

44 If they were generated, run the network addition and creation scripts asrooton thefirst two Target FMS-APs of the Target OMP.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-75

Where:



In RRL off mode:









8. Log off of AP02







In RRL on mode:









8. Log off of AP02



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008







Result: The network entries for the cell being moved are deleted from the TargetRNC. START HERE

...................................................................................................................................................................................................


Example: runBP -i -O /omp-data/logs/evdotools/runBPmmddyyyy.log -A


Where: NeighborSectorXXXYYReplace<BPfile#> contains:




...................................................................................................................................................................................................

46 Restore the 1xEV-DO CDMs from theTICLI. Restore each of the CDMs in case of amulti-carrier cell.

Example:


...................................................................................................................................................................................................



...................................................................................................................................................................................................




...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-77

...................................................................................................................................................................................................



...................................................................................................................................................................................................

50 If a Neighbor cell is available, start a new session on the moved cell and perform threeactive handoffs between the moved cell and a Neighbor cell. This should be done forboth CDMA and EVDO.


...................................................................................................................................................................................................


E N D O F S T E P S...................................................................................................................................................................................................



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Rename a cell...................................................................................................................................................................................................................................

Purpose

This procedure renames a stand alone modular cell or the DO-side of a mixed-modemodular cell on the same RNC. The Source OMP and Target OMP are the same.



Prerequisites








Important






• Ensure that all systems are stable before attempting an actual cell rename.


For descriptions of service measurements for the Ethernet Interface Node (EIN), seeCDMA Network Service Measurements.,401-610-135, .


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-79


Procedure



...................................................................................................................................................................................................

1 Log on to the OMP asroot

...................................................................................................................................................................................................

2 In the RRL off mode , log on to the database FMS-AP and make a backup copy of thedatabase as per standard procedures viadbunload. Run this command in a newdirectory in the/app2 filesystem.








...................................................................................................................................................................................................


...................................................................................................................................................................................................

4 Backup the network files that may/will be modified on the lead FMS-APs.

In RRL off mode:






Rename a cell

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008





In RRL on mode:










...................................................................................................................................................................................................

5 Repeat Main Procedure Steps 1 - 3 for the Neighboring OMPs.

...................................................................................................................................................................................................

6 Make a temporary directory where the necessary input and output files for thisprocedure will be stored.




...................................................................................................................................................................................................




...................................................................................................................................................................................................

8 Create thecell_file, sn_file, andnetwork_fileinput files in the temporary directorycreated in Main ProcedureStep 6on the Source OMP. For file formatting instructions,refer to“cell_file file” (p. 3-12), “ sn_file file” (p. 3-13), and“ network_file file”(p. 3-15).


Rename a cell

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-81



...................................................................................................................................................................................................





Example:


2. . BP_user_setup

3. Enter: Y


...................................................................................................................................................................................................



Where:



-h prints the evdoswing command usage helpmessage


(y/n)?″

...................................................................................................................................................................................................

11 At the prompt,

y


Rename a cell

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


...................................................................................................................................................................................................


...................................................................................................................................................................................................






...................................................................................................................................................................................................

14 If the cell to be moved/renamed has Neighbors on other RNCs or SNs, log into theNeighbor OMP(s) and enter Main Procedure Steps 6 - 13 (runevdodump for thosesystems, specifying the appropriate SN type (n for Neighbor) in Step 12.


...................................................................................................................................................................................................

15 Transfer the files generated for those OMPs to the temporary directory (created in Step6) on the Source OMP.

...................................................................................................................................................................................................


Example: evdoswing -d evdo_dumpdir -i cell_file -s sn_file [-v]

Where:





Rename a cell

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-83

-v prints further details of evdoswing process(optional)

...................................................................................................................................................................................................


Example:


Where:





...................................................................................................................................................................................................

18 On the OMP, go to the Source SNID/Frame ID directory that was created byevdomkdir

Example:

cd $bpPath/sXXX/fYY

Where:


YY = three-digit value for the Frame ID


...................................................................................................................................................................................................



...................................................................................................................................................................................................


Example:

1. cd /var/dhcp


Rename a cell

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008



...................................................................................................................................................................................................


Example:

1. cd /etc

2. get netmasks


...................................................................................................................................................................................................


...................................................................................................................................................................................................


...................................................................................................................................................................................................

24 At the prompt,

cd $bpPath

...................................................................................................................................................................................................

25 If no network changes are being made, skip to Main ProcedureStep 28. Otherwise,


Where:




Result: The dhcp, netmask,and t1 deletion, creation, and addition scripts arecreated.

...................................................................................................................................................................................................




Rename a cell

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-85

Where:



In RRL off mode:







7. cd $bpPath

In RRL on mode:







7. cd $bpPath


...................................................................................................................................................................................................


In RRL off mode:



3. chmod +x *

4. Log off of AP01


In RRL on mode:




Rename a cell

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

3. chmod +x *

4. Log off of AP01



...................................................................................................................................................................................................

28 If they were generated, transfer the Neighbor sector replacement scripts from thetemporary directory on the Source OMP to the temporary directory created on theNeighboring OMPs whereevdodump was run.





...................................................................................................................................................................................................



Run each script individually in validate (-V) mode to confirm syntax.

Example: runBP -i -O /omp-data/logs/evdotools/runBPmmddyyyy.log -A -V scriptname

Where:





...................................................................................................................................................................................................

30 If they were generated, on the Neighbor OMP, run the NeighborSector Replace scriptsin validate (-V) mode.

Important! If the -V is omitted, the script will be executed.


...................................................................................................................................................................................................

31 Take the cell unconditionally out of service (OOS) to divert call traffic.

Example:

TICLI> rmv:cell # <BTS ID>, cdm <CDM ID>, crc; ucl


Rename a cell

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-87

Result: The cell is OOS and call traffic diverted.

...................................................................................................................................................................................................

32 While still in TICLI, inhibit audits on the cell being renamed.

Example:

TICLI>inh:bts old#, aud maint

TICLI>inh:bts old#, aud config

TICLI> quit

...................................................................................................................................................................................................


Run the BP Delete scripts, found in the/home/swing/<yyyymmdd> directory, in normalmode (without the-V command line parameter) in degrowth order on the Source OMPfor the cell components.

Refer to the Degrowth Table,“Forms and key fields” (p. 3-11)for the degrowth orderon the Source OMP for the cell components. For more information on BP, seeCDMA2000® 1xEV-DO Network EMS Configuration Management Bulk ProvisioningGuide,401-614-325.

Example:



...................................................................................................................................................................................................

34 Run the deletion scripts asroot on the first two FMS-APs.

Where:



In RRL off mode:






6. Log off of AP02



Rename a cell

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008





9. Log off of AP01.



In RRL on mode:






6. Log off of AP02






9. Log off of AP01.




...................................................................................................................................................................................................


...................................................................................................................................................................................................



Rename a cell

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-89


Refer to the Growth Table,“Forms and key fields” (p. 3-11)for the growth order onthe Target OMP for the cell components. For more information on BP, see CDMA2000® 1xEV-DO EMS Configuration Management Bulk Provisioning.,401-614-325.

Example:


Result: The renamed cell is added into the database of the Target RNC.

...................................................................................................................................................................................................

37 Run the network addition and creation scripts asroot on the first two FMS-APs.

Where:



In RRL off mode:






5. Run thet1 creation script ./t1fileCrtXXXYY



8. Log off AP02




10. Log off of AP01

11. Log on to AP02 asroot and repeat Substep 9


In RRL on mode:




Rename a cell

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008







8. Log off of AP02








...................................................................................................................................................................................................

38 If they were generated, run the BP Neighbor Sector Replace scripts on all of the TargetOMP’s Neighboring OMPs to update the Neighbor sectors on the Neighbor FMS-APs.



Where: NeighborSectorXXXYYReplace<BPfile#>contains:




...................................................................................................................................................................................................


Example:



Rename a cell

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-91

...................................................................................................................................................................................................



...................................................................................................................................................................................................


...................................................................................................................................................................................................

42 Verify successful cell rename by placing a call on the renamed cell. Start a continuousping to a good system, and perform handoffs across the faces of the cell.


...................................................................................................................................................................................................

43 If a Neighbor cell is available, start a new session on the renamed cell and performthree active handoffs between the renamed cell and the Neighbor cell.

Result: Handoffs between the renamed cell and the Neighbor cell are done.

...................................................................................................................................................................................................


E N D O F S T E P S...................................................................................................................................................................................................


Rename a cell

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Move and Rename a cell (intra-RNC)...................................................................................................................................................................................................................................

Purpose

This procedure moves and renames a stand alone modular cell or the DO-side of amixed-mode modular cell from one FMS-AP pair to another FMS-AP pair on the sameRNC (intra-RNC). The Source OMP and the Target OMP are the same.


When to perform

Perform this procedure when you need to simultaneously move and rename a cell.



Prerequisites








Important


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-93

For information on setting up a login on the OMP, seeCDMA Network Operations andManagement Platform (OMP-FX) ECP Operations, Administration, and Maintenance,401-662-102.




– Data supplied to the configuration database should meet the known parameterconfiguration guidelines. (See the CDMA2000® 1xEV-DO NetworkConfigurations Parameters Guide,401-614-324).

• Ensure that all systems are stable before attempting an actual cell move andrename.



Procedure



...................................................................................................................................................................................................


Important! For inter-RNC Cell Swing, the DO-RNCs need to have the same load.RCS-APs (CDMA) also need to have the same load.

...................................................................................................................................................................................................




Move and Rename a cell (intra-RNC)

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008







...................................................................................................................................................................................................


...................................................................................................................................................................................................


In RRL off mode:









In RRL on mode:




4. cd /<home_DIR>/<login_ID>/<yyyymmdd>/backup







...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-95


...................................................................................................................................................................................................

5 Repeat Main ProcedureStep 1-Step 3for the Neighboring OMPs/RNCs.

...................................................................................................................................................................................................

6 On the Source OMP, make a temporary directory where the necessary input and outputfiles for moving a cell will be stored.




...................................................................................................................................................................................................




...................................................................................................................................................................................................




...................................................................................................................................................................................................





Example:


2. . BP_user_setup



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

3. Enter: Y


...................................................................................................................................................................................................



Where:




-h prints the evdoswing command usage helpmessage


(y/n)?″

...................................................................................................................................................................................................

11 At the prompt,

Enter: Y


...................................................................................................................................................................................................


...................................................................................................................................................................................................





...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-97


Where: -c dumps tables for converged cells.



...................................................................................................................................................................................................

14 If the cell to be move/renamed has Neighbors on other RNCs or SNs, log into theNeighbor OMP(s) and enter Main ProcedureStep 6- Step 13(run evdodump for thosesystems, specifying the appropriate SN type (n for Neighbor) in Main ProcedureStep12 .


...................................................................................................................................................................................................

15 Transfer the files generated for the Neighbor OMPs to the temporary directory (createdin Main ProcedureStep 6) on the Source OMP viasftp.


...................................................................................................................................................................................................



Where:







...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


...................................................................................................................................................................................................


Example:


Where:





...................................................................................................................................................................................................


Example:

cd $bpPath/sXXX/fYY

Where:




...................................................................................................................................................................................................



...................................................................................................................................................................................................


Example:

1. cd /var/dhcp




...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-99


...................................................................................................................................................................................................


Example:

1. cd /etc

2. get netmasks


...................................................................................................................................................................................................


...................................................................................................................................................................................................


...................................................................................................................................................................................................

24 At the prompt,

Enter: cd $bpPath

...................................................................................................................................................................................................

25 If no network changes are being made, skip toStep 28. Otherwise,


Where:





...................................................................................................................................................................................................



Where:




...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


In RRL off mode:







7. cd $bpPath

In RRL on mode:







7. cd $bpPath


...................................................................................................................................................................................................


In RRL off mode:



3. chmod +x *

4. Log off of AP01


In RRL on mode:

1. Log on to AP01 as as login user

2. cd /<home_DIR>/<login_ID>/<yyyymmdd>/scripts

3. chmod +x *

4. Log off of AP01



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-101



...................................................................................................................................................................................................







...................................................................................................................................................................................................



On the Source OMP, at the$bpPath directory, run each script individually in validatemode (-V) to confirm syntax.

Example: runBP -i -O /omp-data/logs/evdotools/runBPmmddyyyy.log -A -Vscriptname

Where:






...................................................................................................................................................................................................

30 Remove the CDM using theTICLI. This step must be repeated for all CDMs in amultiple carrier cell.

Take the cell unconditionally out of service (OOS) to divert call traffic.

Example:

TICLI



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008



...................................................................................................................................................................................................


Run the BP Delete scripts, found in the/home/swing/<yyyymmdd> directory, in normalmode (without the -V command line parameter) in degrowth order on the Source OMPfor the cell components.


Example:



...................................................................................................................................................................................................


Where:



In RRL off mode:






6. Log off of AP02






9. Log off of AP01.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-103



In RRL on mode:






6. Log off of AP02






9. Log off of AP01.




...................................................................................................................................................................................................


Important! Prior to entering the BP ADD scripts, the CDMA portion of the cellshould be swung, up and made operational.

...................................................................................................................................................................................................





...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Example:

runBP -i -O /omp-data/logs/evdotools/runBPmmddyyyy.log -A <element><SNID><FMSID>Add<BPfile#>

Result: The renamed cell is added into the database of the Target RNC.

...................................................................................................................................................................................................

35 Run the network addition and creation scripts asroot on the first two TargetFMS-APs.

Where:



In RRL off mode:









8. Log off of AP02







In RRL on mode:





...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-105







8. Log off of AP02







Result: The network entries for the cell being moved/renamed are added to theTarget RNC.

...................................................................................................................................................................................................


Example:



Where:





...................................................................................................................................................................................................




...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Example:


...................................................................................................................................................................................................



...................................................................................................................................................................................................


...................................................................................................................................................................................................



...................................................................................................................................................................................................

41 If a Neighbor cell is available, start a new session on the moved cell and perform threeactive handoffs between the moved cell and a Neighbor cell. This should be done forboth CDMA and EVDO.


...................................................................................................................................................................................................


E N D O F S T E P S...................................................................................................................................................................................................



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-107

Move and Rename a cell (inter-RNC)...................................................................................................................................................................................................................................

Purpose

This procedure moves and renames a stand alone modular cell or the DO-side of amixed-mode modular cell from an FMS-AP pair on one RNC to another FMS-AP pairon another RNC (inter-RNC).


When to perform

Perform this procedure when you need to simultaneously move and rename a cell.



Prerequisites








Important


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008






• Ensure that all systems are stable before attempting an actual cell move andrename.



Procedure



...................................................................................................................................................................................................


...................................................................................................................................................................................................





Move and Rename a cell (inter-RNC)

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-109






...................................................................................................................................................................................................


...................................................................................................................................................................................................


In RRL off mode:









In RRL on mode:










...................................................................................................................................................................................................

5 Repeat Main ProcedureStep 1- Step 4for the Target OMP.



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

...................................................................................................................................................................................................

6 Repeat Main ProcedureStep 1- Step 3for the Neighbor OMP.

...................................................................................................................................................................................................

7 Using TICLI, obtain list a active generics on the cells to be moved/removed.

Example: TICLI

TICLI> OP:CELL #, generic

TICLI> quit


...................................................................................................................................................................................................

8 Confirm Target RNC’s cell generic:

1. Log on to Target OMP asroot

2. Log on to Target FMS-AP

3. cd /flx/ONEXEVcs/versions


Where: cell_generic is the name of the active generic obtained from theop:bts #,generic command entered in Main ProcedureStep 5.

5. If generic is the same as the Source OMP, then this sub-procedure is complete.Go to the next Substep.

If the result is:cell_generic: No such file or directory then install thesame generic as is found on the Source OMP on the Target OMP’s system. SeeSection 8, ofAlcatel-Lucent 9271 EV-DO Radio Network Controller,401-614-102,for cell generic installation procedures.

6. Repeat Substeps 2-4 for all cells being moved/removed.

...................................................................................................................................................................................................

9 On the Source OMP, make a temporary directory where the necessary input and outputfiles for moving a cell will be stored.




...................................................................................................................................................................................................




...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-111



...................................................................................................................................................................................................




...................................................................................................................................................................................................


Cell swing template files may be found in$cstempsafter the BP environment isenabled for theroot user.



Example:


2. . BP_user_setup

3. Enter: Y


...................................................................................................................................................................................................



Where:







...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


(y/n)?″

...................................................................................................................................................................................................

14 At the prompt,

Enter: Y


...................................................................................................................................................................................................


...................................................................................................................................................................................................




Where: -c dumps tables for converged cells.



...................................................................................................................................................................................................

17 If the Target RNC is on a different OMP, repeat Main ProcedureStep 9- Step 16onthe Target OMP, then transfer the following files back to the temporary directorycreated inStep 9on the Source OMP , otherwise skip this step:

Example: APXXX.txtNeighborSectorXXXYY.txt

Where: XXX = Target SN ID

YY = Target Frame ID

...................................................................................................................................................................................................

18 If the cell to be moved/removed has Neighbors on other RNCs or SNs, log into theNeighbor OMP(s) and enter Main ProcedureStep 9- Step 16(run evdodump for thosesystems, specifying the appropriate SN type (n for Neighbor) inStep 15.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-113


...................................................................................................................................................................................................

19 Transfer the files generated for those OMPs to the temporary directory (created inMain ProcedureStep 9) on the Source OMP.

...................................................................................................................................................................................................



Where:





Result: The evdoswing script files for deleting and adding the cell components arecreated along with the replace scripts for updating the Neighbor sectors on otherRNCs/SNs.

...................................................................................................................................................................................................


Example:


Where:






...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


...................................................................................................................................................................................................

22 On the Source OMP, go to the Source SNID/Frame ID directory that was created byevdomkdir.

Example:

cd $bpPath/sXXX/fYY

Where:

XXX = three-digit value for the Source Service Node ID

YY = two-digit value for the Source Frame ID


...................................................................................................................................................................................................



...................................................................................................................................................................................................


Example:

1. cd /var/dhcp


Result: Copy of theSource SUNWfiles1_dhcptabfile is obtained.

...................................................................................................................................................................................................


Example:

1. cd /etc

2. get netmasks

Result: Copy of theSource netmasksfile is obtained.

...................................................................................................................................................................................................




...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-115

...................................................................................................................................................................................................

27 Repeat Main ProcedureStep 22- Step 26for the Target RNC, replacing alloccurrences of Source with Target.If the Target OMP is different, save the files on theTarget OMP in$bpPath directory and transfer the network files viasftp to theappropriate directory ($bpPath/s<TargetSNID>/f<TargetFrameID>) on the SourceOMP.

...................................................................................................................................................................................................


Enter: cd $bpPath

...................................................................................................................................................................................................



Where:





...................................................................................................................................................................................................



Where:



In RRL off mode:




4. mput *Del* (press theEnter key when prompted)

5. Exit sftp by enteringbye or quit; press theEnter key.



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

6. Repeat Substeps2 - 5 for AP02, do not transfer the files that begin withnetmsk,as these files are not needed on AP02

7. cd $bpPath

In RRL on mode:







7. cd $bpPath


...................................................................................................................................................................................................

31 Important! If the Target RNC is on a different OMP, the creation and additionscripts will have to be transferred to the$bpPath directory of the Target OMP.After that, they can then be transferred to the first two FMS-APs of the Targetsystem.


Transfer the network addition and creation scripts (T1, dhcp, netmasks) to the first twoFMS-APs of the Target system.

Where:



In RRL off mode:







7. cd $bpPath



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-117

In RRL on mode:

1. Log on to AP01 as as login user

2. cd /<home_DIR>/<login_ID>/<yyyymmdd>/scripts




7. cd $bpPath


...................................................................................................................................................................................................

32 Change permissions on the deletion script files (transferred in Step 30 for the SourceRNC).

In RRL off mode:



3. chmod +x *

4. Log off of AP01


In RRL on mode:



3. chmod +x *

4. Log off of AP01



...................................................................................................................................................................................................

33 Change permissions on the addition script files (transferred in Step 31 for the TargetRNC).

In RRL off mode:



3. chmod +x *

4. Log off of AP01



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


In RRL on mode:



3. chmod +x *

4. Log off of AP01


Result: The network addition scripts are made executable.

...................................................................................................................................................................................................

34 If they were generated, transfer the Neighbor sector replacement scripts from thetemporary directory on the Source OMP to the temporary directory created on theNeighboring OMPs whereevdodump was run.





...................................................................................................................................................................................................



On the Source OMP, at the$bpPath directory, run each scripts individually in validate(-V) mode to confirm syntax.

Example:


Where:


<element><SNID><FMSID>Delete<BPfile#> (Source)

<element><SNID><FMSID>Add<BPfile#> (Target)

<element><SNID><FMSID>Replace<BPfile#> (Target)

...................................................................................................................................................................................................





...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-119

On the Neighbor OMP, run the NeighborSector Replace scripts in validate (-V) mode.

Example:

runBP -i -O /omp-data/logs/evdotools/runBPmmddyyyy.log -A -V


Where:




...................................................................................................................................................................................................



If Target OMP is different than the Source OMP, transfer the Add and Replace scriptsto the Target OMP usingsftp, then run the BP Add/Replace scripts in validate (-V)mode.

Example:


Where:




...................................................................................................................................................................................................

38 Remove the CDM using theTICLI. This step must be repeated for all CDMs in amultiple carrier cell.

Example:

root> TICLI



...................................................................................................................................................................................................


Run the BP Delete scripts, found in the directory, in normal mode (without the-Vcommand line parameter) in degrowth order on the Source OMP for the cellcomponents.



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Example:



...................................................................................................................................................................................................


Where:



In RRL off mode:


2. cd /app2/swing/<yyyymmdd> /scripts

3. Run thet1 deletion script: ./t1fileDelXXXYY

4. Run thedhcpdeletion script: ./dhcpDelXXXYY


6. Log off of AP02






9. Log off of AP01



In RRL on mode:






...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-121



6. Log off of AP02






9. Log off of AP01.




...................................................................................................................................................................................................


...................................................................................................................................................................................................




Example: runBP -i -O /omp-data/logs/evdotools/runBPmmddyyyy.log -A<element><SNID><FMSID>Add<BPfile#>

Result: The cell is added into the database of the Target RNC.

...................................................................................................................................................................................................

43 Run the network addition and creation scripts asroot on the first two Target FMS-APsof the Target OMP.



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008



In RRL off mode:





4. Run thedhcpaddition script: ./dhcpAddXXXYY

5. Run thet1 creation script: ./t1fileCrtXXXYY

6. Run thet1 addition script: ./t1entryAddXXXYY


8. Log off AP02




10. Log off of AP01



In RRL on mode:









8. Log off of AP02




...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-123







...................................................................................................................................................................................................

44 If they were generated, run the BP Neighbor Sector Replace scripts on all of the TargetOMP’s Neighboring OMPs to update the Neighbor sectors on the Neighbor FMS-APs.



Where:





...................................................................................................................................................................................................


Example:


...................................................................................................................................................................................................



...................................................................................................................................................................................................




...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

...................................................................................................................................................................................................



...................................................................................................................................................................................................



...................................................................................................................................................................................................


E N D O F S T E P S...................................................................................................................................................................................................



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-125

Cell Swing backout procedure...................................................................................................................................................................................................................................

Purpose

This procedure moves the stand alone modular cell back to the original FMS-AP pair.



Caveats

• This procedure does not cover the removal of newly created dhcp files if the swingwas an intra-RNC swing with network changes.

• This procedure does not include backing out applicable network changes to supportthe cell swing (for example, (multiple) router changes between the cell and theSource/Target FMS-APs).

Procedure



...................................................................................................................................................................................................


...................................................................................................................................................................................................

2 Follow the database restoration procedure inAlcatel-Lucent 9271 EV-DO RadioNetwork Controller,401-614-102, for both FMS-APs of the Source system.

...................................................................................................................................................................................................

3 RepeatStep 2for the Target RNC if an inter-RNC swing or an inter-RNC move andrename is being backed out.

...................................................................................................................................................................................................

4 RepeatStep 2for all Neighboring SNs.

...................................................................................................................................................................................................

5 Restore the network files (/var/dhcp/SUNWfiles1_dhcptab,/var/dhcp/SUNWfiles1_A_B_C_D, and/etc/netmasks) on AP01 of the Source system.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Where: A_B_C_D are determined by searching the Source RNC’snetmasksfilesfor entries for the cell in question.

Example:

1. Assume cell 150, which has twoT1s, had been moved to another RNC, and themove is now being backed out.

2. On the Source RNC:In RRL off mode login asonexevcd /app2/swing/<yyyymmdd>/backupIn RRL is enabled login with user accountcd /<home_DIR>/<login_ID>/swing/<yyyymmdd>/backup

3. Enter: grep ″Cell 150″ ./netmasksResult: output shows all defined network entries for cell 15010.1.150.0 255.255.255.224 #Cell 15010.100.19.0 255.255.255.252 #first T1 for Cell 15010.100.20.0 255.255.255.252 #second T1 for Cell 150

4. The following two additional files from the backup directory would have to berestored:Enter:cp SUNWfiles1_10_100_19_0 /var/dhcp/SUNWfiles1_10_100_19_0cp SUNWfiles1_10_100_20_0 /var/dhcp/SUNWfiles1_10_100_20_0

...................................................................................................................................................................................................

6 Restore the network files (/var/dhcp/SUNWfiles1_dhcptaband/var/dhcp/SUNWfiles1_A_B_C_D, and/etc/netmasks) on AP02 of the Source system.

...................................................................................................................................................................................................

7 Enter: /flx/ONEXEVc/current/release/tools/cfg/modifyNetmasks SYNC

Result: The netmasksfiles are synchronized across all FMS-APs of the Sourcesystem.

...................................................................................................................................................................................................

8 Stop and Startdhcpon AP01 and AP02 of the Source system


• In RRL off mode assumeonexev on lead AP.

• In RRL on mode login with user account and then assumersysadm role on lead AP.

2. Stop and restart DHCP on AP01 (asroot) :



3. Log off of AP01



Cell Swing backout procedure

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-127


...................................................................................................................................................................................................

9 Repeat Main ProcedureStep 5- Step 8for the Target RNC if an inter-RNC swing oran inter-RNC move and rename is being backed out, replacing step text″Source″ withthe word″Target″.

...................................................................................................................................................................................................

10 If backing out an inter-RNC move and/or rename, remove the network files(/var/dhcp/SUNWfiles1_dhcptab, /var/dhcp/SUNWfiles1_A_B_C_D, and/etc/netmasks)on AP01 of the Source system.

Where: A_B_C_D are determined by searching the Source RNC’snetmasksfilesfor entries for the cell in question.

Example:

1. Assume cell 150, which has two T1s, had been moved to another RNC, and themove is now being backed out.

2. Assume cell 150, which has twoT1s, had been moved to another RNC, and themove is now being backed out.

3. On the Target RNCEnter: cd /app2/swing/<yyyymmdd>/scripts

4. Enter: grep ″Cell 150″ ./t1fileCrtXXXYYWhere: ( XXX = SN ID andYY = Frame ID)Result: output shows thepntadm -C commands run for the cell swingpntadm -C 10.100.19.0pntadm -C 10.100.20.0

5. Run thepntadm -C commands on AP01 and AP02 of the Target RNC,changing the-C (create) to a-R (remove)pntadm -R 10.100.19.0pntadm -R 10.100.20.0

...................................................................................................................................................................................................

11 Restore the Neighbor lists on the Neighbor RNCs to is their original settings.

E N D O F S T E P S...................................................................................................................................................................................................


Cell Swing backout procedure

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Verify OA&M on moved and/or renamed converged cell...................................................................................................................................................................................................................................

Purpose

This procedure verifies that OA&M procedures can be successfully entered on aconverged 1xEV-DO cell that has been moved and/or renamed.

When to perform

Perform this procedure after a 1xEV-DO cell has been moved and/or renamed via thecell swing tools.

Criticality

This procedure ensures that OA&M can be successfully run on a moved 1xEV-DOcell.

Frequency

Perform this procedure once, for each cell, only after completing a 1xEV-DO cellmove and/or rename.

Required conditions

To perform this procedure successfully, ensure that the following conditions are metbefore you begin the procedure:

• The 1xEV-DO cell move and/or rename completed successfully


This procedure is best performed by an expert system administrator with extensiveknowledge of theTICLI.

Required tools

To perform this procedure, you require the following tools:

• TICLI

Required information

To perform this procedure, you must know the CDMA BTS ID (3G-1x Cell ID on theEMS GUI, or OMC-RAN) and the 1xEV-DO CDM IDs of the cell that was movedand/or renamed.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-129


For detailed information about input and output messages, seeCDMA Networks InputMessages,401-610-055, andCDMA Network Output Messages,401-610-057.

Procedure



...................................................................................................................................................................................................

1 Log on to the OMP asroot and start theTICLI.

...................................................................................................................................................................................................

2 Enter: OP:CELL BTS_ID

Where:

BTS_ID is the ID of the BTS.

Result: The status of the moved cell is displayed.

...................................................................................................................................................................................................

3 Enter: OP:CELL BTS_ID, CDM CDM_ID

Where:

BTS_ID is the ID of the BTS

CDM ID is the ID of the CDM

Result: The status of the specified CDM is displayed.

...................................................................................................................................................................................................

4 Enter: OP:CELL BTS_ID , AMP

Where:


Result: The status of the amplifiers associated with the moved cell is displayed.

...................................................................................................................................................................................................

5 Enter: OP:CELL BTS_ID, GENERIC

Where:



Verify OA&M on moved and/or renamed converged cell

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Result: The status of the cell generic/generics installed on the moved cell is/aredisplayed.

...................................................................................................................................................................................................

6 Enter: OP:CELL BTS_ID, ALARM

Where:


Result: The status of any alarmed components associated with the moved cell isdisplayed.

E N D O F S T E P S...................................................................................................................................................................................................


Verify OA&M on moved and/or renamed converged cell

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-131

Verify service measurements reporting...................................................................................................................................................................................................................................

Purpose

This procedure verifies that service measurements (SM) for a moved/renamed standalone modular cell are reported on the new RNC.

When to perform

Perform this procedure after the top of the second hour after a 1xEV-DO cell has beenmoved.

Criticality

This procedure ensures that SM associated with a moved/renamed cell are correctlybeing reported on their new RNC.

Frequency

Perform this procedure only once after the 1xEV-DO cell has been moved/renamed.

Required conditions

To perform this procedure successfully, ensure that the following conditions are metbefore you begin the procedure:

• The 1xEV-DO cell was successfully moved/renamed


This procedure is best performed by an expert system administrator with extensiveknowledge of service measurements.

Required information

To perform this procedure, you must know the new location of the moved cell.


For descriptions of service measurements for the Ethernet Interface Node (EIN), seeCDMA Network Service Measurements,401-610-135.

Procedure



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


...................................................................................................................................................................................................

1 Place a call on the moved/renamed cell, establish a continuous ping and perform fivesets of active handoffs across all the faces of the cell. Terminate the session.

Result: A call is placed and five sets of active handoffs are done.

...................................................................................................................................................................................................

2 Place a call on the moved/renamed cell, establish a continuous ping and perform fivesets of active handoffs across all the faces of the cell. Terminate the session.

Result: A call is placed and five sets of active handoffs are done.

...................................................................................................................................................................................................

3 Let the AT go idle and then perform five sets of idle handoffs between all the faces ofthe cell.

Result: Five sets of active handoffs are done.

...................................................................................................................................................................................................

4 A few minutes after the top of the hour, verify that service measurements (SM) forboth active and idle handoffs were appropriately pegged for the moved/renamed cell.

Result: Active and idle SM’ pegs are reported in the appropriate SM file.

E N D O F S T E P S...................................................................................................................................................................................................


Verify service measurements reporting

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-133

Cleanup of old Cell Swing files...................................................................................................................................................................................................................................

Purpose

This procedure is used to remove the temporary files and directories created and usedduring a cell move/rename.

When to perform

Perform this procedure after a 1xEV-DO cell has been successfully moved/renamedand the temporary files/directories are no longer needed.

Criticality

This procedure ensures that disk space is conserved.

Frequency

Perform this procedure only once after the 1xEV-DO cell has been moved/renamed.

Procedure



...................................................................................................................................................................................................

1 Log on to the OMP asroot.

...................................................................................................................................................................................................

2 Log on to the database FMS-AP.

...................................................................................................................................................................................................

3 Remove swing file by entering:cd /app2/DBbackuprm -f swing <yyyymmdd>

...................................................................................................................................................................................................

4 Log on to AP01.

...................................................................................................................................................................................................

5 Remove the files and directories from within the temporary directories:

rm -fr /app2/swing/<yyyymmdd>/scripts/

rm -fr /app2/swing/<yyyymmdd>/backup/


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

...................................................................................................................................................................................................

6 Log on to AP02.

...................................................................................................................................................................................................

7 Remove the files and directories from within the temporary directories:

rm -fr /app2/swing/<yyyymmdd>/scripts/

rm -fr /app2/swing/<yyyymmdd>/backup/

...................................................................................................................................................................................................


...................................................................................................................................................................................................

9 On all applicable OMPs (Source, Target, Neighboring), remove the temporary directoryused to store the input and output files:

rm -fr /home/swing/<yyyymmdd>

...................................................................................................................................................................................................

10 Log off of the OMP.

E N D O F S T E P S...................................................................................................................................................................................................


Cleanup of old Cell Swing files

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


3-135

Moving Base Stations from R1SR Based 1xEV-DO RNC APsto Universal Cabinet (UNC)-Based 1xEV-DO RNC APs...................................................................................................................................................................................................................................

Purpose

The procedures to move the base stations and to describe the impact of UNC based1xEV-DO RNC Infrastructure, FID 12885.1, feature, are found in CDMA2000®

1xEV-DO Radio Access System Planning and Implementation Guide,401-614-101 andAlcatel-Lucent 9271 EV-DO Radio Network Controller,401-614-102.



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

4 4CDMA 3G-1x EVolution DataOptimized (1xEV-DO) HandoffMatrix (HOM) Tool and RelatedFeatures

Overview...................................................................................................................................................................................................................................

Purpose

This chapter describes the following optional features inCDMA2000® 1xEV-DOnetworks. Unique Feature Identifiers (FIDs) are assigned to each feature:

• 1xEV-DO Handoff Matrix (HOM) Tool (FID 12146.0)

• BC0/BC1 Dual Band 1xEV-DO (FID 8219.7)

• 1xEV-DO Support for Multi-Carrier Coverage Differences (FID 8219.9)

• Support for Multiple 1xEV-DO Carriers - Inter-frequency Handoff (IFHO) (FID8219.11)

• Six Sector Modular Cell 4.0B with Mixed 1x and 1xEV-DO (8882.2)

Feature summary

The following summarizes the features covered in this document.

1xEV-DO HOM Tool feature (FID 12146.0)

The 1xEV-DO HOM Tool feature provides service providers with importantinformation to assist in 1xEV-DO neighbor list adjustments needed to improve handoffperformance. The 1xEV-DO Handoff Matrix tool outputs the number and types ofactive session handoffs from all the sectors on a Service Node (SN) to every othersector to which a handoff occurred. These handoffs are collected and reported by thein-service Radio Network Controllers (RNCs) in the SN. The data can bepost-processed by a tool or customer-developed tools, such as Excel macros.

BC0/BC1 Dual Band 1xEV-DO (FID 8219.7)

The BC0/BC1 Dual Band 1xEV-DO feature enables the support of BC0/BC1 dual bandin the 1xEV-DO system. BC0 is the cellular (850) frequency band and BC1 is the PCS(1900) frequency band.

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


4-1

1xEV-DO Support for Multi-Carrier Coverage Differences (FID 8219.9)

The 1xEV-DO Support for Multi-Carrier Coverage Differences feature accommodatescoverage differences across band classes for 1xEV-DO in multi-carrier cells.

Support for Multiple 1xEV-DO Carriers - IFHO feature (FID 8219.11)

The Support for Multiple 1xEV-DO Carriers feature provides support for multiple1xEV-DO carriers - inter-frequency handoff (IFHO) and provides the capability toperform handoff of an active 1xEV-DO connection from one carrier to a differentcarrier. With IFHO, a mobile user moving into a sector that does not have the currentservice carrier can be handed off to a new carrier without dropping the connection,providing a smooth transition.

Six Sector Modular Cell 4.0B with Mixed 1x and 1xEV-DO (FID 8882.2)

The Six Sector Modular Cell 4.0B with Mixed 1x and 1xEV-DO feature addresses the6-Sector Modular Cell 4.0B which supports up to 6 1x carriers or up 5 1x carriers and1 1xEV-DO carrier at a power of up to 16W/carrier.


The 1xEV-DO HOM Tool feature and related features affect the user interfaces that arelisted in the following table.


1xEV-DO HOM Tool feature(FID 12146.0)

Element ManagementSystem (EMS) orOMC-RANconfigurationmanagement

None



None


None

CDMA 3G-1x EVolution Data Optimized (1xEV-DO)Handoff Matrix (HOM) Tool and Related Features

Overview

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


BC0/BC1 Dual Band1xEV-DO (FID 8219.7)

EMS or OMC-RANconfigurationmanagement

None


AMA subsystem None

TI (input/outputmessages)

None

1xEV-DO Support forMulti-Carrier CoverageDifferences (FID 8219.9)


None

Service measurements See“Service measurements:1xEV-DO Support forMulti-Carrier CoverageDifferences (FID 8219.9)”(p. 4-33)

AMA subsystem None


None

Support for Multiple1xEV-DO Carriers - IFHOfeature (FID 8219.11)


None


AMA subsystem None


None

Six Sector Modular Cell4.0B with Mixed 1x and1xEV-DO (FID 8882.2)


None


AMA subsystem None


None


Overview

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


4-3



Contents

Availability 4-5

Prerequisites 4-6

Feature description: 1xEV-DO HOM Tool feature (FID 12146.0) 4-9

Feature description: BC0/BC1 Dual Band 1xEV-DO (FID 8219.7) 4-12

Feature description: 1xEV-DO Support for Multi-Carrier CoverageDifferences (FID 8219.9)

4-14

Feature description: Support of Multiple 1xEV-DO Carriers - IFHOfeature (FID 8219.11)

4-18

evstarthom command 4-19

evdisphom command 4-22

Feature description: Six Sector Modular Cell 4.0B with Mixed 1x and1xEV-DO (FID 8882.2)

4-30


Service measurements: 1xEV-DO Support for Multi-Carrier CoverageDifferences (FID 8219.9)

4-33


Implementing the 1xEV-DO HOM feature (FID 12146.0) 4-37

Activating the 1xEV-DO feature (FID 12146.0) 4-38


Overview

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Availability...................................................................................................................................................................................................................................


The following table identifies the AMPS/PCS software releases in which the 1xEV-DOHOM Tool feature and related features are available.


1xEV-DO HOM Tool (FID 12146.0) Releases 25.0 and later

BC0/BC1 Dual Band 1xEV-DO (FID 8219.7) Releases 28.01 and later

1xEV-DO Support for Multi-Carrier CoverageDifferences (FID 8219.9)

Releases 30.0 SU-0002 and later

Support for Multiple 1xEV-DO Carriers - IFHO(FID 8219.11)

Releases 26.0 and later

Six Sector Modular Cell 4.0B with Mixed 1x and1xEV-DO (FID 8882.2)


Market availability

The 1xEV-DO HOM Tool feature and related features are available in the followingmarkets:


1xEV-DO HOM Tool (FID12146.0)

1xEV-DO markets only

BC0/BC1 Dual Band 1xEV-DO(FID 8219.7)


1xEV-DO Support forMulti-Carrier CoverageDifferences (FID 8219.9)


Support for Multiple 1xEV-DOCarriers - IFHO (FID 8219.11)


Six Sector Modular Cell 4.0Bwith Mixed 1x and 1xEV-DO(FID 8882.2)



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


4-5

Prerequisites...................................................................................................................................................................................................................................

Introduction

The 1xEV-DO HOM Tool feature and related features have the following prerequisites.



The 1xEV-DO HOM Tool feature is supported in the following air-interfacetechnologies:

• 1xEV-DO


The BC0/BC1 Dual Band 1xEV-DO feature is supported in the following air-interfacetechnologies:

• 1xEV-DO


The 1xEV-DO Support for Multi-Carrier Coverage Differences feature is supported inthe following air-interface technologies:

• 1xEV-DO

Support of Multiple 1xEV-DO Carriers - IFHO feature (FID 8219.11)

The Support of Multiple 1xEV-DO Carriers - IFHO feature is supported in thefollowing air-interface technologies:

• 1xEV-DO


The Six Sector Modular Cell 4.0B with Mixed 1x and 1xEV-DO feature is supportedin the following air-interface technologies:

• 1xEV-DO

HLR configuration


The 1xEV-DO HOM Tool feature is independent of the Home Location Register(HLR) configuration.


The BC0/BC1 Dual Band 1xEV-DO feature is independent of the Home LocationRegister (HLR) configuration.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


The 1xEV-DO Support for Multi-Carrier Coverage Differences feature is independentof the Home Location Register (HLR) configuration.


The Support of Multiple 1xEV-DO Carriers - IFHO feature is independent of the HomeLocation Register (HLR) configuration.


The Six Sector Modular Cell 4.0B with Mixed 1x and 1xEV-DO feature is independentof the HLR configuration.



The 1xEV-DO HOM Tool feature requires Release 25.0 or later. The 1xEV-DO HOMTool feature is not dependent on other features.

The 1xEV-DO HOM Tool feature FAF must be active. For more information, see“Activating the 1xEV-DO feature (FID 12146.0)” (p. 4-38).


The BC0/BC1 Dual Band 1xEV-DO feature requires Release 28.01 or later. TheBC0/BC1 Dual Band 1xEV-DO feature is not dependent on other features.

The BC0/BC1 Dual Band 1xEV-DO feature covers the testing of 1xEV-DO BC0/BC1dual band capability (Support for Multiple 1xEV-DO Carriers - Enhancements FID8219.2).


The 1xEV-DO Support for Multi-Carrier Coverage Differences feature requiresReleases 30.0 SU-0002 or later.

The 1xEV-DO Support for Multi-Carrier Coverage Differences feature builds on thefunctionality included in the following features. See“1xEV-DO Support forMulti-Carrier Coverage Differences (FID 8219.9)” (p. 4-32)for details.

• Support for Multiple 1xEV-DO Carriers (FID 8219.1)



The Support of Multiple 1xEV-DO Carriers - IFHO feature requires Release 26.0 orlater. The Support of Multiple 1xEV-DO Carriers feature is not dependent on otherfeatures.


Prerequisites

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


4-7


The Six Sector Modular Cell 4.0B with Mixed 1x and 1xEV-DO feature requires ECPRelease 27.0 or later. The 1xEV-DO HOM Tool feature is not dependent on otherfeatures.

General software requirements

The following notes apply to the 1xEV-DO Handoff Matrix Tool feature and to relatedfeatures:

Important! The user’s login must be in the ECP group on the OMP.

Important! To run HOM on the RNCs, the RNCs must have been configured bythe SMconfig tool.



The 1xEV-DO Handoff Matrix Tool feature runs only on a 1xEV-DO Operations andMaintenance Platform (OMP).


The BC0/BC1 Dual Band 1xEV-DO feature runs only on a 1xEV-DO Operations andMaintenance Platform (OMP).


The 1xEV-DO Support for Multi-Carrier Coverage Differences feature runs only on a1xEV-DO Operations and Maintenance Platform (OMP).


The Support of Multiple 1xEV-DO Carriers - IFHO feature runs only on a 1xEV-DOOperations and Maintenance Platform (OMP).


The Six Sector Modular Cell 4.0B with Mixed 1x and 1xEV-DO feature runs only on a1xEV-DO Operations and Maintenance Platform (OMP).


Prerequisites

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Feature description: 1xEV-DO HOM Tool feature (FID12146.0)...................................................................................................................................................................................................................................

Introduction

The following information describes the functionality, benefits, and operation of the1xEV-DO HOM Tool feature.

Functionality

The 1xEV-DO Handoff Matrix Tool feature allows service providers to collectinformation about the number and types of handoffs and handoff attempts that occur intheir systems.

Important! There are some limitations as to which handoff counts are listed in theoutput. See“Issues and caveats” (p. 4-34). Also, only handoffs for active sessionsare reported. Idle transfers and handoffs for idle sessions are not reported.

Benefits

Analysis of the handoff counts that the 1xEV-DO Handoff Matrix Tool featuregenerates can help a service provider to:

• determine whether the system meets current needs

• plan for future needs


For each cell in the SN, this feature counts the number of handoff completions andhandoff attempts from each cell:sector to cell:sector combination for which handoffsare attempted. This feature also reports undeclared neighbors. Undeclared neighbors arepilots (or PN Offsets) that an AT detects that are not in the current set of the strongestpilots for the AT. Some undeclared neighbors may need to be added to a sector’sneighbor list if ATs report them often and they are not currently on the sector’sneighbor list. For a user-specified period of time, a single query obtains the individualcounts for each type of handoff that the Service Node supports.

The 1xEV-DO Handoff Matrix Tool is implemented asUNIX® commands. A 1xEV-DOHandoff Matrix Tool session can be started manually or with the use of a cron job. Thesession length is variable in increments of one minute from a minimum of ten minutesup to a maximum session length of 24 hours. The default session length is ten minutes.

Important! The maximum duration for a HOM study is 24 hours. However, if youplan to schedule a daily cron job to run back-to-back HOM studies, be sure to setthe study duration to a length that allows time to collect the data from one studybefore starting the next study. In this case, it is recommended that HOM studies beno longer than 23.5 hours in length. This allows 30 minutes to collect and


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


4-9

aggregate the HOM data from the RNCs before starting the next study. Theevstarthom command will fail if evdisphom is not completed by the timeevstarthom runs.

The session begins with zeroed counts. The data output goes to a single file in adefault directory. Both successful and attempted handoffs are pegged. Sessions arestopped automatically, per input arguments, or can be stopped early with an inputcommand. Using theevstarthom command, a HOM study is started by a user at theOperations and Maintenance Platform (OMP); the data collected during the study isaccumulated at each RNC. When the study is complete and the user runs theevdisphom command on the OMP, the OMP transfers the RNC output files to theOMP and aggregates the data into a single file. The output file generated for a study iskept on the OMP for a maximum of ten days unless overwritten or removed earlier bythe user.

evstarthom command

The evstarthom command initiates collection of handoff matrix data on a ServiceNode.

Important! For detailed information on the use of theevstarthom command, see“evstarthom command” (p. 4-19).

evdisphom command

The evdisphom command stops a collection session and/or cause a request for theOMP to retrieve the HOM data from each RNC for aggregation into a single outputfile.

Important! For detailed information on the use of theevdisphom command, see“evdisphom command” (p. 4-22).

Service provider perspective

The 1xEV-DO Handoff Matrix Tool feature requires that:

• To run either theevstarthom command or theevdisphom command, the serviceprovider must either use the root login or a login that is a member of the ECPgroup.

• The service provider must have the Feature Activation File (FAF) entry for the1xEV-DO Handoff Matrix Tool feature activated.


Feature description: 1xEV-DO HOM Tool feature (FID12146.0)

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

• The service provider must also have service measurement collection set up properlyor the HOM tool will not work properly. SMconfig is used to set up thisinformation. Please make sure that the frame number used in the SMconfig tool isthe same as the AP Frame Logical ID listed on the AP Frame Configuration pageon the EMS GUI. One can also determine this FMS Frame ID from the FMSFrame Configuration data. For more information on using SMconfig, see documentCDMA2000 1xEV-DO Radio Networks Controller Application ProcessorOperations, Administration, and Maintenance (OA&M).,401-614-102.

• Enter theevstarthom command on the OMP to start the counting of handoffs.

• Enter theevdisphom command on the OMP to collect the data into a single outputfile on the OMP.


Feature description: 1xEV-DO HOM Tool feature (FID12146.0)

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


4-11

Feature description: BC0/BC1 Dual Band 1xEV-DO (FID8219.7)...................................................................................................................................................................................................................................

Introduction

The following information describes the functionality, benefits, and operation of theBC0/BC1 Dual Band 1xEV-DO feature.

Functionality

The BC0/BC1 Dual Band 1xEV-DO feature enables the support of BC0/BC1 dual bandin the 1xEV-DO system. It covers the testing of 1xEV-DO BC0/BC1 dual bandcapability ( Support for Multiple 1xEV-DO Carriers - Enhancements FID8219.2) forGeneral Availability. BC0 is the cellular (850) frequency band and BC1 is the PCS(1900) frequency band.

Benefits

The BC0/BC1 Dual Band 1xEV-DO feature offers two carriers dual band with onecarrier on BC0 and the other carrier on BC1. Dual band is provided in the same cellsite with multiple BTS frames and each BTS frame operates in either BC0 or BC1.The following BTS types are applicable:

• Modular Cell 4.0, Modular Cell 4.0B

• Compact 4.0

• HD 4.0, HDB

• Modular Cells 1 to 3

For Modular Cells 1, 2 and 3, dual band will be provided using Modular Cell 4.0 (orModular Cell 4.0B) as the growth frame:

• Modular Cell(s) 1, 2 or 3 supporting BC0

• Modular Cell 4.0 (or Modular Cell 4.0B) supporting BC1


As Revision A (Rev. A) functions have been offered with the BC0/BC1 Dual Band1xEV-DO (FID 8219.7) after the inclusion of the dual band software (Support forMultiple 1xEV-DO Carriers - Enhancements FID 8219.2) feature. The BC0/BC1 DualBand 1xEV-DO (FID 8219.7) feature includes the testing of dual band BC0/BC1 usingRev. A carriers. The following combinations of carrier types are supported

• Rev 0 (BC0), Rev 0 (BC1)

• Rev 0 (BC0), Rev A (BC1)

• Rev A (BC0), Rev 0 (BC1)

• Rev A (BC0), Rev A (BC1)


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Load balance at call connection set up is supported to handle the dual band cellconfiguration. Inter-frequency Hand Off (IFHO) is supported. Cross-band hashing willbe supported, allowing the dual band ATs to hash to either band. With cross-bandhashing, the channel list information sent on the control channel includes carriers ofboth band classes.

To set up a cell for dual band, different radio resources need to be assigned for BC0and BC1 and the band class of each 1xEVDO carrier needs to be entered at the EMS.

BC0/BC1 Dual Band 1xEV-DO is a standard feature and is not controlled byFAF/QFAF.


Feature description: BC0/BC1 Dual Band 1xEV-DO (FID8219.7)

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


4-13

Feature description: 1xEV-DO Support for Multi-CarrierCoverage Differences (FID 8219.9)...................................................................................................................................................................................................................................

Introduction

The following information describes the functionality, benefits, and operation of the1xEV-DO Support for Multi-Carrier Coverage Differences feature.

Functionality

The 1xEV-DO Support for Multi-Carrier Coverage Differences feature addresses callprocessing during System Acquisition, Paging, and Connection Setup when carriers onthe accessed sector have different coverage areas.

Benefits

The 1xEV-DO Support for Multi-Carrier Coverage Differences feature is expected toimprove system performance in DO multi-carrier cells by the following options:

• turning off cross band hashing which increases the chances that Access Terminals(ATs) will successfully idle on their″assigned″ carrier, where there is a coveragedifference for carriers in different bands in the same sector.

• sending synchronous messages on either the last seen band or on both bands indual band cells when cross band hashing is turnedoff, the improvementsassociated with turning off cross band hashing are realized without requiring thatATs always be paged on both bands, minimizing the impact on paging resources.

• application of a distance threshold before doing cross-carrier assignment reducesthe failure rate at connection setup, where there is a coverage difference fordifferent carriers on the same sector (either due to border/contiguous carrierdifferences or due to band class differences).

• providing both a maximum distance threshold and a minimum pilot Ec/Io thresholdon the accessed carrier before considering cross-band carrier assignment,connection setup failures due to cross-band assignment in dual band cells arereduced.

• two cross-band load differentials, one for RF and one based on users makes itpossible to favor same-band cross-carrier assignment over cross-band assignmentwhen load balancing in dual-band cells. Their names are Cross Band RF loadDifferential and Cross Band Load Differential.

• Outer Setup Distance Threshold: This threshold sets up a concentric circle outsideof the Inner Tier which restricts TCA to carriers for which AT is within thisdistance. The originating carrier is preferred.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


In multi-carrier cells, carrier coverage can differ for border versus contiguous carriersand for carriers in different band classes. The 1xEV-DO Support for Multi-CarrierCoverage Differences feature accommodates multi-carrier coverage differences for1xEV-DO single band and dual band cells during System Acquisition, Paging, andConnection Setup.

The feature includes:

• An option to turnoff cross band hashing per sector in dual band cells.When cross-band hashing is on for a sector, carriers from both band classes areincluded in the channel list of the Sector Parameters Message for each carrier onthat sector. ATs execute cross-band hashing to determine the″assigned″ carrier foridling.When cross-band hashing isoff for a sector, only same-band carriers are includedin the channel list of the Sector Parameters Message for each carrier on that sector.ATs execute the same-band hashing to determine the″assigned″ carrier for idling.

• Paging changes to support cross-band hashing disable in dual band cells, and addsup to 8 paging attepnts.When cross-band hashing ison for a sector, the AN executes cross-band hashing toselect the carrier on which to send synchronous messages to the AT.When cross-band hashing isoff for a sector, the AN delivers synchronousmessages over one or both bands in a dual band cell. Translations are provided toselect the paging option (last seen band or both bands) for each paging attempt.

• Distance-based carrier assignment for connection setup in single band and dualband cells.If the Load Balancing Method parameter is set toOriginating_Carrier,connection setup is on the carrier on which the Connection Request message isreceived, providing the number of users on that originating carrier is less than theMaxAllowedUser parameter. If the number of users on the originating carrierexceeds theMaxAllowedUser parameter, then other carriers are considered. The1xEV-DO Support for Multi-Carrier Coverage Differences feature applies a distancethreshold check before considering other carriers, so that the AT is assigned to anon-originating carrier only if the distance from the sector to the AT is within thedistance threshold for that carrier. The distance threshold is translatable.If the Load Balancing Method parameter is set toNumber_of_Active_Users,connection setup is on the originating carrier providing two criteria are met:

– the number of users on the originating carrier is less than theMaxAllowedUserparameter, and

– the originating carrier has fewer users than other carriers on the sector by atleast a translatable Load Differential.

– Outer Setup Distance Threshold


Feature description: 1xEV-DO Support for Multi-CarrierCoverage Differences (FID 8219.9)

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


4-15

The Inner Circle is defined by the Inner Tier Distance Threshold and Inner TierEc/Io Threshold. If the signal strength and round trip delay of a call meet thesecriteria then any carrier can be selected. If these criteria are not met (one orboth) then the call is restricted to the originating carrier if the distance is withinthe Outer Setup Threshold. If the original carrier is blocked or unavailable thencarrier selection is restricted to non-originating carriers within the Outer SetupDistance Threshold.The thresholds are:- Cross Carrier Channel Assignment : Inner Tier Distance Threshold- Cross Carrier Channel Assignment : Inner Tier Minimum Ec/Io Threshold- Cross Carrier Channel Assignment : Outer Setup Distance Threshold- Cross Band Assignment : RF load differential offset- Cross Band Assignment : Load differential offset (in units of users)

The 1xEV-DO Support for Multi-Carrier Coverage Differences feature applies adistance threshold check before considering other carriers for the Load Differentialcheck or for traffic channel assignment. Only non-originating carriers for which thedistance from the sector to the AT is within the distance threshold for that carrierare considered. The distance threshold is translatable.

• Distance and pilot strength threshold checks on the accessed carrier, beforeallowing cross-band carrier assignment for connection setup in dual band cells.Carriers in the non-accessed band are considered for cross-band assignment onconnection setup only when the distance from the sector to the AT is within amaximum distance threshold for cross-band assignment and the Ec/Io measurementon the accessed carrier is above a minimum Ec/Io threshold for cross-bandassignment. The cross-band distance and pilot strength thresholds are translatable.

• A cross-band load differential parameter to favor same-band cross-carrierassignment over cross-band assignment when load balancing across carriers in dualband cells.If the Load Balancing Method parameter is set toNumber_of_Active_Users, across-band load differential is used to increase the effective loading (measured innumber of active users) for cross-band carriers. The cross-band load differential istranslatable.

• Service Measurements to track cross band assignments and confirmations for bothAT-initiated and Access Network (AN)-initiated connection setup attempts.


The 1xEV-DO Support for Multi-Carrier Coverage Differences feature is a standardfeature. Sevice providers control of the feature includes:

• Control of cross-band hashing (on/off) per sector.

• Selection of paging option (last seen band or both bands) per paging attempt indual band cells when cross band hashing isoff.

• Specification of an outer distance threshold (per sector, per carrier group) to qualifynon-originating carriers for traffic channel selection.



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

• Specification of a maximum distance and minimum Ec/Io threshold (per sector, percarrier group) on the accessed carrier before allowing cross-band carrier assignment

• Specification of two cross-band load differentials (per sector, per carrier group) toincrease the effective loading on cross band carriers.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


4-17

Feature description: Support of Multiple 1xEV-DO Carriers -IFHO feature (FID 8219.11)...................................................................................................................................................................................................................................

Introduction

The following information describes the functionality, benefits, and operation of theSupport of Multiple 1xEV-DO Carriers - IFHO feature.

Functionality

The Support of Multiple 1xEV-DO Carriers - IFHO feature provides support formultiple 1xEV-DO carriers - inter-frequency handoff (IFHO) and provides thecapability to perform handoff of an active 1xEV-DO connection from one carrier to adifferent carrier. With IFHO, a mobile user moving into a sector that does not have thecurrent service carrier can be handed off to a new carrier without dropping theconnection, providing a smooth transition.

Benefits

This feature provides improved session transfer time, reduces service interruption, andimproves the end-user experience for real-time applications such as video and audiostreaming.


This feature adds two new fields to the 1xEV-DO HOM output from theevdisphomcommand. These fields include counts for hard add completes and hard add attempts.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

1234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789

evstarthom command...................................................................................................................................................................................................................................

Abstract

The evstarthom command is used to start a 1xEV-DO HOM study.

Syntaxevstarthom [-h][-t DURATION]

Description

The evstarthom command initiates collection of handoff matrix data from all theRNCs associated with the OMP on which the command is run. Only one job may berun per Service Node at any time.

Options

The following options are available:

-t DURATION is the duration of the study in minutes. The default is 10 minutes, whichis also the minimum time for the study. The maximum time is 1440 minutes (24hours).

-h Displays help information.

Examplesevstarthom

This use of the command starts an EVDO HOM study for 10 minutes.

evstarthom -t 120

This use of the command starts an EVDO HOM study for 2 hours.

evstarthom -h

This version of theevstarthom command displays the usage message (helpinformation) for the user.

System Response

The initial response to this command is to the terminal of the requesting device. Thisindicates to the user whether the job could be successfully initiated.

evstarthomEVDO Handoff Matrix Session ID:xxxxEVDO Handoff Matrix Collection Started on RNC(s): x y


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


4-19

Important! This message is output after the session has been successfully startedon any of the associated RNCs so no errors or warnings appear in this outputmessage. Any further details on failures to start the job on subsequent RNCs, orerrors incurred after the job has initiated, are noted in the resultant output files.

Diagnostics

If the study starts successfully on all RNCs,evstarthom exits with an exit code ofzero. If the study starts successfully on at least one RNC, but not all RNCs, thecommand exits with an exit code of one. In both cases, a list of RNCs on which thestudy started is sent to the standard output and some error messages are sent to theerror file. In addition, a session ID which identifies the study is written to the standardoutput. This session ID is used to access an error file that may be created in the/omp-data/logs/hom/evdo_summary_filesdirectory to describe the errors in more detail.The name of the file isevstarthom.<session-ID>.error. This file contains the list ofRNCs on which the study could not be started. For each RNC, the failure reason isdisplayed.

The file status.<session-ID> in /omp-data/logs/hom/evdo_summary_filesis used toshow the progress of the EVDO HOM study with start time, duration, session-ID, stoptime, and so on.

If the study fails to start on all RNCs,evstarthom exits with a non-zero exit code.The following table lists some of the possible exit codes and their descriptions.

Table 4-1 Error Codes for evstarthom Command

Error Code Message

0 Study completed successfully

1 Study started on at least one RNC but not all RNCs

2 Failed to start the study at all RNCs

3 Invalid arguments

4 Unable to attach to shared memory

5 EVDO HOM feature is not active.

6 Another evstarthom or evdisphom process is running.

/ Another study is currently running. Wait for the study to becompleted and use theevdisphom command to collect the data lateror run evdisphom -s now to stop the study early and collect thedata.

9 No RNC is configured for HOM.

20 Other errors


evstarthom command

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789

1234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789

Sample file outputs

The following is the format of the error file generated by theevstarthom commandwhen the command cannot start the study on all RNCs.

SESSION:<Session-ID>ERROR_DATE:<Day> <Month and Date> <Time> <Year>HOM_START_FAIL_RNCS:<A list of RNCs on which the study failed to

start>HOM_START_SKIP_RNCS:<A list of RNCs that the study skipped because

each RNC is unequipped>HOM_START_STATUS:<status> where <status> indicates if the startcommand failed completely or not.

The following is the format of the status file generated by theevstarthom command:

HOM_START_IN_PROGRESSHOM_DURATION:<duration in minutes>HOM_START_TIME:<time in seconds>HOM_DATE_START_TIME:<time in string format>HOM SESSION:<session-ID>HOM_START_FRAME:<x>:<start-status> Where <x> is the RNC Number and

<start-status> is SUCCESS, FAIL, or SKIPHOM_START_FRAME:<y>:<start-status> Where <y> is the RNC Number and

<start-status> is SUCCESS, FAIL, or SKIPHOM_START_COMPLETED

Important! If one of the RNCs connected to the OMP is on Release 24, theevstarthom command just times out. No warning is given to the user that the RNCis Release 24.0. There is just no response from the frame.


evstarthom command

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


4-21

evdisphom command...................................................................................................................................................................................................................................

Abstract

The evdisphom command stops a HOM session and/or causes a request to retrieve theHOM data from each RNC for aggregation into a single output file of the namespecified by the-o option or the default file name. Depending on which options areselected, the command can just gracefully stop the HOM session or stop the sessionand collect the data. This command can also just collect the HOM data from the RNCsbut this can only be executed after theevdisphom -s command is executed or thesession has stopped on its own when the study timer expires.

Syntax

evdisphom [-o <output_file_name>] [-fshw]

Description

The evdisphom command causes a request for the OMP to retrieve the HOM datafrom each RNC for aggregation into a single output file of the name specified by the-o option or the default file name.

The aggregated data is available in a file that is prepared and stored on the OMPwithin 30 minutes of issuing the command. The default format for the output data istabular format.

Options

-o <output_file_name> where<output_file_name> is the name of the output file.This option cannot be used with the-s option unless the-w option is also used.

-f Display the data only separated by colons. This option cannot be used with the-soption unless the-w option is also used.

-h Displays the usage of theevdisphom command.

-s Stops a study gracefully. No collection of data occurs, however, unless this option isused along with the-w option.

-w This option, used with-s option, stops the HOM session and collects the data.

Examplesevdisphom


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

This use of theevdisphom command collects 1xEV-DO HOM data and failsimmediately if data is not available immediately. The output is in table format and thename of the output fileis evhom_table.<Session ID>. Theevhom_table.<SessionID>.errorfile is located at/omp-data/logs/hom/evdo_summary_files.

Use of theevdisphom command with no options only works when a HOM session hasalready ended, either on its own (by its timer expiring) or by the user havingpreviously runevdisphom -s to stop a study early.

Important! The service provider may see a failure message after issuing theevdisphom command. In this case you need to issue this command again. Thereason for this failure may be due to issuing theevdisphom command too quicklyafter stopping a study gracefully (evdisphom –s). It is recommended to wait aminute or so before issuingevdisphom after stopping the study.

evdisphom -o myOutPut

This use of theevdisphom command collects 1xEV-DO HOM data and failsimmediately if data is not available immediately. The output is in table format and thename of the output file ismyOutPut.The name of the error file ismyOutPut.error.Thiscommand only works when a HOM session has already been stopped.

evdisphom -s

This use of theevdisphom command stops an 1xEV-DO study gracefully withoutcollecting the data.

evdisphom -s -w

This use of theevdisphom command stops an 1xEV-DO study gracefully and waits fordata for 15 minutes. The output is in table format and the name of the output file isevhom_table..<Session ID>.. The name of the error file isevhom_table.<SessionID>.error.. The file is stored on the OMP in/omp-data/logs/hom/evdo_summary_files.

evdisphom -w

This use of theevdisphom command waits for data to be collected in 15 minutes. Itfails immediately if the study takes longer than 15 minutes to be completed.

evdisphom -s -w -f

This use of theevdisphom command stops an 1xEV-DO study gracefully and waits fordata for 15 minutes. The output is in colon-delimited format and the name of theoutput file isevhom_raw.<Session ID>. The name of the error file isevhom_raw.<Session ID>.error.

evdisphom -o myOutPut -s -w -f


evdisphom command

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


4-23

12345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789

12345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789

This use of theevdisphom command stops an EVDO study gracefully and waits fordata for 15 minutes. The output is in raw format and the name of the output file ismyOutPut.The name of the error file ismyOutPut.error.

evdisphom -h

This use of theevdisphom command displays the usage message for the user.

System Responses

evdisphomCollection of Files in Progress; Please WaitEVDO Handoff Matrix Session ID:<session ID>EVDO Handoff Matrix Collected on RNC(s): <RNC #>evdisphom -sStudy stopped on all RNCsEVDO Handoff Matrix Session ID:<session ID>EVDO Handoff Matrix Collection Stopped on RNC(s): <List of RNC #s>evdisphom -f -o file2Collection of Files in Progress: Please WaitEVDO Handoff Matrix Session ID:<session ID>EVDO Handoff Matrix Collected on RNC(s): <RNC #>

Important! It may be up to 15 minutes after thePlease Wait message appearsbefore data is available.

evdisphom -w -sStudy stopped on all RNCsEVDO Handoff Matrix Session ID:<session ID>EVDO Handoff Matrix Collection Stopped on RNC(s): <RNC #>Collection of Files in Progress; Please WaitEVDO Handoff Matrix Session ID:<session ID>EVDO Handoff Matrix Collected on RNC(s): <RNC #>

Important! It may be up to 15 minutes after thePlease Wait message appearsbefore data is available.

Diagnostics

If the command collects data from all RNCs,evdisphom is successful and exits withan exit code of zero. If the command collects data from at least one RNC but not all,the command exists with an exit code of one. The output file has the list of RNCs thatparticipated in the study. If one or more RNCs do not provide any data, the message


evdisphom command

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

WARNING: Incomplete data is written to the end of the output file. A list of RNCsparticipating in the collection along with the session ID of the study is also sent to thestandard output. More detail on errors found is in the error file.

If the data in the output file is not complete due to missing data for an AdjunctProcessor (AP), invalid data in an AP file, maximum number of records for the outputfile, and other reasons, the messageWARNING: Incomplete data is written to the endof the file.

If the command fails to collect data from all of the RNCs,evdisphom exits with anerror code of

The output file will contain only this messageWARNING: Collecting data failed for all RNCs. If the user specifies an outputfile and the output file exists, the existing output file is overwritten in any successfulor failure case without any warning.

If the command is not successful to stop or collect data from all RNCs, an error file iscreated. The error file contains more information about RNCs for which no data wascollected. Theftp.<session-ID> log file has information about transferring data filesfrom APs to the OMP. This file can be found at/omp-data/logs/hom/evdo_summary_files.

The file status.<session-ID> is used to show the progress of an 1xEV-DO HOMstudy. It shows start time, duration, session-ID, stop time, and so on. This file can befound at/omp-data/logs/hom/evdo_summary_files.

The following table lists some of the possible exit codes and their descriptions.

Table 4-2 Error Codes for evdisphom Command

Error Code Message

0 Study completed successfully

1 Study stopped or data is collected from at least one RNC but not allRNCs

2 Failed to stop or collect HOM data from any RNCs

3 Invalid arguments

4 Unable to attach to shared memory

5 EVDO HOM feature is not active.

6 Another evstarthom or evdisphom process is running.

8 Cannot create or write to output file.

9 No RNC is configured for HOM.

10 Study is in progress and data is not available.


evdisphom command

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


4-25

123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789

123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789

Table 4-2 Error Codes for evdisphom Command (continued)

Error Code Message

20 Other errors

Output data format

Colon-delimited output data format (-f option)

The output file consists of a header line and records. The output file may have awarning line, if there is an error such as incomplete data, at the end of the file. Thefirst line of the output is the header. The header has the following format:

EV-DO|HOMATRIX|<REL>|<START_DATE>|<STOP_DATE>|<SM>|<RNC_LIST>

The following table describes the variables in the header:

Table 4-3 Header Variables for evdisphom Command

Variable Description Example

<REL> HOM release number 26.0

<START_DATE> The start date and start time of the studyin a YYYYMMDDHHMMSS format

20050104142045

<STOP_DATE> The stop date and stop time of the studyin YYYYMMDDHHMMSS format

20050104143045

<SN> The Service Node ID 12

<RNC_LIST> The list of RNC IDs participating in thestudy (separated by″|″)

1|3|4

The header line for the above example looks like:

EVDO|HOMATRIX|26.0|20050104142045|20050104143045|12|1|2|4

There is one record for each FROM SECTOR in the service node that reported anyadds, drops, or attempts. The first two fields are the FROM cell ID and sector. The restof the record contains repeating groups of fields, one set for each TO SECTOR. Theformat of the records is:


evdisphom command

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789

<FROM_CELL>:<FROM_SECTOR>:<TO_SECTOR_DECL>:<TO_CELL_PNOFFSET>:<TO_SECTOR_CHAN>:<TO_ACTIVE_IP>:<SOFT_ADD_COMPLETE>:<SOFT_ADD_ATTEMPT>:<SOFT_DROP_COMPLETE>:<SOFT_DROP_ATTEMPT>:<HARD_ADD_COMPLETE>:<HARD_ADD_ATTEMPT>:

The following table describes the variables in the record:

Table 4-4 Record Variables for evdisphom Command


<FROM_CELL> This provides the originating cell numberof HOM(1-maximum number of cellssupported)

1

<FROM_SECTOR> This provides the originating sectornumber of HOM (1-6).

1

<TO_SECTOR_DECL> This is a flag indicating whether the Tocell-sector is a declared neighbor;y =declared neighbor,n= undeclaredneighbor.

y

or

n

<TO_CELL_PNOFFSET>

For a sector that is a declared neighbor,cell number(1-maximum number of cellssupported) is reported. For an undeclaredneighbor sector, PNOffset is reported(0-511).

112

<TO_SECTOR_CHAN> For a sector that is a declared neighbor,sector number (1-3) is reported. For anundeclared neighbor sector, channelnumber (0-2047) is reported.

2

<TO_ACTIVE_IP> For a sector that is a declared neighbor,AP IP address is reported. For anundeclared neighbor sector, this field doesnot apply - NA is reported.

135.5.143.6

<SOFT_ADD_COMPLETE>

This provides the soft/softer handoffcompletions (legs added) for declaredneighbor sectors.

6

<SOFT_ADD_ATTEMPT>

This provides the soft/softer handoffattempts for declared and undeclaredneighbor sectors.

12


evdisphom command

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


4-27

12345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789

123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789

Table 4-4 Record Variables for evdisphom Command (continued)


<SOFT_DROP_COMPLETE>

This provides the soft/softer legs droppedfor declared neighbor sectors; NA isreported for undeclared neighbor sectors.

12

<SOFT_DROP_ATTEMPT>

This provides the soft/softer legsattempted to be dropped for declaredneighbor sectors; NA is reported forundeclared neighbor sectors.

13

<HARD_ADD_COMPLETE>

Hard add complete count for declared or’_’ (NA for table format) for undeclaredneighbor.

14

<HARD_ADD_ATTEMPT>

Hard add attempt count for declared orundeclared neighbor.

15

The following is a sample record:

1:1:Y:112:2:135.5.143.6:12:12:13:14:15:134:Y:112:3:153.5.7.123:4:11:10:204

The WARNING line is used to specify that an error occurs during the collection of thedata. The format is:

WARNING:<warning-text>

An example of the<warning-text> is Incomplete data.

Important! It is possible that the output file does not have header and records dueto a problem such as collecting data has failed from all RNCs. In such a case, theoutput file has only the WARNING line.

Output data format (table format)

The output file consists of a header section and a table of records. The output file mayhave a WARNING line if there is an error such as incomplete data. The headercontains the same variables as described in output data format for the-f option above.The table contains the same fields as described for the-f option above, the onlydifference being they are displayed in an easier-to-read table format.

The following is an example of the output data in table format:


evdisphom command

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

12345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789

EVDO HANDOFF MATRIX RELEASE 26.0Start Date: 05/24/2005 Start Time: 14:11:27Stop Date: 05/24/2005 Stop Time: 14:21:27Service Node ID: 1

Reporting RNC(s): 1, 6

FROM

CELL

FROM

SECT

TO

SECT

DECL

DECL:

TOCELL

UNDEC:

PN

OFFSET

DECL:

TO

SECT

UNDEC:

CHAN#

TO

ACTIVE

APIP

ADD

COMPL

ADD

ATTEMP

DROP

COMPL

DROP

ATTEMP

HARD

COMPL

HARD

ATTEMP

132 1 Y 132 2 10.1.9.1 1 1 0 0 0 0

132 2 Y 132 1 10.1.9.1 0 0 1 1 0 0

Important! It is possible that the output file does not have header and records dueto a problem such as collecting data has failed from all RNCs. In such a case, theoutput file has only the WARNING line.


evdisphom command

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


4-29

Feature description: Six Sector Modular Cell 4.0B with Mixed1x and 1xEV-DO (FID 8882.2)...................................................................................................................................................................................................................................

Introduction

The following information describes the functionality, benefits, and operation of theSix Sector Modular Cell 4.0B with Mixed 1x and 1xEV-DO feature.

Functionality

The Six Sector Modular Cell 4.0B with Mixed 1x and 1xEV-DO feature extends theoperation of the 6-sector Modular Cell 4.0B to support more 1x carrier traffic than inits initial release (FID 8882.0). In addition, it supports a mixture of 1x carriers and one1xEV-DO Rev 0 carrier.

It is offered in the PCS Band and supports the following configurations in one-cabinet:

• up to six (6) 1x carriers per sector transmitting up to 16W/carrier, or

• up to five (5) 1x carriers and one (1) 1xEV-DO carrier per sector simultaneouslytransmitting up to 16W/carrier.

A 6-sector Cell transmitting 8W/carrier requiring less amplifiers than one transmitting16W, can support more carriers, for example, a single outdoor cabinet will support 71x carriers.

Benefits

This feature provides improved session transfer time, reduces service interruption, andimproves the end-user experience for real-time applications such as video and audiostreaming.


A set of External Voice Terminal Assembly/Vacuum Regulator (EVT/EVR) and/orSignaling Bus - 1xEV-DO Modem (SB-EVM) are required for 1xEV-DO operation.The 1xEV-DO Rev 0 carrier baseband signals are generated for two 3-sector groupsusing 2 sets of EVT/EVR or 2 SB-EVMs (FID 12078.17) or a combination of the 2,though RF transmitted in the same radio for each sector. As a result, softer hand-off issupported across 3 sectors of each group, for example, across “a” and across “ae”, notacross sectors of the 2 groups. Customers will have the choice of which sectors will beassigned to a particular card based on the actual Cell antenna sectorization. Forexample, actual adjacent sectors “ae” can be assigned to 1 SB-EVM while ”a” isassigned to the other SB-EVM.

The 1x carriers will continue to support 2-way softer hand-offs across all 6 sectors.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Due to its high capacity, it is recommended that this Cell be provisioned with URC-IIs(8973.1). Also, a dedicated Controller for 1xEV-DO Revision 0 (Rev. 0) processing isrequired when it is simultaneously supported with 1x.


This feature adds two new fields to the 1xEV-DO HOM output from theevdisphomcommand. These fields include counts for hard add completes and hard add attempts.


Feature description: Six Sector Modular Cell 4.0B withMixed 1x and 1xEV-DO (FID 8882.2)

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


4-31


Introduction

The 1xEV-DO HOM Tool feature does not interact with other features.

Important! The 1xEV-DO HO) Tool feature shares the same OMP with the CDMA(HOM Tool feature, but there is no interaction between the 1xEV-DO HOM tooland the CDMA HOM tool.


The 1xEV-DO Support for Multi-Carrier Coverage Differences feature builds on thefunctionality included in the following features:

• Support for Multiple 1xEV-DO Carriers (FID 8219.1)


Support for Multiple 1xEV-DO Carriers (FID 8219.1)

The Support for Multiple 1xEV-DO Carriers feature enhances the support of multiplecarrier feature in 8219.0. It allows more than one 1xEV-DO carrier to be supported ona URC1, and supports additional frequency band. It also supports multiple carriers onURC2.


The BC0/BC1 Dual Band 1xEV-DO feature enables the support of BC0/BC1 dual bandin the 1xEV-DO system. BC0 is the cellular (850) frequency band and BC1 is the PCS(1900) frequency band.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Service measurements: 1xEV-DO Support for Multi-CarrierCoverage Differences (FID 8219.9)...................................................................................................................................................................................................................................

Introduction

The 1xEV-DO Support for Multi-Carrier Coverage Differences feature affects thefollowing categories of services measurements.


The 1xEV-DO Support for Multi-Carrier Coverage Differences feature affects theservice measurements that are identified inTable 4-5, “1xEV-DO Support forMulti-Carrier Coverage Differences Feature: New Service Measurements” (p. 4-33).

Table 4-5 1xEV-DO Support for Multi-Carrier Coverage Differences Feature:New Service Measurements

Service measurementsubcategory


SECT-CARR-HDRC AN_INIT_CONN_ATTMPT_DIFF_BAND_RCVD

AN-Initiated ConnectionRequests Different BandReceived

SECT-CARR-HDRC AN_INIT_CONN_ATTMPT_DIFF_BAND_SENT

AN-Initiated ConnectionRequests Different BandSent

SECT-CARR-HDRC AT_INIT_CONN_ATTMPT_DIFF_BAND_RCVD

AT-Initiated ConnectionRequests Different BandReceived

SECT-CARR-HDRC AT_INIT_CONN_ATTMPT_DIFF_BAND_SENT

AT-Initiated ConnectionRequests Different BandSent

SECT-CARR-HDRC CROSS_BAND_ATTMPT_RCVD_TCC_RCVD

Cross-Band ConnectionAttempts Received -Established Connections

SECT-CARR-HDRC CROSS_BAND_ATTMPT_SENT_TCC_RCVD

Cross-Band ConnectionAttempts Sent - EstablishedConnections


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


4-33


Introduction

The 1xEV-DO HOM Tool feature is subject to the following special caveats.

Caveats

Caveat 1 - FROM CELL and FROM SECT Data

In 1xEV-DO, the AT sends a Route Update Message to all of the active sectors in theHOM data file. The sector that receives this message first is the sector that is listed asthe FROM cell-sector. As a result, the same handoff pattern may show different FROMcell-sectors. Also, when a sector is dropped, the FROM cell-sector may be the sectorthat is dropped.

Consider a call that is active on Cell 132, Alpha Sector. The call is then in soft handoffbetween Cell 132-Alpha and Cell133-Beta. Cell 132-Alpha is then dropped and the callis just active on Cell 133-Beta.

FROM

CELL

FROM

SECT

TO

SECT

DECL

DECL:

TOCELL

UNDEC:

PN

OFFSET

DECL:

TO

SECT

UNDEC:

CHAN#

TO

ACTIVE

APIP

ADD

COMPL

ADD

ATTEMP

DROP

COMPL

DROP

ATTEMP

HARD

COMPL

HARD

ATTEMP

132 1 Y 133 2 10.1.9.1 1 1 0 0 0 0

132 1 Y 132 1 10.1.9.1 0 0 1 1 0 0

In each case, the Route Update Message for adding Cell 133-Beta Sector is receivedby Cell 132-Alpha Sector. The dropping of the leg is somewhat different. In the firstcase, the Route Update Message to drop Cell 132-Alpha Sector is received by Cell133-Beta Sector first. In the second case, the Route Update Message to drop Cell132-Alpha Sector is received by Cell 132-Alpha Sector first. Either is acceptableoutput.

Caveat 2 - Output from Handoffs between Service Nodes

Handoff-matrix data is only collected on a particular service node which has theOverhead Manager (OHM) controlling the Access Terminal (AT) session. This controlof the AT session is only transferred to another OHM during an idle handoff. It is nottransferred during an active handoff.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

The output from the Handoff-matrix tool on a particular service node only listshandoffs where the FROM cell-sector is associated with an AP that is on the sameService Node where the data is being collected. Data where the FROM cell-sector isassociated with an AP that is on another service node does not appear in the outputtable. The other service node does not collect this handoff data until an idle transfer ofthe AT occurs to that particular service node. As a result, certain handoff data mightnot be captured by any OMP.

The data can possibly vary for the same call pattern if it is a handoff between servicenodes and the Route Update Message goes to different Cell-Sectors. Consider thefollowing:

• Cell 132: Sector Alpha is associated with an AP on Service Node 1.

• Cell 133: Sector Beta is associated with an AP on Service Node 2.

The call is initiated on cell 132 - Sector Alpha. The call goes into soft handoff betweenCell 132 - Sector Alpha and Cell 133 - Sector Beta. In this case, Cell 132 - SectorAlpha is dropped and the cell is only active on Cell 133 - Sector Beta.

FROM

CELL

FROM

SECT

TO

SECT

DECL

DECL:

TOCELL

UNDEC:

PN

OFFSET

DECL:

TO

SECT

UNDEC:

CHAN#

TO

ACTIVE

APIP

ADD

COMPL

ADD

ATTEMP

DROP

COMPL

DROP

ATTEMP

HARD

COMPL

HARD

ATTEMP

132 1 Y 133 2 10.2.5.1 1 1 0 0 0 0

FROM

CELL

FROM

SECT

TO

SECT

DECL

DECL:

TOCELL

UNDEC:

PN

OFFSET

DECL:

TO

SECT

UNDEC:

CHAN#

TO

ACTIVE

APIP

ADD

COMPL

ADD

ATTEMP

DROP

COMPL

DROP

ATTEMP

HARD

COMPL

HARD

ATTEMP

132 1 Y 133 2 10.2.5.1 1 1 0 0 0 0

132 1 Y 132 1 10.1.9.1 0 0 1 1 0 0


Issues and caveats

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


4-35

In the first output example, the service provider only sees the add and not the drop. Inthis particular example, the line for the drop should have been:

133 2 Y 132 2 10.1.9.10 0 1 1 0 0

This is because the from cell sector is Cell 133-Sector Beta which is associated withan AP that is on service nodeIt is not included in the table since no idle handoff hasoccurred between the AP on service node 1 and the AP on service nodeBoth tables areacceptable and possible outputs for this scenario.

Caveat 3 - Frame Number versus Frame ID

The R24 SM Configuration Data in the customer sites may have″Frame Number″instead of″Frame ID″ for each frame configured by SMconfig. In this case, 1xEV-DOHOM tool will fail. The customer should verify that the data in the SM ConfigurationData is correct in regard to the value of Frame ID for each frame. The customer canverify the data by using the SMconfig tool to display the SM configuration data. Ifthey are not correct, the customer needs to update the frame ID of each frame usingthe SMconfig tool.

Important! In order to determine the correct Frame ID for a frame, see documentCDMA2000® 1xEV-DO RAS Planning and Implementation Guide.,401-614-101.The Frame ID for AP x is “x” over 10 plus 1.

Caveat 4 - Search window size can be expanded temporarily to collect moreUndeclared Neighbors

Varying the remaining set search window size in configuration data can be helpful inidentifying undeclared neighbors because the AT is then able to demodulate additionalmulti-paths.

To clean up undeclared neighbors, the service provider can open up the remaining setsearch window on a cluster of cells for a few days while he or she runs EV-DO HOMstudies. When the investigation and any updates to the neighbor lists are complete, theuser can then set the window size back to its value before the study.

Important! Setting this window size to a high value may impact drop callperformance due to the additional searches the AT needs to do for the remainingpilots. The more time the AT spends searching for remaining pilots, the less itspends on active and neighbor pilots. Hence, if a neighbor pilot appears rapidly, forexample, it could impact drop performance since the active legs may deterioratebefore the neighbor can be added to the active set.


Issues and caveats

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Implementing the 1xEV-DO HOM feature (FID 12146.0)...................................................................................................................................................................................................................................

Overview

To implement the 1xEV-DO HOM Tool feature, perform the following procedure:“Activating the 1xEV-DO feature (FID 12146.0)” (p. 4-38)

“Activating the 1xEV-DO feature (FID 12146.0)” (p. 4-38)


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


4-37

Activating the 1xEV-DO feature (FID 12146.0)...................................................................................................................................................................................................................................

Purpose

This procedure activates the 1xEV-DO HOM Tool feature in aCDMA2000t® 1xEV-DOnetwork.

Procedure


...................................................................................................................................................................................................


EV-DO Handoff Matrix

E N D O F S T E P S...................................................................................................................................................................................................


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

5 5Per Call Measurement Data(PCMD) for CDMA 3G-1xEVolution Data Optimized(1xEV-DO)

Overview...................................................................................................................................................................................................................................

Purpose

This optional feature description describes the Per Call Measurement Data (PCMD) forCDMA 3G-1x Evolution Data Optimized (1xEV-DO) and Enhancements to EVDO PerCall Service Measurements optional features inCDMA2000® 1xEV-DO networks.

Feature summary

The following summarizes the features covered in this document and their PCMDimpact:

PCMD for 1xEV-DO

The PCMD for 1xEV-DO feature provides PCMD that supports the collection of datafor High-Speed Packet Data service for the EV-DO platform. The feature collectsEV-DO PCMD data and makes that data available in files on the OMP-FX v.2, and in″near real-time″ data streams. (The RNC sends EV-DO PCMD records in blocks to theOMP-FX, rather than send each record individually. The RNC sends a block of EV-DOPCMD messages when a maximum has been reached or when a timer has expired.)The PCMD for 1xEV-DO feature does not provide post-processing tools.

Enhancements to EVDO Per Call Service Measurements

The Enhancements to EVDO Per Call Service Measurements feature providesenhancements to 1xEV-DO PCMD to support Basic and Enhanced Rev A EV-DO,general PCMD, and service measurements. The enhancements include collection andprocessing of Route Update Message (RUM) data, also, the collection of PersonalitySwitch and QoS flow reservation data is included as part of Rev. A support.

New service measurements are added as part of this feature. For detailed informationon these service measurements, refer to, CDMA2000® 1xEV-DO ServiceMeasurements,401-614-326.

....................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


5-1

EVDO Service Measurements Enhancement - Phase 2

The EVDO Service Measurements Enhancement - Phase 2 feature provides 1xEV-DOService Measurement counts to improve performance assessment of 1xEV-DOnetworks:

• Session setup related connection attempt denial/failure

• Average forward link user throughput for Best Effort traffic

• Average number of handoff legs

• Connections rejected/blocked due to overload

• Busy slots for Best Effort (BE) and Expedited Forwarding (EF)

• Scheduler eligible users for all users and Expedited Forwarding (EF) users

• Control Channel slots usage

• Active Usage for Best Effort traffic

• New PCMD fields to identify cross-carrier activities

• Expand the RTD field in PCMD to store either 4-chip RTD value or 1/8-chip RTDvalue and add a new field indicate the granularity

Customer Critical Performance Measurements and Translations - Phase 3

The Customer Critical Performance Measurements and Translations - Phase 3 featureallows fast turnaround to address field issues that require Service Measurements,PCMD fields, or Translations in EVDO. It also provides for management of CriticalSMs, PCMD fields, and Translations that were used in prior release. This feature issupported by DO PCMD by the establishment of permanent sets of spare data fields ineach type of DO PCMD record - Primary, Flow and RUM records.


A unique Feature Identifier (FID) is assigned to each feature. This document supportsthe following features:

• PCMD for 1xEV-DO, FID 12269.0. (Release 26.0)

• Enhancements to EVDO Per Call Service Measurements, FID 12269.2

• EVDO Service Measurements Enhancement - Phase 2, FID 12370.1

• Customer Critical Performance Measurements and Translations - Phase 3, FID12766.2

Per Call Measurement Data (PCMD) for CDMA 3G-1xEVolution Data Optimized (1xEV-DO)

Overview

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


The PCMD for 1xEV-DO affects the user interfaces that are listed in the followingtable.


Element Management System(EMS) configuration management

For information on configuring parameters relatedto this feature, see“Implementing the feature”(p. 5-73).

Service measurements For information on configuring parameters relatedto this feature, see“Service measurement (SM)counts” (p. 5-15)


None

Contents

Availability 5-4

Prerequisites 5-5

PCMD terminology 5-6



How data is delivered to the OMP-FX v.2 5-11

Post-processing tool guidelines 5-15

Description of 1xEV-DO per-connection performance data delivered tothe OMP-FX v.2

5-26

Per-connection performance data output examples from the OMP-FX v.2 5-47

How data is accessed from the OMP-FX v.2 5-63

Using telnet to retrieve EV-DO PCMD data 5-64

Using FTP to retrieve EV-DO PCMD data 5-66

Using the EV-DO PCMD viewer to view EV-DO PCMD data 5-68

EV-DO PCMD viewer command format and syntax 5-70



Activating the PCMD for 1xEV-DO feature 5-74


Overview

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


5-3

Availability...................................................................................................................................................................................................................................


The features described in this chapter have the following release availability:

• The PCMD for 1xEV-DO feature is available in Releases 26.0 and later.

• The Enhancements to EVDO Per Call Service Measurements feature is available in1xEV-DO Release 27.0 and later.

• EVDO Service Measurements Enhancement - Phase 2 feature is available in1xEV-DO Release 30.0 and later.

• Customer Critical Performance Measurements and Translations - Phase 3 feature isavailable in 1xEV-DO Release 30.0 and later.

Market availability

The features listed in this chapter are available in all regions.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Prerequisites...................................................................................................................................................................................................................................

Introduction

The PCMD for 1xEV-DO feature has the following prerequisites.


The PCMD for 1xEV-DO feature is supported in the following air-interfacetechnologies:

• 1xEV-DO


The PCMD for 1xEV-DO feature requires DO-RNC Release 26.0 or later. The PCMDfor 1xEV-DO feature is not dependent on other features.

In Release 28.0 and later, 1xEV-DO PCMD is dependent on the following feature forRev. A support:

• Inter and Intra-RNC Handoff Enhancement (FID 12078.7)

• Application Based Quality of Service (QoS) Support for HRPD Rev. A (FID12078.9)


The PCMD for 1xEV-DO feature requires use of the Netra-440-based OMP-FX v.2.

In Release 27.0 and later, 1xEV-DO PCMD requires the service provider to have thefollowing 1xEV-DO Rev. A capable hardware:

• SBEVM for OneBTS

• SBEVMm for Modular Cells 1, 2, and 3


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


5-5

PCMD terminology...................................................................................................................................................................................................................................

Introduction

The following information defines terms that are specific to Per Call MeasurementData (PCMD).

PCMD event

A PCMD event is an event of interest to call processing and for troubleshooting callprocessing, such as, sessions, connections, and transfers. In Release 27.0, PCMDEvents also include Personality Change Attempts.

PCMD interval

The PCMD interval is the time between the occurrence of a PCMD event (when thePCMD record is created) and the time the PCMD record is complete and ready to besent to the OMP-FX. A PCMD record exists and is open for the duration of a PCMDinterval. For a particular Service Node, a PCMD records for a connection exists for theduration of that connection. A PCMD Session record lasts only for the time that isneeded to negotiate and begin a session, rather than for the entire duration of thesession.

Important! PCMD records uses Greenwich Mean Time (GMT) time.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Introduction

The following information describes the functionality, benefits, and operation of thePCMD for 1xEV-DO feature.

Functionality

The PCMD for 1xEV-DO feature collects selected data for connections and sessionsand reports this data via the OMP-FX v.2. The data includes connection technologydetails, resource usage, and connection failure information.

In Release 27.0 and later, the service provider can choose to include Route UpdateMessage (RUM) data from the first and last RUM that is received during each PCMDinterval, or the service provider can choose to include no RUM data in the PCMDrecord. This feature expands the data that is extracted from the RUM messages toinclude the fields shown inTable 5-18, “DO PCMD RUM Fields” (p. 5-42).

In Release 28.0 adds Flow Data which allows the collection information for up to eightFlows as part of the PCMD record. If data from more than eight flows is received, aduplicate record is created that contains the rest of the flow data information.

Benefits

The PCMD for 1xEV-DO feature provides valuable data that can help to monitor,maintain, and improve the performance and capacity for the EVDO systems.


The PCMD for 1xEV-DO feature collects performance data that relates to the EV-DOAccess Terminal (AT) connection path for data connections. Overall performance of thepacket data application is not within the scope of the PCMD for 1xEV-DO feature.

For details on how the PCMD for 1xEV-DO feature operates, see“How data isdelivered to the OMP-FX v.2” (p. 5-11).

The interval during which data is exchanged, previously referred to as a″call″ in othersystems, need not necessarily involve a″calling party,″ ″called party,″ or ″caller″ in theEV-DO system. Terminology to clarify this distinction is found inTable 5-1, “EV-DOterminology” (p. 5-7).

Table 5-1 EV-DO terminology

3G1X EV-DO

call connection

origination AT-Initiated Connection


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


5-7

Table 5-1 EV-DO terminology (continued)

3G1X EV-DO

termination AN-Initiated Connection

Pilot-Strength Measurement Message Route Update Message (RUM)

Summary of data collected

Data is collected for the EV-DO PCMD records as follows:

• EV-DO PCMD records include a field to indicate the EV-DO PCMD softwareversion which generated the EV-DO PCMD record to indicate the format of thedata.

• EV-DO PCMD includes Connection Final Class (CFC) values, as well as qualifiersspecifically applicable to EV-DO PCMD (for example, Radio Network Controller(RNC) resource data)

• EV-DO PCMD mirrors the existing 3G1X PCMD capabilities as well as the currentCFC values applicable to EV-DO

• EV-DO PCMD data storage is in the OMP, similar to the way that 3G1X data isstored in the 3G1X-associated OMP. This data has the same storage requirementsas far as the length of time the data is stored. However, the files are dedicated toEV-DO PCMD.

• EV-DO PCMD records are sent to OMP ports specific to EV-DO PCMD. Theassigned ports are different from those used by 3G1X PCMD data.

• The PCMD data for EV-DO is in a completely separate data stream and in separatedirectories from PCMD for 3G1X.

In Release 27.0 and later

• There is also a field to indicate the number of RUM records. This field can have avalue of either 0 or 1 and provides more detailed RUM data (seeTable 5-18, “DOPCMD RUM Fields” (p. 5-42).

• A Personality Type field is added for the type of AT that is involved in the PCMDevent.

• An additional field that reports the number of flow data into the PCMD record hasbeen added. For Release 27.0, the value for this field will always be none.

• In Release 28.0 PCMD reports Flow data as part of the Enhanced Rev-A support.


The PCMD for 1xEV-DO feature is transparent to subscribers.


Feature description

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Service perspective

The most widely used applications for EV-DO PCMD are for troubleshooting, forexample, detection, isolation, and correction of errors. Examples include:

• EV-DO PCMD collects all the data associated with the connection. This allowsquick response to customer trouble tickets. There is no need to recreate the failurescenario in the lab to understand why a connection failed or was dropped. Thisvirtually eliminates the drive test, which is very expensive and time-consuming.

• EV-DO PCMD can determine if a particular brand or model or even a specific ATis causing set-up failures and dropped connections. This enables isolation of theroot cause of the problem.

• EV-DO PCMD gives very useful information regarding RF coverage. Once thenetwork is established, the RF coverage can be analyzed by looking at signalstrength at the end of connections. Inadequate RF coverage can result in lostconnections, and signal strength at the time of a lost connection can be examined inthe EV-DO PCMD record. EV-DO PCMD can increase efficiency and reduce costsassociated with RF optimization and engineering.

Important! Service providers must set up their own post-processing tool to analyzethe data collected by the PCMD for 1xEV-DO feature. For guidelines on how to setup the tool, see“Post-processing tool guidelines” (p. 5-15).


Feature description

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


5-9


Introduction

The PCMD for 1xEV-DO, FID 12269.0 feature is subject to the following specialissues and/or caveats.

Issues

The message2 header lines are displayed is NOT an error message. The, PCMDfor 1xEV-DO feature deliberately behaves in this way when the daemon is re-started.

Caveats

The intention of the PCMD for 1xEV-DO feature is each time the daemon is re-starteda new header line is written to the raw data file for the current hour. This header lineserves as an indication that the daemon has re-started and that any data that was sentfrom the RNC during the time the daemon was inactive has been lost.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

How data is delivered to the OMP-FX v.2...................................................................................................................................................................................................................................

Introduction

This section describes how the OMP-FX v.2 method of data delivery operates.

Functions

The OMP-FX v.2 method of data delivery provides the following functions:

• Combines selected key data from the AMA record with per-connection performancedata

• Makes this data available to customer performance analysis applications(post-processing tools) via Internet-accessible ports on the OMP-FX v.2

Data delivery steps

When the OMP-FX v.2 is on-line, the EV-DO PCMD data is transferred from the RNCAP to the OMP and stored in an hourly file on the OMP (for file details, see“Storageof one hour of current data” (p. 5-12)).

Data delivery path diagram

Figure 5-1, “EV-DO PCMD data delivery path” (p. 5-12)shows the path of the PCMD1xEV-DO data transmission message that is sent after a connection ends. The EthernetInterface Node Enhanced (EINE) selects an available Mobility Manager B-ServerApplications Processor (AP) to route the message to the OMP-FX v.2.

Important! The EV-DO PCMD record always has fields for RUM data, even ifthey are null.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


5-11

EV-DO PCMD record viewer tools

Program tools calledevdo_rpcmdviewerandevdo_vpcmdviewerare available to displayper-call measurement data at the OMP-FX v.2. For details on the EV-DO PCMDViewer, see“Using the EV-DO PCMD viewer to view EV-DO PCMD data” (p. 5-68).

Storage of one hour of current data

The OMP-FX v.2 stores two types of data files: uncompressed data files of the currenthour and previous hour, and compressed data files of up to eight hours, resulting insaving up to ten hours of data files.

The OMP-FX v.2 accumulates the current hour’s worth of data on the OMP-FX v.2disk. When the current hour is up, the OMP-FX v.2 moves the data for the currenthour to a separate, uniquely named file for the previous hour.

To access the stored data files (current and previous), the user can run File TransferProtocol (FTP) software for the files. The files are ASCII text with fields that areseparated by a delimiter (″;″ or ″|″), which is also called the″raw″ format. For adescription of the raw format, see“Per-connection performance data output examplesfrom the OMP-FX v.2” (p. 5-47).

The stored files are located in the following directory:

Figure 5-1 EV-DO PCMD data delivery path


How data is delivered to the OMP-FX v.2

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

/omp/omp-data/logs/evdo_pcmd

The naming convention for the files is as follows:

YYMMDDHH.EVDOPCMD

where

YY = year

MM = month

DD = day

HH = hour at the end of the data collection period (in 24-hour format, for example, 15is 3:00 PM)

Configured OMP-FX v.2 ports

The following configuration files define the port allocations for the OMP-FX v.2method of data delivery:

/etc/inittab

/etc/services

/etc/inetd.conf

crontab

Important! These files are configured as the OMP package is installed on thesystem and are not done manually.

/etc/services file

The /etc/servicesfile defines the services that are available via remote telnetconnection to the OMP-FX v.2. These services map to the following five portallocations:

evdo_vpcmdviewer7050 7050/tcp

evdo_rpcmdviewer7051 7051/tcp




Port 7050 is reserved for human readable format (also called the″verbose″ format).Ports 7051 through 7054 are reserved for an ASCII version with fields that areseparated by a delimiter (″;″ or ″|″) (also called the″raw″ format).

Important! By default, theevdo_vpcmdviewerdisplays 10 records and then quits.Limiting the number of output records conserves CPU space. You can use thesyntaxevdo_vpcmdviewer -n, with n having a value greater than zero and a



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


5-13

maximum value that fits into a signed integer (2, 147, 483, 647), to change thenumber of EVDO PCMD records that are displayed. If the number provided is lessthan 1,evdo_vpcmdviewerdisplays 10 records.

/etc/inetd.conf file

The /etc/inetd.conffile defines the services that are available directly from theOMP-FX v.2 with theevdo_pcmd command and the OMP-FX v.2 port number. Theoutput format of the EV-DO PCMD data is decided by the port number the userspecifies:

eevdo_vpcmdviewer7050 stream tcp nowait root /omp/bin/evdo_vpcmdviewerevdo_vpcmdviewer

evdo_rpcmdviewer7051 stream tcp nowait root /omp/bin/evdo_rpcmdviewerevdo_rpcmdviewer




Port 7050 is reserved for the verbose (human readable) format. Ports 7051-7054 arereserved for the raw Access and Cross Connect System II (ASCII) version with fieldsthat are separated by a delimiter (″;″ or ″|″).

/etc/inittab file

The following entry is made in the /etc/inittab file:

IT56:a:respawn:/omp/sbin/evdo_pcmdaemon

See also

For guidelines on how to develop post-processing tools, see“Post-processing toolguidelines” (p. 5-15).

For a description of the EV-DO PCMD record that is delivered to the OMP-FX v.2,see“Description of 1xEV-DO per-connection performance data delivered to theOMP-FX v.2” (p. 5-26).

For examples of verbose and raw data output formats, see“Per-connection performancedata output examples from the OMP-FX v.2” (p. 5-47).



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Post-processing tool guidelines...................................................................................................................................................................................................................................

Introduction

Post-processing tools can be developed to produce a wide variety of reports to analyzeand troubleshoot system performance. The following examples illustrate the types ofqueries that can be run against the EV-DO PCMD data.

Example 1

For all cells, generate the number of connections with

• CFC 9 (Origination Failed—Cell Problem)

• CFC Qualifier of Traffic Channel Unavailable

Example 2

For a given sector and carrier, list all AT Electronic Serial Numbers (ESNs) thatproduced a Traffic Channel Confirmation failure. These failures result in failedconnection attempts. With the ESN, you can determine manufacturer and modelnumber of the AT.

Guidelines

Use the following guidelines during development of post-processing tools:

Guideline Page

“OMP-FX v.2 ports” (p. 5-15) “OMP-FX v.2 ports” (p. 5-15)

“Service measurement (SM) counts” (p. 5-15)“Service measurement (SM)counts” (p. 5-15)

“CFC Qualifiers and their meanings” (p. 5-21)“CFC Qualifiers and theirmeanings” (p. 5-21)

“Connection Final Class field usage” (p. 5-20)“Connection Final Class fieldusage” (p. 5-20)

OMP-FX v.2 ports

Set up the post-processing tools to access the desired OMP-FX v.2 port (7050 or 7051)as described in“Configured OMP-FX v.2 ports” (p. 5-13).

Service measurement (SM) counts

Up to nine SM counts are included in EV-DO PCMD records.

For detailed information about the following service measurements, see CDMA2000®

1xEV-DO Service Measurements,401-614-326


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


5-15

Key service measurements

The PCMD for 1xEV-DO feature provides fields in the EV-DO PCMD data record tostore key service measurements which are updated during the processing of aconnection. This feature does not define these counts, but it does define a subset of thetotal number of potentially generated measurements during a connection whosepegging may be flagged in the EV-DO PCMD record as the associated code inTable5-2, “Key service measurements” (p. 5-16). This allows better fault isolation fordetermining the reason for a dropped connection. The Read-Only-Printer (ROP)Message IDs are included as the Secondary CFCQ for Dropped Connections inTable5-6, “Dropped connection qualifiers” (p. 5-22).

Table 5-2 Key service measurements

Code Count = Explanation

01 AN_INIT_CONN_ATT_FAIL_CONFIG_NEGO_FAILED

= AN-initiated Connection attempt failures - negotiation fail

02 AN_INIT_CONN_ATTMPT_FAIL_NO_TCC_RCVD

= (AN- initiated Connection attempt failures - no response to traffic

channel assignment traffic channel confirmation received

03 AN_INIT_CONN_ATTMPT_FAIL_RL_NOT_ACQ

= AN- initiated Connection attempt failures - rev link not acquired

04 AN_INIT_CONN_ATTMPT_FAIL_NO_RES_AVLBL

= AN- initiated connection attempt failures - no resources available

05 AN_INIT_CONN_ATMPT_FAIL_OTHER_PRETCA

= AN- initiated Connection attempt failures - other failures pre TCA

06 AN_INIT_CONN_ATMPT_FAIL_OTHER_POSTTCA

= AN- initiated Connection attempt failures - other failures pre TCA

07 AT_INIT_CONN_ATT_FAIL_CONFIG_NEGO_FAILED

= AT- initiated Connection attempt failures - negotiation fail

08 AT_INIT_CONN_ATTMPT_FAIL_NO_TCC_RCVD

= AT- initiated Connection attempt failures - no traffic channel confirmationreceived response to traffic channel assignment

09 AT_INIT_CONN_ATTMPT_FAIL_RL_NOT_ACQ

= AT- initiated Connection attempt failures - rev link not acquired

10 AT_INIT_CONN_ATTMPT_FAIL_NO_RES_AVLBL

= AT- initiated connection attempt failures - no resources available


Post-processing tool guidelines

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Table 5-2 Key service measurements (continued)


11 AT_INIT_CONN_ATMPT_FAIL_OTHER_PRETCA

= AT- initiated Connection attempt failures - other failures Pre TCA

12 AT_INIT_CONN_ATMPT_FAIL_OTHER_POSTTCA

= AT- initiated Connection attempt failures - other failures Post TCA

13 FAST_CONNECT

= Number of fast connection requests

15 FAST_CONNECT_FAIL_NO_TCC_RCVD

= Number of fast connection attempt failures due to no Traffic ChannelConfirmation received

16 FAST_CONNECT_FAIL_NOT_RL_ACQ

= Number of fast connection attempt failures due to no reverse link beingacquired

17 AN_INIT_CONN_REQ

= AN-Initiated Connection Requests

18 TCA_FOR_AN_INIT_CONN_REQ

= Traffic Channel Assignments for AN Initiated Connection Requests

19 AT_INIT_CONN_REQ

= AT Initiated Connection Requests

20 TCA_FOR_AT_INIT_CONN_REQ

= Traffic Channel Assignments for AT Initiated Connection Requests

21 CONN_REL_RLL

= Connection Release - RF Link Lost

22 CONN_REL_OTHER_REASON

= Connection Release - Other Reasons

28 INT_SUBNET_IDL_TRFR_ATTMPT

= Number of Inter Subnet Idle Transfer Attempts

29 PERS_SWTCH_CONN_TCA

= Traffic Channel Assignments for Personality Switch

30 PERS_SWTCH_CONN_ESTABLISHED

= Established Connections for Personality Switch

31 CONN_SETUP_PERS_SWTCH_UNKNOWN_TO_REVA

= Personality Switches During Connection Setup from Unknown to Rev A



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


5-17

Table 5-2 Key service measurements (continued)


32 CONN_SETUP_PERS_SWTCH_REL0_TO_REVA

= Personality Switches During Connection Setup from Rel 0 to Rev A

33 CONN_SETUP_PERS_SWTCH_REVA_TO_REL0

= Personality Switches During Connection Setup from Rev A to Rel 0

34 AHO_PERS_SWTCH_REVA_TO_REL0

= Personality Switch During Active Connections from Rev A to Rel 0

35 RAN_AUTH_TOTAL_ATTMPT

= RAN Authentications – Total Attempts

36 RAN_AUTH_SUCCESSFUL_ATTMPT

= RAN Authentications – Successful Attempts

37 RAN_AUTH_FAIL_INTERNAL

= RAN Authentications – Internal Failure

38 RAN_AUTH_FAIL_STREAM_SELECTION_FAILED

= RAN Authentications – Stream Selection Failures

39 RAN_AUTH_FAIL_AT_CONFIG_RJCT_RCVD

= RAN Authentication Failure – AT Configuration Reject Received

40 RAN_AUTH_FAIL_INVLD_AT_CFGRQ_PPP_EST_FLD

= RAN Authentication Failure – Invalid AT Configuration Request PPPEstablishment Failed

41 RAN_AUTH_FAIL_LCP_RLTD_PPP_EST_FAILED

= RAN Authentication Configuration - ACK Related PPP EstablishmentFailures

42 RAN_AUTH_FAIL_CNFGR_NAK_PPP_EST_FAILED

= RAN Authentication Configure- NAK Related PPP Establishment Failures

43 RAN_AUTH_FAIL_LCP_TERM_RCVD

= RAN Authentication Failures – LCP Termination Received

44 RAN_AUTH_FAIL_NO_AT_CONFIG_RQST_RCVD

= RAN Authentication Failures - No AT Configure Request Received



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

The EVDO Service Measurements Enhancement - Phase 2 feature (FID 12370.1)introduces new service measurement counts to improve performance assessment of1xEV-DO networks for both Rev. 0 and Rev. A. SeeTable 5-3, “SMs for DO SMEnhancements Phase 2” (p. 5-19).

Table 5-3 SMs for DO SM Enhancements Phase 2


45 AT_INIT_CONN_ATTMPT_FAIL_NO_RES_AVLBL_SESS

= AT-Initiated Connection Attempt Failures - No Resource Available -SessionSetup Short

46 AT_INIT_CONN_ATTMPT_FAIL_RL_NOT_ACQ_SESS

= AT-Initiated Connection Attempt Failures - Reverse Link Not Acquired -Session Setup Short

47 AT_INIT_CONN_ATTMPT_FAIL_NO_TCC_RCVD_SESS

= AT-Initiated Connection Attempt Failures - No Traffic Channel CompleteReceived - Session Setup Short

48 AT_INIT_CONN_REQ_SESS

= AT Initiated Connection Request - Session Setup Short

49 TCA_FOR_AT_INIT_CONN_REQ_SESS

= AT Initiated Connection Request TCA Sent - Session Setup Short

50 AT_INIT_ESTABLISHED_CONN_SESS

= AT Initiated Connection Request Established Connections - Session SetupShort

51 SESS_SETUP_REQ_POOR_RF_ALLOW

= Session Setup Request Poor RF Allow Short

52 SESS_SETUP_REQ_POOR_RF_DENY

= Session Setup Request Poor RF Deny Short



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


5-19

Connection Final Class field usage

The CFC assignment is made at the end of every 1xEV-DO connection. The CFCvalue is a broad classification defining success or failure of the connection as well asthe approximate site of failure (EV-DO, RNC, cell, or access terminal). CFC values arelisted in Table 5-4, “CFC values” (p. 5-20)with the additional values appearing inadjacent tables:

Table 5-4 CFC values

Value Meaning Additional information

1 normal connection The connection ended without any failureconditions. SeeTable 5-5, “Normalconnection qualifiers” (p. 5-21)foradditional qualifiers for this value.

2 dropped connection The connection attempt was completed butthen was dropped or lost. SeeTable 5-6,“Dropped connection qualifiers” (p. 5-22)for additional qualifiers for this value.

3 AT/AN Connection attemptfailed—subscriber

The AT/AN-originated connection attemptwas unsuccessful due to a problem withthe subscriber’s account or AT unit. SeeTable 5-7, “AT-Initiated/AN-InitiatedConnection Failed - Subscriber” (p. 5-22)for additional qualifiers for this value.

Expectation to see the digit 3 withoutextra information or value for others.CFCQ values are not there and will beexpanded in the future.

9 AT/AN Connection attemptfailed—cell

The AT/AN-originated connection attemptfailed due to a cell-related error orblockage. SeeTable 5-8, “AT-Initiated/AN-Initiated Connection Failed - Cell”(p. 5-23) for additional qualifiers for thisvalue.

11 AT/AN Connection attemptfailed— network elementindependent

The AT/AN-originated connection attemptfailed and the exact cause wasundetermined.

20 AT/AN Connection attemptfailed— RNC

The AT/AN-originated connection attemptfailed due to an RNC-related error. SeeTable 5-9, “AT-Initiated/AN-InitiatedConnection Failed - RNC” (p. 5-23)foradditional qualifiers for this value.



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Table 5-4 CFC values (continued)

Value Meaning Additional information

22 AT/AN Connection attemptfailed—network

The AT/AN-originated connection attemptfailed due to a network-related error orblockage. SeeTable 5-10,“AT-Originated/AN-Originated ConnectionFailed - Network” (p. 5-24)for additionalqualifiers for this value.

CFC Qualifiers and their meanings

The CFC Qualifier field builds on the CFC field to more narrowly isolate the cause ofconnection failures.Table 5-5, “Normal connection qualifiers” (p. 5-21)throughTable5-10, “AT-Originated/AN-Originated Connection Failed - Network” (p. 5-24)list theCFC Qualifiers (CFCQs) used by the PCMD for 1xEV-DO feature and any additionalcriteria that the PCMD for 1xEV-DO feature uses to apply to the qualifier.

Table 5-5 Normal connection qualifiers

Value Qualifier Additional Information

001 Connection established andreleased normally.

002 Connection released early by AT. This is an indication of auser-initiated connection end orHybrid AT hand-down to 1X

005 Connection attempt interruptedby Idle Transfer.

This indicates that the AT did anIdle transfer to another RNCbefore the connection attemptcould complete.

021 Connection forced to dormancyearly due to congestion control.

Forced dormancy can be used forintra-user QoS or congestioncontrol

022 Connection forced to dormancyearly due to QoS priority.

Forced dormancy can be used forintra-user QoS or congestioncontrol.

023 Connection Personality ChangeAttempt

Secondary CFCQ indicates newpersonality type requested.

024 Connection Session Close ByOperator

Session closed by operatorcommand.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


5-21

Table 5-6 Dropped connection qualifiers


Possiblesecondaryqualifier

100 Dropped connection The connection was dropped aftertraffic channel confirmation.

—

106 Lost Connection Cell has detected a loss of RFcontinuity. This is an ending of aconnection due to failures otherthan in the network, such as theAT, or when no TCC wasreceived during a soft/softerhandoff attempt.

—

120 RNC Disconnect Connection was dropped due to aloss of communication betweenthe cell and the RNC.

—

122 AT Tune-AwayTimeout

The AT tuned away and did notreturn within the timeout period(″fade timer″).

—

Table 5-7 AT-Initiated/AN-Initiated Connection Failed - Subscriber


Possiblesecondaryqualifier

300 AT/AN-InitiatedConnectioninhibited —temporary accountsuspension

1=RAN-authentication failure —

304 ConfigurationNegotiation Failure

Failure occurred duringConfiguration Negotiationexchange.

—

305 Communicationfailed with AT

Communication with AT failed. —

310 AT-Initiated SessionClose

AT initiated session close due toan error detected at AT.

—



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Table 5-8 AT-Initiated/AN-Initiated Connection Failed - Cell


Possiblesecondaryqualifiers

901 Traffic channelconfirmation failure

0 = No indication that ATacquired reverse link

1 = No Traffic Channelconfirmation received

—

902 Resource Mismatch QoS Backhaul expectation —

903 Traffic channelunavailable

Traffic Channel could not beobtained

—

904 Internal cellprocessing error

Undetermined hardware orsoftware error

—

Table 5-9 AT-Initiated/AN-Initiated Connection Failed - RNC


Possiblesecondaryqualifiers

2001 AP-related softwarefailure

Failure was due to an internal APsoftware problem, for example,database error or expired timers.

—

2002 ConfigurationFailure

Failure during ConfigurationNegotiation

—

2003 Internal RNCcommunicationfailure

Communication between AP &TP or AP to AP-reasons notspecified

—

2004 No TP available The connection failed due to lackof a TP in the RNC

—

2007 TP protocol failure Protocol error between TP andcell

—



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


5-23

Table 5-10 AT-Originated/AN-Originated Connection Failed - Network

Value Qualifier Additional InformationPossible secondaryqualifiers

2202 A10/A11 path setupfailure

The connection failedbecause the path betweenthe RNC and PDSN failed.

Secondary ConnectionFinal Qualifier

1 = PDSN RejectedREQUEST_REASON_UNSPECIFIED

2 = PDSN RejectedREQUEST_ADMISTRATIVELY_PROHIBITED

3 = PDSN RejectedREQUEST_INSUFFICIENT_RESOURCES

4 = PDSN RejectedREQUEST_AUTHENTICATION_FAILED

5 = PDSN RejectedREQUEST_IDENTIFICATION_MISMATCH

6 = PDSN RejectedREQUEST_POORLY_FORMED_REQUEST

7 = PDSN RejectedREQUEST_UNKNOWN_PDSN_ADDRESS

8 = PDSN RejectedREQUEST_REVERSE_TUNNEL_UNAVAILABLE

9 = PDSN RejectedREQUEST_REVERSE_TUNNEL_MANDATORY

10 = PDSN RejectedREQUEST_UNSUPPORT_VENDORID

2203 AuthorizationException

Connection could not beestablished due to failure toauthor license.

—



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Table 5-10 AT-Originated/AN-Originated Connection Failed - Network(continued)

Value Qualifier Additional InformationPossible secondaryqualifiers

2206 PDSN-initiatedclosure

PDSN sends registrationupdate message

—

2207 AAA comm.failures

The communicationbetween RNC and AAAfailed.

—



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


5-25

Description of 1xEV-DO per-connection performance datadelivered to the OMP-FX v.2...................................................................................................................................................................................................................................

Introduction

This section describes the 1xEV-DO per-connection performance data that is deliveredto the OMP-FX v.2.

EV-DO PCMD Record Format

Each EV-DO PCMD record may have up to 67 different fields within the followingcategories:

• Administrative Fields

• Session Detail Fields

• Connection Detail Fields

• RLP Layer Detail Fields

• Key Service Measurements

• Personality Type

• Additional Data

• Route Update Message Data

• Flow Data

EV-DO PCMD record length

The 1xEV-DO PCMD record has a fixed number of fields. There are always six fieldsfor service measurements. Data for six legs is always sent/output, even if not all of thelegs have data. In Release 27.0 and later, the PCMD record has a variable length dueto the service provider option to include or exclude RUM data.

Data table

The following tables list the total possible data set that can be collected for eachconnection that qualifies for 1xEV-DO PCMD data collection:

• Table 5-11, “EV-DO PCMD record data fields - Administrative” (p. 5-28)

• Table 5-12, “EV-DO PCMD record data fields - Session” (p. 5-29)

• Table 5-13, “EV-DO PCMD record data fields - Connection” (p. 5-31)

• Table 5-14, “EV-DO PCMD record data fields - RLP Layer” (p. 5-36)

• Table 5-15, “EV-DO PCMD record data fields - Key Service Measurements”(p. 5-36)

• Table 5-16, “EV-DO PCMD record data fields - Personality Type:” (p. 5-38)

• Table 5-17, “EV-DO PCMD record data fields - Additional Data” (p. 5-38)


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

• Table 5-19, “Flow Data Fields” (p. 5-44)

• Table 5-20, “Flow Final Classes (FFC) and FFC Qualifiers for Flow Reservation”(p. 5-46)

Sequence of fields in the table

The fields inTable 5-11, “EV-DO PCMD record data fields - Administrative” (p. 5-28)throughTable 5-17, “EV-DO PCMD record data fields - Additional Data” (p. 5-38)arein the same sequence as the fields in the raw and verbose output data. For examples ofthe raw and verbose output data, see“Per-connection performance data outputexamples from the OMP-FX v.2” (p. 5-47).

Column descriptions

The following table describes each column in:

• Table 5-11, “EV-DO PCMD record data fields - Administrative” (p. 5-28)

• Table 5-12, “EV-DO PCMD record data fields - Session” (p. 5-29)

• Table 5-13, “EV-DO PCMD record data fields - Connection” (p. 5-31)

• Table 5-14, “EV-DO PCMD record data fields - RLP Layer” (p. 5-36)

• Table 5-15, “EV-DO PCMD record data fields - Key Service Measurements”(p. 5-36)

• Table 5-16, “EV-DO PCMD record data fields - Personality Type:” (p. 5-38)

• Table 5-17, “EV-DO PCMD record data fields - Additional Data” (p. 5-38)

• Table 5-19, “Flow Data Fields” (p. 5-44)

• Table 5-20, “Flow Final Classes (FFC) and FFC Qualifiers for Flow Reservation”(p. 5-46)

Column number Column name Description

1. Field number Numbers the fields as aconvenient reference. Thefields in the actual outputare not numbered.

2. Length Provides the actual lengthof the data in the field inbits or bytes, asappropriate.

3. Verbose output field name Is the name of the fieldas it appears on theverbose output.

4. Field description Describes the field and itsusage.


Description of 1xEV-DO per-connection performance datadelivered to the OMP-FX v.2

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


5-27

Column number Column name Description

5. Range of values Provides a range ofvalues that the field cancontain.

Important! Except where specifically noted, all fields in the EV-DO PCMD recordare set to null prior to being populated with any other data

Important! All time stamp fields are represented as milliseconds after midnight.

Table 5-11 EV-DO PCMD record data fields - Administrative

Fieldnumber Length

Verbose outputfield name Field description Range of values

1. 2bytes

PCMD softwaredata format version

Identifies data layout.Unique for each release.

Starts with 1 andincrements by 1each time there is anew version of thedata output format:

1 = Release 26.0

2. 4bytes

Sequence Number(assigned at OMP)

Sequence number that isincremented for eachconnection record.

Starts with 0 andincrements by 1each time there is anew connectionrecord, up to amaximum of 232,and then resets to0.

3. 2bytes

Month and Day Month and day Any valid monthand day in MMDDformat.

4. 8bytes

Duplicate RecordSequence Number

Denotes that this recordis an initial primaryPCMD record.

Always zero inRelease 27.0.

5. 1 byte Mobile ID Type Mobile Serial Number(MSN) (ESN/MEID)

0 = ESN

1 = MEID

6. 8bytes

Mobile ID MSN ESN/MEID eight-digithexadecimalnumber



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Table 5-11 EV-DO PCMD record data fields - Administrative (continued)

Fieldnumber Length


7. 8bytes

InternationalMobile StationIdentifier

International MobileStation Identifier (IMSI)

15 digits(maximum)

Table 5-12 EV-DO PCMD record data fields - Session

Fieldnumber Length

Verboseoutput fieldname

Fielddescription Range of values

8. 4bytes

UATI Unicast AccessTerminalIdentifierpopulated whenthe UATICompletemessage isreceived.

32-bits displayed in hexadecimalformat and derived from thelower 24 bits of the UATI128plus the 8-bit color code.

9. 4bytes

UATI CompleteMessageReceived Time

Timestamp ofwhen UATICompleteMessagereceived at theRNC from theAT.

32-bits stored as millisecondsafter midnight.

10. 4bytes

RATI Random AccessTerminalIdentifiergeneratedduring sessionsetup attempt.

32-bits

11. 4bytes

Control OHMAP ID Address

ApplicationsProcessorIdentifiersupporting theevent in theform of an IPaddress.

—



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


5-29

Table 5-12 EV-DO PCMD record data fields - Session (continued)

Fieldnumber Length



12. 1 byte SessionRequest Type

Indicates thesession requesttype.

0 = Not for Session

1 = RATI New Session Setup

2 = Idle Session Transfer

3 = Idle Session Transfer - PriorSession

4 = Load Balancing with an RNCgroup

5 = Connection withConfiguration Negotiation Data

13. 1 byte Session SetupFinal Class

Indicates thedisposition ofthe sessionsetup.

0 = Success

1 = Failure, UATI Complete NotReceived

2 = Connection Setup to doConfiguration Negotiation Failed

3 = Failure, ConfigurationNegotiation Failed

4 = Failure, Idle Transfer InternalError

5 = Failure, UATI AssignmentFailed

6 = Failure Request fromunidentified AT

7 = Failure Service Denial -Network DHZ Violation

8 = Failure Service Denial -Network Other

9 = Failure AT-Initiated SessionClose



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Table 5-12 EV-DO PCMD record data fields - Session (continued)

Fieldnumber Length



14. 4bytes

Session orConnectionCPFail Value

Provides detailson why thesession setupfailed.

CP Failure Codes will bereported in the field. this CPFailure Codes will be associatedwith PCMD sessions connectionevent.

The CP Failure Code will beassociated with the PCMDsession or connection event.

15. 4bytes

SessionSetup/TransferRequest Time

Contains atimestamp ofwhen the UATIRequestMessage isReceived.

—

16. 4bytes

SessionSetup/TransferComplete Time

Contains atimestampindicating thetime thesession becameactive. Thetime is thepoint at whichthe AT canrequest aconnection.

—

Table 5-13 EV-DO PCMD record data fields - Connection

Fieldnumber Length

Verboseoutput fieldname Field description Range of values

17. 4bytes

ConnectionRequest Time

The time the request wasreceived by the AP.

—

18. 4bytes

ConnectionEstablishedTime

Timestamp indicating thetime the traffic channel wassuccessfully established.

—



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


5-31

Table 5-13 EV-DO PCMD record data fields - Connection (continued)

Fieldnumber Length


19. 4bytes

A12 RANAuthenticationTime

The time the AT has beenRAN authenticated.

—

20. 4bytes

A10 LinkEstablishedTime

The time the A10 link wassuccessfully established.

—

21. 4bytes

ConnectionDuration

The time the sessionbecomes dormant.

—

22. 1 byte ConnectionFinal Class

Indicates the connectionended normally, wasdropped, or lost.

See values in Table5-3, CFC values.

23. 2bytes

CFC Qualifier Indicates the connection wasestablished and releasenormally.

See values in Table5-4, through Table5-9..

24. 4bytes

Secondary CFCQualifier

Indicates the connection wasestablished and releasednormally and conditionsdetected.

—

25. 1 byte AT- orAN-InitiatedConnectionRequest

Defines the type ofconnection request.

0 = AT-Initiated

1 = AN-Initiated

2 = Fast Connect

26. 1 byte SilentReoriginationFlag

Indicates that at least onesilent reorigination occurredduring the associated PCMDInterval.

Always zero inR26.

27. 1 byte Service NodeID

The service node handlingthe connection at the timethe connection is closed(returned to dormancy). Thisis the OMP identifier.

0-255

28. 4bytes

TP forConnection

Indicates the trafficprocessor used for theconnection identified by theIP address.

—



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Fieldnumber Length


29. 4bytes

PDSN IP No. Indicates the address. —

30. 2bytes

Seizure CellNumber

Populated after the Cell Siteidentifier is available.

1-maximum numberof cells supported

31. 1 byte Seizure SectorNumber

Populated once for a PCMDas soon as the data isavailable.

0-6

32. 2bytes

LastDRC-PointedCell

Indicates the DRC-pointedcell site number when theconnection was beingreleased.

0-maximum numberof cells supported

33. 1 byte LastDRC-PointedSector Number

Indicates the ID of the lastsector to which the DatarateControl message pointed.

0-6

34. 1 byte Number of DOpages

Indicates the number of DOpages leading to set up aconnection. This field is setonly for AN-initiatedconnections.

0-255

35. 4bytes

ConfigurationNegotiationStart Time

Timestamp —



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


5-33


Fieldnumber Length


36. 1 byte ConfigurationNegotiationFailure Code

Indicates the configurationnegotiation failure code.

001 = Could notproceed

010 = AN-InitiatedNegotiationConnection AttemptFailure

011 = AT-InitiatedNegotiationConnection AttemptFailure

100 = SecurityProtocolNegotiation Failure

101 = Session KeyLength NegotiationFailure

110 = No responsefrom AT duringconfigurationnegotiation

000 = Success

37. 4bytes

ConfigurationNegotiationEnd Time

Timestamp —

38. 1 byte Seizure BandClass

Indicates seizure band class. 0 = Cellular: 850band class

1 = PCS: 1900band class

4 = Korea PCS

5 = 450

6 = China 2100

39. 2bytes

SeizureChannelNumber

Indicates seizure channelnumber.

0-2047 inincrements of 1



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Fieldnumber Length


40. 1 byte Assigned BandClass

Indicates assigned bandclass.

0 = Cellular: 850band class


4 = Korea PCS

5 = 450

6 = China 2100

41. 2bytes

AssignedChannelNumber

Indicates assigned channelnumber.


42. 1 byte Ending BandClass

Indicates ending band class. 0 = Cellular: 850band class


4 = Korea PCS

5 = 450

6 = China 2100

43. 2bytes

EndingChannelNumber

Indicates ending channelnumber.


44. 1 byte ConnectionEstablished

Does not require aconnection request received.If the connection is notestablished, the field is setto null.

y or n*

* Even though theConnection Established field format indicates whether the“connection” was established with a response ofy or n, the contents are:

• NULL = no connection was requested

• 1 = the connection was successfully established

• 0 = the connection was requested and not established



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


5-35

Table 5-14 EV-DO PCMD record data fields - RLP Layer

Fieldnumber Length


45. 4 bytes RLP BytesTransmitted to AT

Indicates RLP bytestransmitted to AT.

—

46. 4 bytes RLP BytesReceived from AT

Indicates RLP bytesreceived from AT.

—

47. 4 bytes RLP BytesRetransmitted(NAKed) to AT

Indicates the RLPbytes retransmitted(NAKed) to AT.

—

48. 4 bytes RLP BytesRe-received fromAT

Indicates RLP bytesre-received fromAT.

—

Table 5-15 EV-DO PCMD record data fields - Key Service Measurements

Fieldnumber Length


49. 1 byte Number of SMCounts (OneField PerCount)

Number of SM Counts (OneField Per Count).

1 field per count

50. 1 byte SM Count 1 SM Count 1 0-44

Values 29 to 34 areavailable in R29.0and later

Values 35 to 44 areavailable inR28.0/SU3 CFTEand later






...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Table 5-15 EV-DO PCMD record data fields - Key Service Measurements(continued)

Fieldnumber Length
















...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


5-37

Table 5-16 EV-DO PCMD record data fields - Personality Type:

Fieldnumber Length


56. 1 byte PersonalityType

Indicates Personality Type ofAT.

0 = Rev 0

1 = Rev A

2 = MFPA

Table 5-17 EV-DO PCMD record data fields - Additional Data

Fieldnumber Length



57. 1 byte RUM recorddata stored

Indicateswhether RUMcollection wasenabled.

0, 1

58. 1 byte Num of RUMdata stored

When RUMcollection isenabled, thisvalue indicateshow manyRUM haveactually beenreceived andstored in thisPCMD record.

0-2

59. 1 byte Num of FlowData Included

Indicates thenumber ofPCMDsubrecordsthat areincluded inthe PCMDprimaryrecord.

0-No Flows

Up to 8 Flows included.

For Release 27.0, the value isalways none.



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Table 5-17 EV-DO PCMD record data fields - Additional Data (continued)

Fieldnumber Length



60. 2bytes

Access RoundTrip Delay

If AccessRound TripDelay Precision= 1, than 1 unit= 1/8 chip. IfAccess RoundTrip DelayPrecision = 32,than 1 unit = 4chips.s

IndicatesRound TripPacketTransmissionDelay

0-255

61. word32 Last AP IPAddress

Indicates LastAP IP Address

—

62. Last AttemptedPaging Area

pagingArea 1-8, where:

1:Last Active Set

2:Color Code of Last Seen RNC

3: Neighbor RN

4: RNC Group

5:Distance Tier 0

6:Distance Tier 1

7:Distance Tier 2

8:Distance Tier 3

63. Paging ProfileID

profileId 0-5 (BEpID, CMCSpID,PTTCSSpID, PTTICSpID,CPTTSB1pID, CPTTSB2pID)

64. Number ofQoS Pages

noOfQosPage 0-7

65. Last-Seen CellUsed forPaging

lastSeenCell 0-999

66. Last-SeenSector Used forPaging

lastSeenSector 0-6



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


5-39


Fieldnumber Length



67. Last-SeenGroup MemberUsed forPaging

lastSeenRNC 0-255

68. 2bytes

Control OHMNumber

This is theOHM numberassociatedwith theControl OHMIPAddress(field 11

0.0.0.0-255.255.255.255

69. 4bytes

Initial AccessOHM AP IPAddress

This is onlypopulatedwhen OHMload-balancingis attempted.

0.0.0.0-255.255.255.255

70. 2bytes Initial AccessOHM Number

This is theOHM numberassociatedwith theInitial AccessOHM AP IPAddress (field69)

0-65535

71. 2bytes

SubscriberHomeJurisdiction ID

0-65535

72. 1 byte SubscriberHomeInter-UserPriority

0-8

73. 2bytes

Assigned CellSite ID ForConnection

1-maximum number of cellssupported

74. 1 byte AssignedSector ID ForConnection

0-6



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Fieldnumber Length



75. 3bytes

SM Count 7 SM Count 7 —

76. 3bytes


77. 3bytes


78. 1 byte Access RoundTrip DelayPrecision

Indicates theprecision of theAccess RoundTrip Delay. If1, AccessRound TripDelay is inunits of 1/8chip. If 32,Access RoundTrip Delay isin units of 4chip.

1, 32

79. 1 byte EVDO PCMDPrimary Spare01

0-255


0-255


0-255


0-255


0-255



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


5-41


Fieldnumber Length




0-255


0-255


0-255

Detailed RUM data

When the Enhancements to EVDO Per Call Service Measurements feature is active,the service provider uses the EMS interface to include or exclude data from the firstRUM and the last RUM that are received during the PCMD Interval in the PCMDrecord. The PCMD record contains a field to indicate whether RUM data is stored inthat record.

If RUM data is included, the RUM data fields that are shown inTable 5-18, “DOPCMD RUM Fields” (p. 5-42)are appended to the end of the PCMD record.

Table 5-18 DO PCMD RUM Fields

Field Number Description of data

1 RUM Storage Timestamp

2 Handoff Activity caused by RUM (select one)

0: No Handoff activity

1: Add a call leg to the active set

2: Drop a call leg to the active set

3: Add/Drop one leg at the same time

4: AT-Assisted IFHO

5: Directed IFHO

3 Number of non-Reference pilots in the RUM (0-5)

4 Cell site # of reference pilot

5 Sector Number



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Table 5-18 DO PCMD RUM Fields (continued)


6 RNC ID

7 SN ID

8 Carrier Channel Number

9 Carrier Band Class

10 Reference Pilot PN Offset

11 Reference Pilot Strength

12 Keep indicator for reference pilot

13 Pre handoff evaluation Active Set flag

0 = not in active set

1 = in active set

14 Post handoff evaluation Active Set flag


1 = in active set

15 Handoff Complete Active Set flag

0 = no TCC

1 = TCC

16 Round Trip Delay

1 unit = 4 chips

17 Cell site # of pilot

18 Sector Number

19 RNC ID

20 SN ID

21 Carrier Channel Number

22 Carrier Band Class

23 Pilot PN Phase

24 Pilot Strength

25 Keep Indicator



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


5-43

Table 5-18 DO PCMD RUM Fields (continued)


26 Pre handoff evaluation Active Set flag:


1 = in active set

Important! This field indicates which pilots from the RUMare currently part of the active set at the moment the RUMmessage was received at the RNC.

27 Post Handoff evaluation Active Set flag:


1 = in active set

Important! This field indicates which pilots from the RUMare added/deleted from the active set due to handoffevaluation at the RNC.

28 Handoff Complete Active Set flag:

0 = no TCC

1 = TCC

Important! This field indicates which pilots from the RUMwere successfully added to the active set after successfulhandoff.

29 Round Trip Delay

If Round Trip Delay Precision = 1, than 1 unit = 1/8 chip. IfRound Trip Delay Precision = 32, than 1 unit = 4 chips.

30 Round Trip Delay Precision

Indicates the precision of the Round Trip Delay. If 1, RoundTrip Delay is in units of 1/8 chip. If 32, Round Trip Delayis in units of 4 chip.

Important! Fields 17 - 29 are repeated for each of the non-Reference pilots in the RUMspecified in Field 3.

The Flow data fields are shown inTable 5-19, “Flow Data Fields” (p. 5-44)areappended to the end of the PCMD record.

Table 5-19 Flow Data Fields


1 Reservation Request Time Received

2 Reservation Label



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Table 5-19 Flow Data Fields (continued)


3 Reservation Type Requested (Profile ID)

4 ReservationOnRequest Channel Type (Access/Traffic)

0 - Access Channel

1 - Traffic Channel

5 Reservation Denied

0 - False

1 - True

6 Reservation Flow Direction (forward/reverse)

01 - Forward

10 - Reverse

11 - Bidirectional

7 Flow Event Start/Open Time

8 Flow Event Duration

9 Flow Final Class

See values inTable 5-20, “Flow Final Classes (FFC) andFFC Qualifiers for Flow Reservation” (p. 5-46)

10 Flow CFC Qualifier

See values inTable 5-20, “Flow Final Classes (FFC) andFFC Qualifiers for Flow Reservation” (p. 5-46)

11 Flow CPFailure Value

12 SpareFlow(01)

13 SpareFlow(02)

14 SpareFlow(03)

15 SpareFlow(04)

Important! Fields 1 - 11 arerepeated.

The data is repeated accordingly with the value of number of Flow Data in Record(field 59) and that the maximum that can be reported in 1 PCMD record is 8.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


5-45

Table 5-20 Flow Final Classes (FFC) and FFC Qualifiers for Flow Reservation

Value Flow Final ClassAdditional Information (FFCQualifier)

Secondary FFCQ(Future Use)

001 Flow Reservationestablished andreleased normally

Null Null

002 Flow ReservationFail

(FRF) - QoS

Requirements NotMet

201 = Flow Admission Failed

202 = QoS Backhaul Exception

Null or Cpfail code

003 FRF - ResourceProblem - TP

301 = Resource Problem - TP Null or Cpfail code

004 FRF - ResourceProblem - Cell

401 = FL RF Overload Control -Cell

402 = RL RF Overload Control -Cell

403 = FL BH Overload Control -Cell

404 = RL BH Overload Control -Cell

405 = FL Packet Drop by DSP -Cell

406 = FL Packet Loss Due to BH- Cell

Null or Cpfail code

005 Service Denial(AuthorizationException)

501 = BTS EQU LicenseAuthorization Exception

502 = PTT License AuthorizationException

503 = Conversational VideoLicense Authorization Exception

504 = VoIP (ConversationalSpeech) License AuthorizationException

Null or Cpfail code

006 General SystemError

Not covered by other FFCs Null



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Per-connection performance data output examples from theOMP-FX v.2...................................................................................................................................................................................................................................

Introduction

This section contains examples of the per-connection performance output data from theOMP-FX v.2.

OMP storage control

The EV-DO PCMD process on the OMP can store eight additional previous hours ofEV-DO PCMD data, in a compressed format. Several minutes after a new log file isstarted, the log file which is over two hours old is compressed. The data is compressedusing GNU Zip (GZIP).

The data for the current and previous hours are stored in uncompressed format.

Raw ASCII data

The following figures show examples of raw ASCII data output with RUM datadisabled(Figure 5-2, “Example raw data output from the OMP-FX v.2 with RUMdisabled” (p. 5-48)), with RUM dataenabled(Figure 5-3, “Example raw data outputfrom the OMP-FX v.2 with RUM enabled” (p. 5-48)) and with Rum and Flowenabled(Figure 5-4, “Example raw data output from the OMP-FX v.2 with RUM and Flowenabled” (p. 5-48)). In these examples, the data is displayed as follows:

• Each data field is separated from the other data fields by a delimiter (″;″ or ″|″).

• The data fields are in the same order as the data fields inTable 5-11, “EV-DOPCMD record data fields - Administrative” (p. 5-28)throughTable 5-17, “EV-DOPCMD record data fields - Additional Data” (p. 5-38).

• Every field is included in this output whether the field has a value or not. If thefield does not have a value, nothing is printed for the field except the semicolondelimiter.

• There can be one through six service measurement counts that are populated in therecord. If only two are populated, the other four have no value. TheNum. of SMCount field (Field 49) specifies how manySM counts (Fields 50 through 55) arein the record.

• A cell number of zero is reported in the EV-DO PCMD when the connection failsearly in the connection, before the system recognizes which cell is involved withsetting up the connection.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


5-47

Verbose data

The following figures show examples of verbose data output with RUM disabled(Figure 4) and with RUMenabled(Figure 5) and Data Flows data fields (Figure 6).Each data field includes a label that describes what the field contains. The data fieldsare in the same order as the data fields inTable 5-11, “EV-DO PCMD record datafields - Administrative” (p. 5-28)throughTable 5-17, “EV-DO PCMD record datafields - Additional Data” (p. 5-38).

Example verbose data output from the OMP-FX v.2 with RUM disabledEVDO PCMD Version: 5Sequence Number: 32528Month and Day: 0123Duplicate Sequence Number: 0Mobile ID Type (ESN/MEID): 0Mobile ID(MSN) (ESN/MEID): 0000000074111310International Mobile Station Identifier: 0999999812145265UATI: 19420251UATI Complete Message Received Time: 20:33:16.2RATI: NoneControl OHM AP IP Address: 172.26.4.7Session Request Type: 2

Figure 5-2 Example raw data output from the OMP-FX v.2 with RUM disabled

5;32528;0123;0;0;0000000074111310;0999999812145265;19420251;73996291;;172.26.4.7;2;0;;73994798;73996293;;;;73996293;;;;;;;7;172.26.4.15;172.47.11.1;599;3;;;;;;;;;;;;;;;;;;1;28;;;;;;0;0;;0;0;172.26.4.7;;;;;;;303;0.0.0.0;;;8;;255;;;;;;;;;;;;;

Figure 5-3 Example raw data output from the OMP-FX v.2 with RUM enabled

5;32411;0123;0;0;000000007411130b;;170205f8;70842458;964967391;172.26.4.133;1;0;;70841791;70845753;70842479;70842658;;;4000;1;1;;0;;7;172.26.4.142;;411;1;411;1;;70841750;0;70844700;0;425;0;425;0;425;1;;;;;5;48;19;20;49;50;;2;1;2;0;1;172.26.4.133;;;;;;;301;0.0.0.0;;;8;411;1;;;;32;;;;;;;;;70841791;0;1;411;1;23;7;425;0;326;14;1;0;0;0;1;32;;;;;425;0;24069;10;1;0;0;0;2;32;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;|70842847;0;1;411;1;23;7;425;0;326;14;1;1;1;0;1;32;;;;;425;0;24069;9;1;0;0;0;2;32;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

Figure 5-4 Example raw data output from the OMP-FX v.2 with RUM and Flowenabled

5;32545;0123;0;0;0000000074111313;0999999210677960;1a420002;;;172.26.4.71;0;;44000;;;74405166;74405357;;;116000;2;106;;0;;7;172.26.4.78;172.47.11.1;503;1;503;1;;;;;0;425;0;384;0;384;1;6189964;3847687;7373;0;3;19;20;21;;;;2;1;2;4;52;172.26.4.71;;;;;;;303;0.0.0.0;;;0;503;1;;;;1;;;;;;;;;74405417;0;4;503;1;26;7;384;0;200;9;1;1;1;0;0;1;503;2;26;7;384;0;13056;11;1;1;1;0;0;1;503;3;26;7;384;0;13312;12;1;1;1;0;0;1;503;2;26;7;425;0;13056;12;1;1;1;0;0;1;503;3;26;7;425;0;13312;13;1;1;1;0;0;1;;;;;;;;;;;;;;|74514463;0;2;503;2;26;7;384;0;204;11;1;1;1;0;50;1;503;1;26;7;384;0;12800;9;1;1;1;0;50;1;503;3;26;7;384;0;13312;12;1;1;1;0;50;1;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;|74407947;3;100;2;0;1;74407971;87166;1;;;;;;|74407955;3;100;2;0;2;74407971;87177;1;;;;;;|74407955;4;300;2;0;1;74407971;87220;1;;;;;;|74407955;4;300;2;0;2;74407971;87220;1;;;;;;|


Per-connection performance data output examples fromthe OMP-FX v.2

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Session Setup Final Class: 0Session or Connection CPFail Value: NoneSession Setup/Transfer Request Time: 20:33:14.7Session Setup/Transfer Complete Time: 20:33:16.2Connection Request Time: NoneConnection Established Time: NoneA12 RAN Authentication Time: NoneA10 Link Established Time: 20:33:16.2Connection Duration: NoneConnection Final Class: NoneCFC Qualifier: NoneSecondary CFC Qualifier: NoneAT- or AN-Initiated Connection Request: NoneSilent Reorigination Flag: NoneService Node ID: 7TP for Connection: 172.26.4.15PDSN IP No.: 172.47.11.1Seizure Cell Number: 599Seizure Sector Number: 3Last DRC-Pointed Cell: NoneLast DRC-Pointed Sector Number: NoneNumber of DO pages: NoneConfiguration Negotiation Start Time: NoneConfiguration Negotiation Failure Code: NoneConfiguration Negotiation End Time: NoneSeizure Band Class: NoneSeizure Channel Number: NoneAssigned Band Class: NoneAssigned Channel Number: NoneEnding Band Class: NoneEnding Channel Number: NoneConnection Established: NoneRLP Bytes Transmitted to AT: NoneRLP Bytes Received from AT: NoneRLP Bytes Retransmitted to AT: NoneRLP Bytes Re-received from AT: NoneNumber of SM Counts: 1SM Count 1: 28SM Count 2: NoneSM Count 3: NoneSM Count 4: NoneSM Count 5: NoneSM Count 6: NonePersonality Type Used: 0Rum Data Stored: 0Number of RUM data stored: NoneNumber of Flow data included: 0Access Round Trip Delay: 0Last Cell-Serving OHM AP IP Address: 172.26.4.7



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


5-49

Last Attempted Paging Area: NonePaging ProfileID: NoneNumber of QoS Pages: NoneLast-Seen Cell Used for Paging: NoneLast-Seen Sector Used for Paging: NoneLast-Seen RNC Group Member Number Used for Paging: NoneControl OHM Number: 303Initial Access OHM AP Address: 0.0.0.0Initial Access OHM Number: NoneSubscriber Home Jurisdiction ID: NoneSubscriber Home Inter-User Priority: 8Assigned Cell Site ID For Connection: NoneAssigned Sector ID For Connection: 255SM Count 7: NoneSM Count 8: NoneSM Count 9: NoneAccess Round Trip Delay Precision: None

Example verbose data output from the OMP-FX v.2 with RUM enabledEVDO PCMD Version: 5Sequence Number: 32411Month and Day: 0123Duplicate Sequence Number: 0Mobile ID Type (ESN/MEID): 0Mobile ID(MSN) (ESN/MEID): 000000007411130bInternational Mobile Station Identifier: NoneUATI: 170205f8UATI Complete Message Received Time: 19:40:42.4RATI: 964967391Control OHM AP IP Address: 172.26.4.133Session Request Type: 1Session Setup Final Class: 0Session or Connection CPFail Value: NoneSession Setup/Transfer Request Time: 19:40:41.7Session Setup/Transfer Complete Time: 19:40:45.7Connection Request Time: 19:40:42.4Connection Established Time: 19:40:42.6A12 RAN Authentication Time: NoneA10 Link Established Time: NoneConnection Duration: 4000Connection Final Class: 1CFC Qualifier: 1Secondary CFC Qualifier: NoneAT- or AN-Initiated Connection Request: 0Silent Reorigination Flag: NoneService Node ID: 7TP for Connection: 172.26.4.142PDSN IP No.: NoneSeizure Cell Number: 411



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Seizure Sector Number: 1Last DRC-Pointed Cell: 411Last DRC-Pointed Sector Number: 1Number of DO pages: NoneConfiguration Negotiation Start Time: 19:40:41.7Configuration Negotiation Failure Code: 0Configuration Negotiation End Time: 19:40:44.7Seizure Band Class: 0Seizure Channel Number: 425Assigned Band Class: 0Assigned Channel Number: 425Ending Band Class: 0Ending Channel Number: 425Connection Established: 1RLP Bytes Transmitted to AT: NoneRLP Bytes Received from AT: NoneRLP Bytes Retransmitted to AT: NoneRLP Bytes Re-received from AT: NoneNumber of SM Counts: 5SM Count 1: 48SM Count 2: 19SM Count 3: 20SM Count 4: 49SM Count 5: 50SM Count 6: NonePersonality Type Used: 2Rum Data Stored: 1Number of RUM data stored: 2Number of Flow data included: 0Access Round Trip Delay: 1Last Cell-Serving OHM AP IP Address: 172.26.4.133Last Attempted Paging Area: NonePaging ProfileID: NoneNumber of QoS Pages: NoneLast-Seen Cell Used for Paging: NoneLast-Seen Sector Used for Paging: NoneLast-Seen RNC Group Member Number Used for Paging: NoneControl OHM Number: 301Initial Access OHM AP Address: 0.0.0.0Initial Access OHM Number: NoneSubscriber Home Jurisdiction ID: NoneSubscriber Home Inter-User Priority: 8Assigned Cell Site ID For Connection: 411Assigned Sector ID For Connection: 1SM Count 7: NoneSM Count 8: NoneSM Count 9: NoneAccess Round Trip Delay Precision: 32RUMData 1: RUM Storage Timestamp: 19:40:41.7



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


5-51

RUMData 1: Handoff Activity caused by RUM: 0RUMData 1: Number of NONREF_PLTS in the RUM: 1RUMData 1: Cell site # of reference pilot: 411RUMData 1: Reference Pilot Sector ID: 1RUMData 1: Reference Pilot RNC ID: 23RUMData 1: Reference Service Node ID: 7RUMData 1: Reference Pilot Carrier Channel Number: 425RUMData 1: Reference Pilot Band Class: 0RUMData 1: Reference Pilot PN Offset Index: 326RUMData 1: Reference Pilot strength: 14RUMData 1: Keep indicator for reference pilot: 1RUMData 1: Reference Pilot Pre Handoff Evaluation Active Set Flag: 0RUMData 1: Reference Pilot Post Handoff Evaluation Active Set Flag: 0RUMData 1: Reference Pilot Handoff complete active set flag : 0RUMData 1: Reference Pilot Round trip delay: 1RUMData 1: Reference Pilot Round trip delay Precision: 32RUMData 1: NonReference pilots 1: Cell site number: NoneRUMData 1: NonReference pilots 1: Sector number: NoneRUMData 1: NonReference pilots 1: RNC Id: NoneRUMData 1: NonReference pilots 1: Service Node ID: NoneRUMData 1: NonReference pilots 1: Carrier Channel Number: 425RUMData 1: NonReference pilots 1: Carrier Band Class: 0RUMData 1: NonReference pilots 1: Pilot PN phase: 24069RUMData 1: NonReference pilots 1: Pilot Strength: 10RUMData 1: NonReference pilots 1: Keep indicator: 1RUMData 1: NonReference pilots 1: Pre Handoff Evalution active set

flag: 0RUMData 1: NonReference pilots 1: Post Handoff Evalution active set

flag: 0RUMData 1: NonReference pilots 1: Handoff complete active set flag: 0RUMData 1: NonReference pilots 1: Round Trip Delay: 2RUMData 1: NonReference pilots 1: Round Trip Delay Precision: 32RUMData 1: NonReference pilots 2: Cell site number: NoneRUMData 1: NonReference pilots 2: Sector number: NoneRUMData 1: NonReference pilots 2: RNC Id: NoneRUMData 1: NonReference pilots 2: Service Node ID: NoneRUMData 1: NonReference pilots 2: Carrier Channel Number: NoneRUMData 1: NonReference pilots 2: Carrier Band Class: NoneRUMData 1: NonReference pilots 2: Pilot PN phase: NoneRUMData 1: NonReference pilots 2: Pilot Strength: NoneRUMData 1: NonReference pilots 2: Keep indicator: NoneRUMData 1: NonReference pilots 2: Pre Handoff Evalution active set

flag: NoneRUMData 1: NonReference pilots 2: Post Handoff Evalution active set

flag: NoneRUMData 1: NonReference pilots 2: Handoff complete active set flag: NoneRUMData 1: NonReference pilots 2: Round Trip Delay: NoneRUMData 1: NonReference pilots 2: Round Trip Delay Precision: NoneRUMData 1: NonReference pilots 3: Cell site number: NoneRUMData 1: NonReference pilots 3: Sector number: None



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

RUMData 1: NonReference pilots 3: RNC Id: NoneRUMData 1: NonReference pilots 3: Service Node ID: NoneRUMData 1: NonReference pilots 3: Carrier Channel Number: NoneRUMData 1: NonReference pilots 3: Carrier Band Class: NoneRUMData 1: NonReference pilots 3: Pilot PN phase: NoneRUMData 1: NonReference pilots 3: Pilot Strength: NoneRUMData 1: NonReference pilots 3: Keep indicator: NoneRUMData 1: NonReference pilots 3: Pre Handoff Evalution active set


flag: NoneRUMData 1: NonReference pilots 3: Handoff complete active set flag: NoneRUMData 1: NonReference pilots 3: Round Trip Delay: NoneRUMData 1: NonReference pilots 3: Round Trip Delay Precision: NoneRUMData 1: NonReference pilots 4: Cell site number: NoneRUMData 1: NonReference pilots 4: Sector number: NoneRUMData 1: NonReference pilots 4: RNC Id: NoneRUMData 1: NonReference pilots 4: Service Node ID: NoneRUMData 1: NonReference pilots 4: Carrier Channel Number: NoneRUMData 1: NonReference pilots 4: Carrier Band Class: NoneRUMData 1: NonReference pilots 4: Pilot PN phase: NoneRUMData 1: NonReference pilots 4: Pilot Strength: NoneRUMData 1: NonReference pilots 4: Keep indicator: NoneRUMData 1: NonReference pilots 4: Pre Handoff Evalution active set




flag: NoneRUMData 1: NonReference pilots 5: Handoff complete active set flag: NoneRUMData 1: NonReference pilots 5: Round Trip Delay: NoneRUMData 1: NonReference pilots 5: Round Trip Delay Precision: NoneRUMData 2: RUM Storage Timestamp: 19:40:42.8RUMData 2: Handoff Activity caused by RUM: 0RUMData 2: Number of NONREF_PLTS in the RUM: 1RUMData 2: Cell site # of reference pilot: 411



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


5-53

RUMData 2: Reference Pilot Sector ID: 1RUMData 2: Reference Pilot RNC ID: 23RUMData 2: Reference Service Node ID: 7RUMData 2: Reference Pilot Carrier Channel Number: 425RUMData 2: Reference Pilot Band Class: 0RUMData 2: Reference Pilot PN Offset Index: 326RUMData 2: Reference Pilot strength: 14RUMData 2: Keep indicator for reference pilot: 1RUMData 2: Reference Pilot Pre Handoff Evaluation Active Set Flag: 1RUMData 2: Reference Pilot Post Handoff Evaluation Active Set Flag: 1RUMData 2: Reference Pilot Handoff complete active set flag : 0RUMData 2: Reference Pilot Round trip delay: 1RUMData 2: Reference Pilot Round trip delay Precision: 32RUMData 2: NonReference pilots 1: Cell site number: NoneRUMData 2: NonReference pilots 1: Sector number: NoneRUMData 2: NonReference pilots 1: RNC Id: NoneRUMData 2: NonReference pilots 1: Service Node ID: NoneRUMData 2: NonReference pilots 1: Carrier Channel Number: 425RUMData 2: NonReference pilots 1: Carrier Band Class: 0RUMData 2: NonReference pilots 1: Pilot PN phase: 24069RUMData 2: NonReference pilots 1: Pilot Strength: 9RUMData 2: NonReference pilots 1: Keep indicator: 1RUMData 2: NonReference pilots 1: Pre Handoff Evalution active set




flag: NoneRUMData 2: NonReference pilots 2: Handoff complete active set flag: NoneRUMData 2: NonReference pilots 2: Round Trip Delay: NoneRUMData 2: NonReference pilots 2: Round Trip Delay Precision: NoneRUMData 2: NonReference pilots 3: Cell site number: NoneRUMData 2: NonReference pilots 3: Sector number: NoneRUMData 2: NonReference pilots 3: RNC Id: NoneRUMData 2: NonReference pilots 3: Service Node ID: NoneRUMData 2: NonReference pilots 3: Carrier Channel Number: None



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

RUMData 2: NonReference pilots 3: Carrier Band Class: NoneRUMData 2: NonReference pilots 3: Pilot PN phase: NoneRUMData 2: NonReference pilots 3: Pilot Strength: NoneRUMData 2: NonReference pilots 3: Keep indicator: NoneRUMData 2: NonReference pilots 3: Pre Handoff Evalution active set






flag: NoneRUMData 2: NonReference pilots 5: Handoff complete active set flag: NoneRUMData 2: NonReference pilots 5: Round Trip Delay: NoneRUMData 2: NonReference pilots 5: Round Trip Delay Precision: None

Example verbose data output of RUM and Flow data fieldsEVDO PCMD Version: 5Sequence Number: 32545Month and Day: 0123Duplicate Sequence Number: 0Mobile ID Type (ESN/MEID): 0



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


5-55

Mobile ID(MSN) (ESN/MEID): 0000000074111313International Mobile Station Identifier: 0999999210677960UATI: 1a420002UATI Complete Message Received Time: NoneRATI: NoneControl OHM AP IP Address: 172.26.4.71Session Request Type: 0Session Setup Final Class: NoneSession or Connection CPFail Value: 44000Session Setup/Transfer Request Time: NoneSession Setup/Transfer Complete Time: NoneConnection Request Time: 20:40:05.1Connection Established Time: 20:40:05.3A12 RAN Authentication Time: NoneA10 Link Established Time: NoneConnection Duration: 116000Connection Final Class: 2CFC Qualifier: 106Secondary CFC Qualifier: NoneAT- or AN-Initiated Connection Request: 0Silent Reorigination Flag: NoneService Node ID: 7TP for Connection: 172.26.4.78PDSN IP No.: 172.47.11.1Seizure Cell Number: 503Seizure Sector Number: 1Last DRC-Pointed Cell: 503Last DRC-Pointed Sector Number: 1Number of DO pages: NoneConfiguration Negotiation Start Time: NoneConfiguration Negotiation Failure Code: NoneConfiguration Negotiation End Time: NoneSeizure Band Class: 0Seizure Channel Number: 425Assigned Band Class: 0Assigned Channel Number: 384Ending Band Class: 0Ending Channel Number: 384Connection Established: 1RLP Bytes Transmitted to AT: 6189964RLP Bytes Received from AT: 3847687RLP Bytes Retransmitted to AT: 7373RLP Bytes Re-received from AT: 0Number of SM Counts: 3SM Count 1: 19SM Count 2: 20SM Count 3: 21SM Count 4: NoneSM Count 5: None



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

SM Count 6: NonePersonality Type Used: 2Rum Data Stored: 1Number of RUM data stored: 2Number of Flow data included: 4Access Round Trip Delay: 52Last Cell-Serving OHM AP IP Address: 172.26.4.71Last Attempted Paging Area: NonePaging ProfileID: NoneNumber of QoS Pages: NoneLast-Seen Cell Used for Paging: NoneLast-Seen Sector Used for Paging: NoneLast-Seen RNC Group Member Number Used for Paging: NoneControl OHM Number: 303Initial Access OHM AP Address: 0.0.0.0Initial Access OHM Number: NoneSubscriber Home Jurisdiction ID: NoneSubscriber Home Inter-User Priority: 0Assigned Cell Site ID For Connection: 503Assigned Sector ID For Connection: 1SM Count 7: NoneSM Count 8: NoneSM Count 9: NoneAccess Round Trip Delay Precision: 1RUMData 1: RUM Storage Timestamp: 20:40:05.4RUMData 1: Handoff Activity caused by RUM: 0RUMData 1: Number of NONREF_PLTS in the RUM: 4RUMData 1: Cell site # of reference pilot: 503RUMData 1: Reference Pilot Sector ID: 1RUMData 1: Reference Pilot RNC ID: 26RUMData 1: Reference Service Node ID: 7RUMData 1: Reference Pilot Carrier Channel Number: 384RUMData 1: Reference Pilot Band Class: 0RUMData 1: Reference Pilot PN Offset Index: 200RUMData 1: Reference Pilot strength: 9RUMData 1: Keep indicator for reference pilot: 1RUMData 1: Reference Pilot Pre Handoff Evaluation Active Set Flag: 1RUMData 1: Reference Pilot Post Handoff Evaluation Active Set Flag: 1RUMData 1: Reference Pilot Handoff complete active set flag : 0RUMData 1: Reference Pilot Round trip delay: 0RUMData 1: Reference Pilot Round trip delay Precision: 1RUMData 1: NonReference pilots 1: Cell site number: 503RUMData 1: NonReference pilots 1: Sector number: 2RUMData 1: NonReference pilots 1: RNC Id: 26RUMData 1: NonReference pilots 1: Service Node ID: 7RUMData 1: NonReference pilots 1: Carrier Channel Number: 384RUMData 1: NonReference pilots 1: Carrier Band Class: 0RUMData 1: NonReference pilots 1: Pilot PN phase: 13056RUMData 1: NonReference pilots 1: Pilot Strength: 11



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


5-57

RUMData 1: NonReference pilots 1: Keep indicator: 1RUMData 1: NonReference pilots 1: Pre Handoff Evalution active set


flag: 1RUMData 1: NonReference pilots 1: Handoff complete active set flag: 0RUMData 1: NonReference pilots 1: Round Trip Delay: 0RUMData 1: NonReference pilots 1: Round Trip Delay Precision: 1RUMData 1: NonReference pilots 2: Cell site number: 503RUMData 1: NonReference pilots 2: Sector number: 3RUMData 1: NonReference pilots 2: RNC Id: 26RUMData 1: NonReference pilots 2: Service Node ID: 7RUMData 1: NonReference pilots 2: Carrier Channel Number: 384RUMData 1: NonReference pilots 2: Carrier Band Class: 0RUMData 1: NonReference pilots 2: Pilot PN phase: 13312RUMData 1: NonReference pilots 2: Pilot Strength: 12RUMData 1: NonReference pilots 2: Keep indicator: 1RUMData 1: NonReference pilots 2: Pre Handoff Evalution active set


flag: 1RUMData 1: NonReference pilots 2: Handoff complete active set flag: 0RUMData 1: NonReference pilots 2: Round Trip Delay: 0RUMData 1: NonReference pilots 2: Round Trip Delay Precision: 1RUMData 1: NonReference pilots 3: Cell site number: 503RUMData 1: NonReference pilots 3: Sector number: 2RUMData 1: NonReference pilots 3: RNC Id: 26RUMData 1: NonReference pilots 3: Service Node ID: 7RUMData 1: NonReference pilots 3: Carrier Channel Number: 425RUMData 1: NonReference pilots 3: Carrier Band Class: 0RUMData 1: NonReference pilots 3: Pilot PN phase: 13056RUMData 1: NonReference pilots 3: Pilot Strength: 12RUMData 1: NonReference pilots 3: Keep indicator: 1RUMData 1: NonReference pilots 3: Pre Handoff Evalution active set


flag: 1RUMData 1: NonReference pilots 3: Handoff complete active set flag: 0RUMData 1: NonReference pilots 3: Round Trip Delay: 0RUMData 1: NonReference pilots 3: Round Trip Delay Precision: 1RUMData 1: NonReference pilots 4: Cell site number: 503RUMData 1: NonReference pilots 4: Sector number: 3RUMData 1: NonReference pilots 4: RNC Id: 26RUMData 1: NonReference pilots 4: Service Node ID: 7RUMData 1: NonReference pilots 4: Carrier Channel Number: 425RUMData 1: NonReference pilots 4: Carrier Band Class: 0RUMData 1: NonReference pilots 4: Pilot PN phase: 13312RUMData 1: NonReference pilots 4: Pilot Strength: 13RUMData 1: NonReference pilots 4: Keep indicator: 1



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

RUMData 1: NonReference pilots 4: Pre Handoff Evalution active setflag: 1

RUMData 1: NonReference pilots 4: Post Handoff Evalution active setflag: 1

RUMData 1: NonReference pilots 4: Handoff complete active set flag: 0RUMData 1: NonReference pilots 4: Round Trip Delay: 0RUMData 1: NonReference pilots 4: Round Trip Delay Precision: 1RUMData 1: NonReference pilots 5: Cell site number: NoneRUMData 1: NonReference pilots 5: Sector number: NoneRUMData 1: NonReference pilots 5: RNC Id: NoneRUMData 1: NonReference pilots 5: Service Node ID: NoneRUMData 1: NonReference pilots 5: Carrier Channel Number: NoneRUMData 1: NonReference pilots 5: Carrier Band Class: NoneRUMData 1: NonReference pilots 5: Pilot PN phase: NoneRUMData 1: NonReference pilots 5: Pilot Strength: NoneRUMData 1: NonReference pilots 5: Keep indicator: NoneRUMData 1: NonReference pilots 5: Pre Handoff Evalution active set


flag: NoneRUMData 1: NonReference pilots 5: Handoff complete active set flag: NoneRUMData 1: NonReference pilots 5: Round Trip Delay: NoneRUMData 1: NonReference pilots 5: Round Trip Delay Precision: NoneRUMData 2: RUM Storage Timestamp: 20:41:54.4RUMData 2: Handoff Activity caused by RUM: 0RUMData 2: Number of NONREF_PLTS in the RUM: 2RUMData 2: Cell site # of reference pilot: 503RUMData 2: Reference Pilot Sector ID: 2RUMData 2: Reference Pilot RNC ID: 26RUMData 2: Reference Service Node ID: 7RUMData 2: Reference Pilot Carrier Channel Number: 384RUMData 2: Reference Pilot Band Class: 0RUMData 2: Reference Pilot PN Offset Index: 204RUMData 2: Reference Pilot strength: 11RUMData 2: Keep indicator for reference pilot: 1RUMData 2: Reference Pilot Pre Handoff Evaluation Active Set Flag: 1RUMData 2: Reference Pilot Post Handoff Evaluation Active Set Flag: 1RUMData 2: Reference Pilot Handoff complete active set flag : 0RUMData 2: Reference Pilot Round trip delay: 50RUMData 2: Reference Pilot Round trip delay Precision: 1RUMData 2: NonReference pilots 1: Cell site number: 503RUMData 2: NonReference pilots 1: Sector number: 1RUMData 2: NonReference pilots 1: RNC Id: 26RUMData 2: NonReference pilots 1: Service Node ID: 7RUMData 2: NonReference pilots 1: Carrier Channel Number: 384RUMData 2: NonReference pilots 1: Carrier Band Class: 0RUMData 2: NonReference pilots 1: Pilot PN phase: 12800RUMData 2: NonReference pilots 1: Pilot Strength: 9RUMData 2: NonReference pilots 1: Keep indicator: 1



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


5-59

RUMData 2: NonReference pilots 1: Pre Handoff Evalution active setflag: 1

RUMData 2: NonReference pilots 1: Post Handoff Evalution active setflag: 1

RUMData 2: NonReference pilots 1: Handoff complete active set flag: 0RUMData 2: NonReference pilots 1: Round Trip Delay: 50RUMData 2: NonReference pilots 1: Round Trip Delay Precision: 1RUMData 2: NonReference pilots 2: Cell site number: 503RUMData 2: NonReference pilots 2: Sector number: 3RUMData 2: NonReference pilots 2: RNC Id: 26RUMData 2: NonReference pilots 2: Service Node ID: 7RUMData 2: NonReference pilots 2: Carrier Channel Number: 384RUMData 2: NonReference pilots 2: Carrier Band Class: 0RUMData 2: NonReference pilots 2: Pilot PN phase: 13312RUMData 2: NonReference pilots 2: Pilot Strength: 12RUMData 2: NonReference pilots 2: Keep indicator: 1RUMData 2: NonReference pilots 2: Pre Handoff Evalution active set





flag: None



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

RUMData 2: NonReference pilots 4: Post Handoff Evalution active setflag: None

RUMData 2: NonReference pilots 4: Handoff complete active set flag: NoneRUMData 2: NonReference pilots 4: Round Trip Delay: NoneRUMData 2: NonReference pilots 4: Round Trip Delay Precision: NoneRUMData 2: NonReference pilots 5: Cell site number: NoneRUMData 2: NonReference pilots 5: Sector number: NoneRUMData 2: NonReference pilots 5: RNC Id: NoneRUMData 2: NonReference pilots 5: Service Node ID: NoneRUMData 2: NonReference pilots 5: Carrier Channel Number: NoneRUMData 2: NonReference pilots 5: Carrier Band Class: NoneRUMData 2: NonReference pilots 5: Pilot PN phase: NoneRUMData 2: NonReference pilots 5: Pilot Strength: NoneRUMData 2: NonReference pilots 5: Keep indicator: NoneRUMData 2: NonReference pilots 5: Pre Handoff Evalution active set


flag: NoneRUMData 2: NonReference pilots 5: Handoff complete active set flag: NoneRUMData 2: NonReference pilots 5: Round Trip Delay: NoneRUMData 2: NonReference pilots 5: Round Trip Delay Precision: NoneFlowData 1: Reservation Request Time Received: 20:40:07.9FlowData 1: Reservation Label: 3FlowData 1: Reservation Type Requested (Profile ID): 100FlowData 1: ReservationOnRequest Channel Type (Access/Traffic): 2FlowData 1: Reservation Denied: 0FlowData 1: Reservation Flow Direction (forward/reverse): 1FlowData 1: Flow Event Start/Open Time: 20:40:07.9FlowData 1: Flow Event Duration: 87166FlowData 1: Flow Final Class: 1FlowData 1: Flow CFC Qualifier: NoneFlowData 1: Flow CPFail Value: NoneFlowData 2: Reservation Request Time Received: 20:40:07.9FlowData 2: Reservation Label: 3FlowData 2: Reservation Type Requested (Profile ID): 100FlowData 2: ReservationOnRequest Channel Type (Access/Traffic): 2FlowData 2: Reservation Denied: 0FlowData 2: Reservation Flow Direction (forward/reverse): 2FlowData 2: Flow Event Start/Open Time: 20:40:07.9FlowData 2: Flow Event Duration: 87177FlowData 2: Flow Final Class: 1FlowData 2: Flow CFC Qualifier: NoneFlowData 2: Flow CPFail Value: NoneFlowData 3: Reservation Request Time Received: 20:40:07.9FlowData 3: Reservation Label: 4FlowData 3: Reservation Type Requested (Profile ID): 300FlowData 3: ReservationOnRequest Channel Type (Access/Traffic): 2FlowData 3: Reservation Denied: 0FlowData 3: Reservation Flow Direction (forward/reverse): 1



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


5-61

FlowData 3: Flow Event Start/Open Time: 20:40:07.9FlowData 3: Flow Event Duration: 87220FlowData 3: Flow Final Class: 1FlowData 3: Flow CFC Qualifier: NoneFlowData 3: Flow CPFail Value: NoneFlowData 4: Reservation Request Time Received: 20:40:07.9FlowData 4: Reservation Label: 4FlowData 4: Reservation Type Requested (Profile ID): 300FlowData 4: ReservationOnRequest Channel Type (Access/Traffic): 2FlowData 4: Reservation Denied: 0FlowData 4: Reservation Flow Direction (forward/reverse): 2FlowData 4: Flow Event Start/Open Time: 20:40:07.9FlowData 4: Flow Event Duration: 87220FlowData 4: Flow Final Class: 1FlowData 4: Flow CFC Qualifier: NoneFlowData 4: Flow CPFail Value: None



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

How data is accessed from the OMP-FX v.2...................................................................................................................................................................................................................................

Introduction

This section presents three methods to access/view per-connection performance datafrom the OMP-FX v.2.

Methods available

Per-connection performance data is accessible in two ways:

• A telnet command to the OMP-FX v.2 port (7050 through 7054)

• An FTP command to retrieve the EV-DO PCMD hourly file

Per-connection performance data can be viewed on the OMP-FX v.2 using the verboseor raw EV-DO PCMD Viewers (evdo_vpcmdvieweror evdo_rpcmdviewer).

Both verbose and raw EV-DO PCMD viewers can be active at the same time becausethe data source for the verbose-mode EV-DO PCMD viewer and the data source forthe raw-mode EV-DO PCMD viewer is the data files.

The EV-DO PCMD uses TCP/IP to transfer data. One TCP port allows any number ofclients. So the number of ports does not limit the number of clients.

Procedures

The following sections provide procedures for each method:

• “Using telnet to retrieve EV-DO PCMD data” (p. 5-64)

• “Using FTP to retrieve EV-DO PCMD data” (p. 5-66)

• “Using the EV-DO PCMD viewer to view EV-DO PCMD data” (p. 5-68)


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


5-63

Using telnet to retrieve EV-DO PCMD data...................................................................................................................................................................................................................................

Purpose

This procedure describes how to use telnet to retrieve per-connection performance data.

Before you begin

Verify that the implementation of the PCMD for 1xEV-DO feature is complete. Forimplementation details, see“Implementing the feature” (p. 5-73).

Steps


...................................................................................................................................................................................................

1 Enter the following command on aUNIX® terminal:telnet [omp machine] [port] [>filename]

Where:

[omp machine] is the system name for the OMP-FX v.2

[port] is either 7050 for human readable format or 7051 through 7054 for delimitedformat.

[>filename] is an optional redirection of output to a file, if desired

Example:telnet ompa 7050

Result: Per-connection performance data immediately starts to stream to theselected port (7050 through 7054). Reference: For output examples, see“Per-connection performance data output examples from the OMP-FX v.2”(p. 5-47).

...................................................................................................................................................................................................

2 Process the data received in the post-processing tool.

Important! The post-processing tool must be set to access the desired OMP-FX v.2port (7050 through 7054) as described in“Configured OMP-FX v.2 ports” (p. 5-13). For guidelines on the post-processing tool, see“Post-processing tool guidelines”(p. 5-15).


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

...................................................................................................................................................................................................

3 To stop the stream of data to the port, close the telnet window.

E N D O F S T E P S...................................................................................................................................................................................................


Using telnet to retrieve EV-DO PCMD data

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


5-65

Using FTP to retrieve EV-DO PCMD data...................................................................................................................................................................................................................................

Purpose

This procedure describes how to use FTP software to retrieve per-connectionperformance data.

Before you begin

Verify that the activation of the PCMD for 1xEV-DO feature is complete. Foractivation details, see“Implementing the feature” (p. 5-73).

Steps


...................................................................................................................................................................................................

1 Enter theftp command on a UNIX terminal:

ftp [hostname]

Where:

[hostname] is the system name for the OMP-FX v.2

Example:

ftp ompa

Result: The system prompts for login information.

...................................................................................................................................................................................................

2 Enter login information.

...................................................................................................................................................................................................

3 Use thecd command to go to the directory location where the stored files are located:

cd /omp-data/logs/evdo_pcmd

...................................................................................................................................................................................................

4 Enter thels command to display a list of directory files.

Important! Older files are in gzip format. These files can be retrieved if they areungzipped.

...................................................................................................................................................................................................

5 Enter aget command to retrieve the files:get YYMMDDHH.EVDOPCMD

where:

YY = year


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

MM = month

DD = day

HH = hour at the end of the data collection period (in 24-hour format, for example, 15is 3:00 PM)

The files are ASCII text with fields that are separated by a delimiter (″;″ or ″|″),which is also called the″raw″ format. For a description of the raw format, see“Per-connection performance data output examples from the OMP-FX v.2” (p. 5-47).

Result: Per-connection performance data is transferred to the specified output file.

...................................................................................................................................................................................................

6 Process the data received in the post-processing tool.

Important! For guidelines on how to set up the post-processing tool, see“Post-processing tool guidelines” (p. 5-15).

E N D O F S T E P S...................................................................................................................................................................................................


Using FTP to retrieve EV-DO PCMD data

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


5-67

Using the EV-DO PCMD viewer to view EV-DO PCMD data...................................................................................................................................................................................................................................

Purpose

This procedure describes how to use the EV-DO PCMD viewer to view per-connectionperformance data.

References

For details on OMP-FX v.2 procedures, see,OMP-FX v.2 Operation, Administration, &Maintenance Guide,401-662-102

For details on the OMP-FX v.2pevdo_pcmdaemon command format and syntax, see“EV-DO PCMD viewer command format and syntax” (p. 5-70).

Before you begin

Verify that the implementation of the PCMD for 1xEV-DO feature is complete. Forimplementation details, see“Implementing the feature” (p. 5-73).

Steps


...................................................................................................................................................................................................

1 Log into the OMP-FX v.2.

...................................................................................................................................................................................................

2 Go to the/omp/bindirectory.

...................................................................................................................................................................................................

3 Enter theevdo_pcmdaemon command to generate the desired data format. For example:

evdo_vpcmdviewer (in verbose mode) orevdo_rpcmdviewer (in raw mode)

For command format details, see“EV-DO PCMD viewer command format and syntax”(p. 5-70).


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Result: The EV-DO PCMD viewer immediately starts to display the data that isbeing sent from the DO-RNC to the OMP-FX v.2.

Reference: For output examples, see“Per-connection performance data outputexamples from the OMP-FX v.2” (p. 5-47).

...................................................................................................................................................................................................

4 To stop the EV-DO PCMD viewer, use the interrupt character that is set for yourterminal (typically,CTRL+c).

E N D O F S T E P S...................................................................................................................................................................................................


Using the EV-DO PCMD viewer to view EV-DO PCMDdata

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


5-69

EV-DO PCMD viewer command format and syntax...................................................................................................................................................................................................................................

Introduction

This section describes the format and syntax of theevdo_pcmdaemon UNIX command.

Description

The evdo_pcmdaemon command provides three modes:

• Start mode for the verbose format

• Start mode for the raw format

• Help mode

Availability

The evdo_pcmdaemon command is in the/omp/bindirectory.

Syntax

The syntax for theevdo_pcmdaemon command is as follows:

evdo_vpcmdviewer

evdo_rpcmdviewer

evdo_vpcmdviewer -h

evdo_rpcmdviewer -h

Syntax conventions

Options begin with a hyphen (-).

Command rules

More than one mode (option) is valid in a command line.

Option descriptions

The options for theevdo_pcmdaemon command are described inTable 5-21,“evdo_pcmdaemon command options” (p. 5-70).

Table 5-21 evdo_pcmdaemon command options

Option Description

-n Start theevdo_vpcmdviewer and view data in human readableformat (verbose). For example,-n number,0< = number, maximum =maximum number that fits into signed integer (2, 147, 483, 647)

Start theevdo_rpcmdviewer and view data in delimited format (raw)


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Table 5-21 evdo_pcmdaemon command options (continued)

Option Description

-h Help mode. Provide information for the command options.

Command cancellation

The EV-DO PCMD viewer runs continuously until the tool is stopped. To stop theEV-DO PCMD viewer, use the interrupt character that is set for your terminal(typically, CTRL+c).

Important! Note that about a minute passes before the EV-DO PCMD viewerstops.

Examples

Start the EV-DO PCMD viewer to display verbose format data:

evdo_vpcmdviewer

Start the EV-DO PCMD viewer to display raw format data:

evdo_rpcmdviewer


EV-DO PCMD viewer command format and syntax

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


5-71


Introduction

The PCMD for 1xEV-DO feature does not interact with other features.

The Enhancements to EVDO Per Call Service Measurements feature interacts with thefollowing feature:

• Inter and Intra-RNC Handoff Enhancement (FID 12078.7)

Inter and Intra-RNC Handoff Enhancement

The Inter and Intra-RNC Handoff Enhancement feature adds the following new casesto the set of PCMD events:

• Personality change attempts within an RNC (intra-RNC)

• Personality change attempts during an active connection, which is from current(Rev. A) to non-current (Rev. 0)

• When AT comes out of idle, including both Rev. A to Rev. 0 and Rev. 0 to Rev. A(at connection setup)

These PCMD records indicate all personality change attempts due to changes incoverage on the BTS where signal strength requires a personality change. In the caseof a new connection, this personality is stored as usual. In cases where an activeconnection is present, and a new personality is requested, this request results in a newconnection attempt, and therefore, a new PCMD record. The Inter and Intra-RNCHandoff Enhancement feature populates the CFCQ and Secondary CFCQ with theresult of the personality change attempt, and the new personality selected, respectively.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Overview

To implement the PCMD for 1xEV-DO feature, perform the following procedure:

“Activating the PCMD for 1xEV-DO feature” (p. 5-74)


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


5-73

Activating the PCMD for 1xEV-DO feature...................................................................................................................................................................................................................................

Purpose

This procedure activates the PCMD for 1xEV-DO feature in aCDMA2000® 1xEV-DOnetwork.

The following parameters set by the EMS CM management interface control how thePCMD for 1xEV-DO behaves.

• PCMD (PCMDevdoEnable) - Determines whether EV-DO PCMD features should beactivated.

• PCMD Normal (PCMDevdoNormConn) - Determines whether EV-DO PCMD data thatis associated with normal connections should be omitted from output. However,when this parameter is enabled the EV-DO PCMD data is included.

• PCMD Normal Sessions (PCMDevdoNormSess) - Determines whether EV-DOPCMD data that is associated with sessions should be omitted from output.However, when this parameter is enabled the EV-DO PCMD data is included.

• PCMD Master Key (PCMDevdoMasterKey) - Determines whether EV-DO PCMDhas been allowed on this service node via a FAF entry. This is a display string. Thegranularity of this key is for the entire Service Node.

• PCMD RUM Collections (PCMDevdoRUM) - Determines whether data from the firstand last RUM messages that occur during a PCMD Interval is included in thePCMD record.

Procedure


...................................................................................................................................................................................................


EVDO PCMD

...................................................................................................................................................................................................

2 From the EMS FMS Frame view, activate the PCMD control through thePCMDparameter.

Important! The user is required to enablePCMD (PCMDevdoEnable) before settingany of the other parameters.

...................................................................................................................................................................................................

3 Click Submit.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

...................................................................................................................................................................................................

4 Activate any other control form the EMS FMS Frame view (such as,PCMD Normal Connections, PCMD Normal Sessions, PCMD RUM Collections).

Important! These parameters may be enabled separately or together.

...................................................................................................................................................................................................

5 Click Submit.

E N D O F S T E P S...................................................................................................................................................................................................


Activating the PCMD for 1xEV-DO feature

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


5-75

6 6High Rate Packet Data RadioNetwork Controller (HRPDRNC) Performance and CapacityImprovements

Overview...................................................................................................................................................................................................................................

Purpose

This optional feature description describes the High Rate Packet Data Radio NetworkController (HRPD RNC.) Performance and Capacity Improvements optional feature inCDMA2000® 1xEV-DO networks.

Feature summary

The HRPD RNC Performance and Capacity Improvements feature improves theperformance and capacity of the FMS-based CDMA 3G-1x Evolution Data Optimized(1xEV-DO) RNC by:

• supporting up to 260 carriers

• supporting up to 40,000 (active plus dormant) sessions per Application Processor(AP) and 20,000 dormant sessions per Force690/Artesyn752i Traffic Processor (TP)board

• supporting up to 1000 active users per Force690/Artesyn752i TP board.


A unique feature identifier (FID) number is assigned to each feature. This chaptersupports HRPD RNC Performance and Capacity Improvements (FID 10607.3).


The HRPD RNC Performance and Capacity Improvements affects the user interfacesthat are listed in the following table.


Element Management System (EMS) See“Implementing the feature” (p. 6-9)

....................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


6-1


Operations and Maintenance Center -Radio Access Network (OMC-RAN)

For information on configuring withOMC-RAN, see“Implementing thefeature” (p. 6-9)


Automatic Message Accounting (AMA)subsystem

None

Technician Interface (TI) (input/outputmessages)

None



Contents

Availability 6-3

Prerequisites 6-4






Activating the Carrier Capacity Enhancement 6-11

Deactivating the feature 6-13

High Rate Packet Data Radio Network Controller (HRPDRNC) Performance and Capacity Improvements

Overview

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Availability...................................................................................................................................................................................................................................


The HRPD RNC Performance and Capacity Improvements feature is available in DORNC Release 26.0 and later.

Market availability

The HRPD RNC Performance and Capacity Improvements feature is available in allmarkets.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


6-3

Prerequisites...................................................................................................................................................................................................................................

Introduction

The HRPD RNC Performance and Capacity Improvements feature has the followingprerequisites.


The HRPD RNC Performance and Capacity Improvements feature is supported in thefollowing air-interface technologies:

• 1xEV-DO


The HRPD RNC Performance and Capacity Improvements feature requires

• OMP-FX Release R26.0 or later

• RNC Release: R26.0 or later

• Cell Release (1xEV-DO): R24.0 or later

The HRPD RNC Performance and Capacity Improvements feature is not dependent onany R26.0 or earlier features, but does have interactions with several features. See“Feature interactions” (p. 6-7)for further details.


The HRPD RNC Performance and Capacity Improvements feature requires nohardware beyond the standard hardware in aCDMA2000® 1xEV-DO network.


The processing of A11 messages moves to the Traffic Processor (TP) from theApplication Processor (AP). Standard A11 mechanisms (MD5 authentication andtimestamp replay protection) continue to provide security.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Introduction

The following information describes the functionality, benefits, and operation of theHRPD RNC Performance and Capacity Improvements feature.

Functionality

The HRPD RNC Performance and Capacity Improvements feature providesenhancements to the R25.0 FMS RNC Carrier Count and Session Capacity Increasefeature (FID 10607.2), which had increased the maximum number of configuredcarriers and cells to 130 in order to increase the number of cell coverage per RNCframe, but not the overall RNC performance.

The HRPD RNC Performance and Capacity Improvements feature expands support to260 Rev 0 Carriers providing improved Forward Link Throughput for the RNC. Theseimprovements are applicable for the FMS platform (1xEV-DO RNC) and are achievedthrough software optimization.

The A11 Packet Control Function (PCF) function is moved to the TP to improveoverall system capacity by eliminating the TP-to-A11-PCF interface, removing the A11proxy function, and creating additional capacity for AP processing. Additional upgradesindicate that the number of active and dormant connections per RNC frame has beenincreased, this improvement proportionately supports the required 260 carriers.

Benefits

The HRPD RNC Performance and Capacity Improvements feature (10607.3) is aperformance improvement feature offering the following improvements over the R25.0FID 10607.2:

Per R25.0 R26.0

AP 26,000 total sessions 40,000 total sessions

TP 13,000 dormant sessions 20,000 dormant sessions

TP 520 active users 1000 active users

RNC 130 carriers 260 carriers

Additionally, file transfer protocol (ftp) transfers have improved throughput on forwardand reverse links and there is significant speed up of the evcup command.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


6-5


The HRPD RNC Performance and Capacity Improvements feature impacts

• A11 message processing at the AP,

• TP processing and the IP Stack, and

• Operations, Administration and Maintenance (OA&M) (System Initialization TimeReduction, Service Measurements).

Database view collation changes have been implemented in an effort to minimize the1xEV-DO controller software initialization times. The changes will decrease theinitialization time for evcup after AP failover, application process failover, andindividual AP and application process initialization durations.

AP process optimization

The basic changes required to support 260 carriers involve increasing the number ofcalls supported per AP from 26,000 to up to 40,000. This is accomplished byincreasing the number of Overhead Manager Access Terminal (OHMAT) objects andby modifying the way Unicast Access Terminal Identifiers (UATIs) are allocated by theAP.

A11 processing moved from AP to TP

In the R25.0 FMS RNC, the A11 functionality was built into the A11 messageprocessing at the AP, whereas the actual A11 termination as seen by the Packet DataServing Node (PDSN) was at the TP. By migrating the A11 functionality into the TP inR26.0, internal message flow is reduced from 5 messages to 2. A distributed A11message processing at the AP architecture also improves reliability and scalability.

TP process optimization

The TP performance was improved by reducing memory copies in the bearer stack andby optimizing the usage of timers.

OAM link configuration

The OAM links on the first 4 APs are configured on the AP side for 10 Mbps halfduplex rather than auto negotiate. RNC retrofit procedures preserve this setting. Thesame switch may be used for the GigE and OA&M links, however in this case theOAM links will be assigned to a separate (port-based) VLAN.


The HRPD RNC Performance and Capacity Improvements feature requires serviceproviders to perform the following task after the FAF is activated:

• Activate the Carrier Capacity Enhancement parameter on the EMS (or OMC-RAN).


Feature description

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Introduction

The HRPD RNC Performance and Capacity Improvements feature interacts with thefollowing features:

• Support for Multiple 1xEV-DO Carriers – IFHO - FID 8219.11

• Support for Multiple 1xEV-DO Carriers – Enhancements - FID 8219.2.

• Increasing 1xEV-DO Limits on the OMP-FX Netra 440 - FID 12518.0

Support for Multiple 1xEV-DO Carriers – Enhancements feature

The HRPD RNC Performance and Capacity Improvements feature allows single-sectorcarrier cells to support a total of 260 cells per RNC. If the cells are 3 carrier cells(introduced by the Support for Multiple 1xEV-DO Carriers – Enhancements feature), amaximum of 87 cells are supported per RNC frame.

Increasing 1xEV-DO Limits on the OMP-FX Netra 440

While the OMP-FX Release R26.0 supports the HRPD RNC Performance and CapacityImprovements feature, the OMP-FX Netra 440 (OMP-FX v.2) provides additionalgrowth opportunities in conjunction with the Increasing 1xEV-DO Limits on theOMP-FX Netra 440 feature, allowing the EMS/OMP-FX v.2 to support maximumnumber of cells and 600 carriers per Service Node.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


6-7


Introduction

The HRPD RNC Performance and Capacity Improvements feature is subject to thefollowing special issues and/or caveats.

Issues

There are no issues associated with this feature.

Caveats

The R26.0 base release includes the software optimization and architecturalimprovements without FAF control. The FAF for FID 10607.3 controls the portions ofthe feature that provide

• the number of carriers that may be supported and

• the maximum number of total and dormant sessions allowed.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Overview

To implement the HRPD RNC Performance and Capacity Improvements feature,perform the following procedures:


“Activating the Carrier Capacity Enhancement” (p. 6-11)

“Deactivating the feature” (p. 6-13)









...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


6-9


Purpose

This procedure activates the HRPD RNC Performance and Capacity Improvementsfeature in aCDMA2000® 1xEV-DO network.

Procedure


...................................................................................................................................................................................................


1xEV-DO HRPD RNC Performance and Capacity Improvements to support 260Rev 0 carriers

...................................................................................................................................................................................................

2 Proceed to“Activating the Carrier Capacity Enhancement” (p. 6-11).

E N D O F S T E P S...................................................................................................................................................................................................


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Activating the Carrier Capacity Enhancement...................................................................................................................................................................................................................................

Purpose

This procedure activates the Carrier Capacity Enhancement component of the HRPDRNC Performance and Capacity Improvements feature in aCDMA2000® 1xEV-DOnetwork.

For detailed procedures, see CDMA2000® 1xEV-DO Radio Access System Planningand Implementation Guide,401-614-101 or 401-710-110,Element Management System(EMS) User’s Guide.

Prerequisites

• The1xEV-DO HRPD RNC Performance and Capacity Improvements to support260 Rev 0 carriers FAF must be activated.

Procedure


...................................................................................................................................................................................................



...................................................................................................................................................................................................

2 Click on theConfiguration Data icon.


...................................................................................................................................................................................................

3 In the list of blue navigation buttons on the left side of this EMS page, click on thelink titled Service Nodes. (You may need to scroll down to see that link.)


...................................................................................................................................................................................................

4 Click on the link titledGeneral - section 3 .

Result: The General - section 3 page appears.

...................................................................................................................................................................................................

5 Set theCarrier Capacity Enhancement parameter toOn

...................................................................................................................................................................................................

6 Click the Submit button at the bottom of the page. (Scroll down to see this button.)


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


6-11

Result: You have activated the Carrier Capacity Enhancement parameter.

E N D O F S T E P S...................................................................................................................................................................................................


Activating the Carrier Capacity Enhancement

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Deactivating the feature...................................................................................................................................................................................................................................

Purpose

This procedure deactivates the HRPD RNC Performance and Capacity Improvementsfeature.

Important! In order to deactivate the HRPD RNC Performance and CapacityImprovements feature, the Carrier Capacity Enhancement component must first beturned off, followed by turning off the entry in the FAF.

For detailed procedures, see CDMA2000® 1xEV-DO Radio Access System Planningand Implementation Guide,401-614-101 or 401-710-110,Element Management System(EMS) User’s Guide.

Prerequisites

• Both the1xEV-DO HRPD RNC Performance and Capacity Improvements to support260 Rev 0 carriers FAF entry and theCarrier Capacity Enhancementparameter are activated.

• Only 130 or fewer carriers may be provisioned on the system in order to turn thisfeature off. If more than 130 carriers are provisioned, theCarrier CapacityEnhancement parametercannotbe deactivated. If more than 130 carriers areprovisioned, deprovision the necessary number of carriersbeforebeginning thisprocedure.

Procedure


...................................................................................................................................................................................................



...................................................................................................................................................................................................

2 Click on theConfiguration Data icon.


...................................................................................................................................................................................................

3 In the list of blue navigation buttons on the left side of this EMS page, click on thelink titled Service Nodes. (You may need to scroll down to see that link.)


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


6-13


...................................................................................................................................................................................................

4 Click on the link titledGeneral - section 3 .

Result: The General - section 3 page appears.

...................................................................................................................................................................................................

5 Set theCarrier Capacity Enhancement parameter toOff.

Important! If more than 130 carriers are provisioned, theCarrier CapacityEnhancement parametercannotbe turned off.

...................................................................................................................................................................................................

6 Click the Submit button at the bottom of the page. (Scroll down to see this button.)

Result: You have deactivated theCarrier Capacity Enhancement parameter.

...................................................................................................................................................................................................

7 Ask your account executive to deactivate the following entry in your FeatureActivation File(FAF):1xEV-DO HRPD RNC Performance and Capacity Improvements to support260 Rev 0 carriers

E N D O F S T E P S...................................................................................................................................................................................................


Deactivating the feature

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

7 7EVolution Data Optimized(1xEV-DO) Basic Revision A(Rev. A) Feature Bundle

Overview...................................................................................................................................................................................................................................

Purpose

This optional feature description describes the following EVolution Data Optimized(1xEV-DO) Basic Revision A (Rev. A) Feature Bundle inCDMA® 1xEV-DO networks.A unique Feature Identifier (FID) is assigned to each feature:

Basic Rev. A Feature Bundle:

• Enhanced Reverse and Forward Links using Enhanced MAC Protocols with Rev. ASubtype 2 Physical Layer (FID 12078.2)

• Generic Attribute Update Protocol (GAUP) for Dynamic Parameters Update (FID12078.3)

• High Rate Packet Data (HRPD) Rev. A Support on Modular Cell 1-3 BTSPlatforms using SB-EVMm (FID 12078.4)

• High Rate Packet Data (HRPD) Rev. A Support on Modular Cell 4.0 BTSPlatforms using SB-EVM (FID 12078.5)

• Inter and Intra-Radio Network Controller (RNC) Handoff Enhancement (FID12078.7)

Feature summary

FIDs 12078.2, 12078.3, 12078.4, 12078.5 and 12078.7 make up the software collectionreferred to as Rev. A Basic Feature Bundle and are activated via a software licensingkey mechanism instead of the usual Feature Activation File/Qualified FeatureActivation File (FAF/QFAF) mechanism.

The Basic Rev. A Feature Bundle license key must be purchased in order to enableMandatory Rev. A functionality. The license key is used for the activation of the Rev.A Basic Feature Bundle for one or more Rev. A-capable Base Transceiver Station(BTS)-Carriers served by the RNC.

....................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


7-1

Mandatory Rev A license key is managed by the RNC and is enabled per carrier. Forexample:

• Base station 1 has one Rev A carrier, therefore, 1 Rev A license is required.

• Base station 2 has two Rev A carriers, therefore, 2 Rev A licenses are required.

• Base station 3 has three Rev A carriers, therefore, 3 Rev A licenses are required.

The service provider needs to install the license key via Element Management System(EMS) and assign license keys to the base station carriers to enable the base stationcarrier(s).

When the Basic Rev. A Features are activated within the Radio Access System they arereferred to as HRPD Rev. A system.

The HRPD Rev. A system supports Release 27.0 and later FIDs and any new Rev. Afeatures.

Enhanced Reverse and Forward Links using Enhanced MAC Protocols with Rev.A Subtype 2 Physical Layer (FID 12078.2)

This feature is part of the Rev. A Basic package of features, also referred to as BasicRev. A Feature Bundle. This feature introduces the support of the full Rev. A PhysicalLayer with the complete set of Rev. A enhanced Medium Access Control (MAC)protocols. The following MAC protocols are supported:

• Enhanced Control Channel (CC) MAC

• Enhanced Forward Traffic Channel (FTC) MAC

• Enhanced Access Channel (AC) MAC

• Enhanced Subtype 3 Reverse Traffic Channel (RTC) MAC

This feature is supported on all Modular Cell BTS types using the new HRPD Rev. Amodem board, the SB-EVM for Modular Cell 4.0 and variants or the SB-EVMm forModular Cell 1-3. This feature is supported only by the Rev. A capable RNC.

Generic Attribute Update Protocol (GAUP) for Dynamic Parameters Update (FID12078.3)

This feature is part of the Rev. A Basic package of features. This feature allowsconfiguration attribute changes without costly session configuration protocol exchangeand without releasing the connection. It allows the AT and the AN to use the GAUP toupdate values of the session parameter attributes belonging to different lower andhigher layer protocols and applications.

EVolution Data Optimized (1xEV-DO) Basic Revision A(Rev. A) Feature Bundle

Overview

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

HRPD Rev. A Support on Modular Cell 1-3 BTS Platforms using SB-EVMm (FID12078.4)

This feature is part of the Rev. A Basic package of features and provides the necessaryhardware and software for the Modular Cell 1-3 products to make use of any otherRev. A feature. This feature includes Software, OA&M and Service Measurementssupport related to HRPD Rev. A for the Modular Cell 3.0, Modular Cell 2.0 andModular Cell 1.0.

The term Modular Cell 1-3 is used in this chapter to include the variants listed above.

HRPD Rev. A Support on Modular Cell 4.0 BTS Platforms using SB-EVM (FID12078.5)

This feature is part of the Rev. A Basic package of features and provides the necessaryhardware and software for the Modular Cell 4.0 products to make use of any otherRev. A feature. This feature supports HRPD Rev. A technology on all Modular Cell 4.0Platforms. This feature includes Software, OA&M and Service Measurements supportrelated to HRPD Rev. A for the Modular Cell 4.0 platforms.

The following Modular Cell 4.0 products will be supported:

• Modular Cell 4.0

• Modular Cell 4.0 B

• Compact 4.0

• Compact 4.0 B

• HD 4.0

• HD 4.0 B

The term Modular Cell 4.0 is used in this chapter to include the variants listed above.

Inter and Intra-RNC Handoff Enhancement (FID 12078.7)

This feature is part of the Rev. A Basic package of features. This feature supports, inboth Rel 0 systems and in mixed Rel 0/Rev. A systems:

• every type of handoff that is currently supported in a Rel 0 system (soft/softer ontraffic channel; hard handoff across carriers on traffic channel; inter-RNC dormantsession handoff)

• handoffs from Rev. A PHYsical/Medium Access Control (PHY/MAC) connectionsto Rel 0 PHY/MAC connections.

This feature does not include active handoff from Rel 0 to Rev. A systems.


Overview

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


7-3


The features that are described in this chapter impact the following user interfaces:


Rev. A BasicFeatureBundle: FIDs12078.2,12078.3,12078.4,12078.5,12078.7

Element Management System(EMS) or Operations andMaintenance Center - RadioAccess Network (OMC-RAN)

None

Service measurements For information on configuringparameters related to this feature,see“Impacts on servicemeasurements” (p. 7-15).

Automatic Message Accounting(AMA) subsystem

None


None



Contents

Availability 7-5

Prerequisites 7-6

Feature description: Basic Rev. A Feature Bundle 7-7






Overview

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Availability...................................................................................................................................................................................................................................


The 1xEV-DO Basic Rev. A Feature Bundle are available in 1xEV-DO Releases 28.0and later.

Market availability

The 1xEV-DO Basic Rev. A Feature Bundle are available in all regions.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


7-5

Prerequisites...................................................................................................................................................................................................................................

Introduction

The 1xEV-DO Basic Rev. A Feature Bundle have the following prerequisites.


The 1xEV-DO Basic Rev. A Feature Bundle are supported in the following air-interfacetechnology:

• 1xEV-DO


The 1xEV-DO Basic Rev. A Feature Bundle require Release 27.0 or later.


The 1xEV-DO Basic Rev. A Feature Bundle requires the standard in aCDMA®

1xEV-DO network hardware.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Feature description: Basic Rev. A Feature Bundle...................................................................................................................................................................................................................................

Introduction

The following information defines the functionality, benefits, and operation of BasicRev. A Feature Bundle.

Functionality

High Rate Packet Data (HRPD) Rev. A is a collection of software features (FIDs12078.2, 12078.3, 12078.4, 12078.5 and 12078.7) in a Feature Bundle or package, toprovide the main Rev. A functionality. The Package is referred to as Basic Rev. AFeature Bundle. This bundle of features is mandatory to support 1xEV-DO Rev. A andis activated via a software licensing key mechanism instead of the usual FAF/QFAF.

Benefits

Several enhancements have been introduced in Rev. A which allow customers toprovide higher data rates especially in the reverse link moreover to support a variety ofapplications:

• Improved Reverse Link

– Up to 1.8 Mbps data rate

– Improved Reverse Link Improved MAC, throughput and latency gains withH-ARQ

• Improved Forward Link

– Up to 3.1Mbps data rate

– Improved MAC & MUP Support


Basic Rev. A Operation requires an SB-EVM or SB-EVMm hardware per BaseTransceiver Station (BTS)-carrier supporting Rev. A operation, and must have thesoftware enabled for Rev. A operation by a license key per BTS-carrier. Enabling theBTS-carrier allows operators to use SB-EVM and SB-EVMm for Rel 0 carrierswithout purchasing the Basic Rev. A Feature Bundle. The license key in an RNC willlimit the number of Rev. A enabled BTS-carriers. This license, known as the Rev. Alicense, will be installed by a manual license key procedure on each RNC intended tohost a Rev. A enabled BTSs. The RNC will perform Rev. A functions for anyBTS-carrier that is Rev. A enabled. The EMS will be blocked, by the RNC, fromenabling any BTS-carrier for Rev. A operation if the license key is not present, or ifthere are already as many BTS-carriers enabled on the RNC as the license-key limitallows.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


7-7

The Rev. A software license key is used to:

• enable one or more BTS-Carriers to support features included in the″Basic Rev. AFeature Bundle″ served by the RNC, and

• allow RNC application to set up Rev. A connections from a″Basic Rev. A FeatureBundle″- enabled.

The Rev. A Release RNC base software supports parts of the Basic Rev. A operationwhich do not depend on the enhanced physical layer (without control of the licensekey). That includes multiple personalities negotiation and changing the personality inthe AT by GAUP, and communicating those personalities on A13. All Rev-A operationswhich require the enhanced physical layer will be under control of the Rev. A licensekey.

The following scenario explains at high level the activation process of the Basic Rev.A Feature Bundle using the license key:

• Customer requests quote for Basic Rev A Feature Bundle.

• In order to create a quote, the CT must acquire the following attribute data:

– Lead AP Server Pair Host ID (alpha-numeric)

– Service Node ID (alpha-numeric)

– RNC Frame ID (alpha-numeric)

– Number of additional Rev A carriers

– Existing number of Rev A carriers available on DO-RNC

– Ship-to E-mail address OR to LED indicator

• CT creates quote and a STARS Number is created.

• Basic Rev A quote is delivered to the Customer with appropriate OI’s andnecessary attribute data to generate the license key.

• Customer PO sent to service provider.

• Order is checked to ensure that an appropriate number of Rev A RTU fees for thebase stations have been previously purchased by the customer:

– If sufficient base station Rev A RTUs, the total for the customer’s network isdecremented.

– If there is insufficient base station Rev A RTUs to fill the order, CT iscontacted to resolve situation.

• AP Host ID, RNC Frame ID and Service Node ID are checked to ensureconsistency with order history. If not, CT is contacted to resolve situation.

• To generate the license key, add the incremental license key purchased to therunning total and generate a key with the new total. If issues arise, CT is contactedto resolve them, for example:

• License key(s) generated within 3-4 business days.

• License key(s) shipped to E-mail address/contact on order or posted to LED.


Feature description: Basic Rev. A Feature Bundle

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

• Customer receives license key(s).

• Customer gets invoiced for Basic Rev A Package.

• Customer installs license key(s) per procedures found in document1xEV-DO RASPlanning and Implementation Guide,401-614-101.


The service provider is charged as Right To Use (RTU) fee for each license key. Thisis ananlogous to the Rel 0 license key implemented for some other FIDs. Serviceproviders are charged the Rev. A license fee on top of current Rel 0 license fees.

The serve provider is able to view from the EMS:

• At RNC level the number of BTS-Carrier allowed by the software license key and

• At RNC level the number of BTS-carrier activated for Rev. A service Package

• At BTS level the BTS-Carrier that has been activated for the Basic Rev. A FeatureBundle

Enhanced Reverse and Forward Links using Enhanced MAC Protocols with Rev. A Subtype 2Physical Layer (FID 12078.2)

This feature provides the following improvement:

New Rev. A Physical Layer packet types and sizes to improve packing efficiency andconsequently increase the air interface capacity. Packet sizes are from 128 bits to 5120bits in the FL and from 128 bits to 12288 bits in RL:

• Smaller payloads introduced to improve packing efficiency.

• Larger payloads introduced and this also useful by multiplexing several higherlayer packets (to one or different users) into one physical layer packet.

New data rates have been introduced in both FL and RL:

• In the FL the data rates are from 4.8 kbps (Rel 0 minimum data rate is 38.4 kbps)to 3.072 Mbps (Rel 0 highest data rate is 2457.6 kbps) and in the RL data rates arefrom 4.8 kbps (Rel 0 minimum data rate is 9.6 kbps) and up to 1843.2 kbps (Rel 0highest data rate is 153.6 kbps).

RL incremental redundancy and early termination: Each packet consists of up to four4-slot sub-packets: Transmission of the packet may use 1, 2, 3 or 4 sub-packets witheach one spanning over 4 slots and this reduces the delay and increase throughput.

Support physical-layer hybrid ARQ:

• AT transmits each RL sub-packet incrementally. If the AT receives a NAK, itsubsequently transmits the next subpacket. It terminates the transmission if itreceives an ACK, hence this yields to a higher throughput.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


7-9

Enhanced RTC MAC which supports:

• Different types of applications on top of Rev. A Physical Layer.

• Traffic-to-Pilot (T2P) Resource allocation allows a user in a good RF condition totransmit at a higher rate while Rel 0 MAC does not provide such distinction. Also,it allows more T2P values even for the same encoder packet size such that adifferent PER can be achieved easily.

• Traffic-to-Pilot Token Bucket Operation allows users with bursty traffic to transmitat high data rate when needed.

• Low Latency and High Capacity Modes.

Enhanced FTC MAC allows MAC Layer Packing and Multi-Users Packet (MUP):

• A single physical-layer packet contains one or more upper-layer packets addressedto one or different users.

• MUP is beneficial to certain applications such as Voice Over IP (VoIP) in bothincreasing the capacity and reducing the delay.

Enhanced CC MAC:

• New rate at 19.2 kbps in addition to the existing rates of 38.4 kbps and 76.8 kbps.

• New packet sizes of 128, 256, 512 or 1024 bits (in Rel 0 only 1024 bits issupported).

• A single-user page of 4-slot transmission versus default control channel of 16-slots.This allows for quick paging of the mobile.

Enhanced AC MAC:

• New data rates at 9.6 kbps, 19.2 kbps and 38.4 kbps (in Rel 0 only 9.6 kbps issupported). The new higher data rates reduce the channel setup delay.

• New packet sizes of 256, 512 or 1024 bits (in Rel 0 only 256 bits is supported).

• New ARQ Forward Link Channel which provides a convenient framework tosupport the RTC MAC protocol in reducing the delay.

• New Data Source Control Channel for seamless cell selection to improve Handoff.

GAUP Update (FID 12078.3)

GAUP is used to update certain attributes for different Protocols and Applications, suchas the Enhanced RTC MAC Layer protocols (subtypes 1, 2 and 3), the Multi-FlowPacket Application, 3G-1X Circuit Services Notification Application, theSessionConfigurationToken attribute in the Default Session Configuration Protocol, etc.

GAUP improves the operation of delay sensitive applications, such Video Streamingand Gaming. Lower latency and reduced call drop rates requirements can be achievedby dynamically updating multiple flow per user attributes (for instance, GAUP isuseful in Inter and Intra RNC handoff, as well as in QoS-based scheduling). GAUPsupports only Rev. A RNC.



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

GAUP does not support Rel 0 RNC. GAUP is transparent to BTS, and will supporteither on Rel 0 or Rev. A BTSs.

Service Providers need this functionality for example, in handoff operation of Rev. Amobiles from Rel 0 into Rev. A infrastructure and vice-versa. In such cases, GAUPprovides a mechanism for seamless Inter-Personality handoff, when a personality(configuration) boundary is reached.

Performance improvements brought by GAUP implementation in Rev. A are classifiedas improved user experience since faster adjustments between active applications arepossible. In VoIP, GAUP is key to reduce the call drop rate since it allows switching aSession Configuration (personality) when PHY/MAC boundaries are reached, forexample for Inter-RNC handoff (Rel 0 RNC to Rev. A RNC, or vice-versa).

Implementing GAUP allows support of Subtype 1 RTC MAC protocol which is simplythe Default Rel 0 RTC MAC, but with Rate Transition Vectors that are GAUP-abledynamically and within a session without dropping the connection. The rate transitionvectors in the Rate Transition Matrix (RTM) are used to determine the AT reverse ratebased on the Reverse Activity Bit (RAB) broadcast by the system.

HRPD Rev. A Support on Modular Cell 1-3 BTS Platforms using SB-EVMm (FID 12078.4)

All Modular Cell 1-3 BTSs currently offer packet data services over HRPD based onRel 0. With this feature HRPD Rev. A air-interface will be supported on these productswith software generic upgrades including but not limited to:

• Use the HRPD Rev. A modem cards (SB-EVMm) introduced in Feature 12078.27with the new application and OA&M software to support the new Rev. A airinterface.

• Use of the new application software introduced in 12078.2 and 12078.7 to supportRev. A

• Support of faster Received Signal Strength Indication (RSSI) measurements asspecified in FID 12204.0. With the introduction of higher data rate in the RL forRev. A air-interface, there is a need to provide better, more accurate and fastersystem measurements. RSSI indicates the reverse link total received power at thebase station and is directly related to RL loading. So for better and more accurateestimate of the RL loading a faster RSSI is needed. It should be mentioned that the″Classic″ CBR does not have the resources to implement the new Fast RSSIalgorithm, therefore only SBCBR will be supported for Rev. A in Modular Cell 1-3.

Modular Cell 1-3 will have Feature parity (including OA&M and SM features) withexisting Rel. 0 Modular Cell 1-3 features. In a Modular Cell 1-3: there is oneSB-EVMm per CDMA Digital Module (CDM) which can support three sector-carriers.The Modular Cell 1-3 BTS products will support up to 3 carriers (a carrier refers to1C-3S), one per CDM (Modular Cell 1-3 can be equipped with up to 3 CDMs).



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


7-11

The Modular Cell 1-3 BTS products will support multi-carriers (up to three carriers)with HRPD Rev. A, HRPD Rel 0 and 3G-1X carriers can co-exist in the same BTS butusing:

• Different modem cards:

– Existing EVM for Rel. 0.

– SB-EVMm for Rev. A etc.

• Separate controllers

– One URCm per three sector-carriers.

• Separate radios

– One radio per sector-carrier.

All frequency bands for Modular Cell 1-3 supported in features 8219.x will besupported for Rev. A:

• 850 MHz

• 1900 MHz

• 450 MHz (only for Modular Cell 2-3)

HRPD Rev. A Support on Modular Cell 4.0 BTS Platforms using SB-EVM (FID 12078.5)

All Modular Cell 4.0 products currently offer packet data services over HRPD basedon Rel 0. With this feature HRPD Rev. A air-interface will be supported on theseproducts with software generic upgrades including but not limited to:

• Use the HRPD Rev. A modem cards (SB-EVM) introduced in Feature 12078.17with the new application and OA&M software to support the new Rev. A airinterface

• Use the new application software introduced in FID 12078.2 and 12078.7 tosupport Rev. A

• Support of faster RSSI measurements as specified in FID 12204.0. With theintroduction of higher data rate in the RL for Rev. A air-interface, there is a need toprovide better, more accurate and faster system measurements. RSSI indicates thereverse link total received power at the base station and is directly related to RLloading. So for better and more accurate estimate of the RL loading a faster RSSIis needed. All Modular Cell 4.0 radios are able to support the fast RSSImeasurement, that includes UCR and MCR.

Modular Cell 4.0 will have Feature parity (including OA&M and SM features) withexisting Rel. 0 Modular Cell 4.0 features.

Modular Cell 4.0 HRPD Rev. A will support up to three SB-EVM cards with eachSB-EVM serves three sector-carriers.



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

The Modular Cell 4.0 BTS products will support the multi-carriers feature (FID8219.x, FID 9043.0 and FID 8973.1) with HRPD Rev. A, HRPD Rel 0 and 3G-1Xcarriers can co-exist in the same BTS using:

• Different modem cards:

• Existing EVM for Rel. 0

• SB-EVM for Rev. A etc.

• Can share same radio (if FID 8219.x & FID 9043.0 are supported)

• Use different controllers

All frequency bands for Modular Cell 4.0 supported in features 8219.x will besupported for Rev. A:

• 850 MHz

• 1900 MHz

• 1800 MHz (Korea PCS: Modular Cell 4.0 and Compact 4.0)

• 450 MHz (Compact 4.0)

• 2100 MHz (Compact 4.0 B)


This feature supports both Rel 0 systems and in mixed Rel 0/Rev. A systems:

• Every type of handoff that is currently supported in a Rel 0 system (soft/softer ontraffic channel; hard handoff across carriers on traffic channel; inter-RNC dormantsession handoff)

• Handoffs from Rev-A PHY/MAC connections to Rel 0 PHY/MAC connections.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


7-13


General feature dependencies of 1xEV-DO Rev. A Features

All the 1xEV-DO Rev. A features that impact the base station, result in newrequirements for the following features:

• HDR Reverse Link Overload Control Feature (FID 8048.0)

• Cell Processor Overload Control Feature (FID 10519.0)

All the Rev. A features that impact the RNC, result in new requirements for thefollowing features:

• TP Overload Control and AP Overload Control Features (FID 10519.1)

Enhanced Reverse and Forward Links using Enhanced MAC Protocols with Rev. A Subtype 2Physical Layer (FID 12078.2)

FID 12078.2 has no interactions with other features.

GAUP Update (FID 12078.3)

The GAUP implementation on the AN has no dependency on other FIDs; however,GAUP operation requires GAUP implementation on the AT.

HRPD Rev. A Support on Modular Cell 1-3 BTS Platforms using SB-EVMm (FID 12078.4

FID 12078.4 interacts with the following features:

• Rev. A modem card SB-EVMm (FID 12078.17 and FID 10861.0)

• SBCBR with the Fast RSSI measurement capability (FID 12204.0)

• Modular Cell 1-3 radio controller, URCm (FIDs 8212.x)

HRPD Rev. A Support on Modular Cell 4.0 BTS Platforms using SB-EVM (FID 12078.5)

FID 12078.5 interacts with the following features:

• Rev. A modem card SB-EVM (FID 12078.17 and FID 10861.0)

• Modular Cell 4.0 radio cards (UCR or MCR) with the Fast RSSI measurementcapability (FID 12204.0 )

• Modular Cell 4.0 radio controller, URC and URC-II

• Depends on the support of multi-carriers feature specified in FID 8219.1 for thesupport of multi-carriers in the controllers and radios


This feature is dependent on all features in the Rev. A Basic package. In addition, thisfeature depends on 8219.1 feature which supports handoffs across multiple carriers in aBTS.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Introduction

The 1xEV-DO Rev. A features affect the following categories of servicesmeasurements:

Protocols with Rev. A Physical Layer (12078.2)

The following service measurements are supported:

• DRC Rate Request (per rate)/DRC measure count

• Physical Layer ACK/NAK (Early termination Gain per DRC rate)

• Slot usage for Sub-Synchronous, Synchronous and Asynchronous Control Channel

The Protocols with Rev. A Physical Layer feature affects the Executive CellularProcessor (ECP) service measurements that are identified inTable 7-1, “Protocols withRev. A Physical Layer Feature: New and Modified Service Measurements” (p. 7-15)

Table 7-1 Protocols with Rev. A Physical Layer Feature: New and ModifiedService Measurements

Servicemeasurementsubcategory


SECT-CARR-HCS

EVM_DRC_ERASURE DRC rate requestserased

SECT-CARR-HCS

EVM_DRC_RATE_0 DRC Rate Requests for0kbps

SECT-CARR-HCS

EVM_DRC_RATE_1228_8 DRC Rate Request for1228.8 kbps

SECT-CARR-HCS

EVM_DRC_RATE_1228_8_L DRC Rate Request for1228.8 kbps LongFormat

SECT-CARR-HCS


SECT-CARR-HCS

EVM_DRC_RATE_153_6 DRC rate request for153.6 kbps

SECT-CARR-HCS


SECT-CARR-HCS


SECT-CARR-HCS



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


7-15

Table 7-1 Protocols with Rev. A Physical Layer Feature: New and ModifiedService Measurements (continued)



SECT-CARR-HCS


SECT-CARR-HCS

EVM_DRC_RATE_307_2_L DRC Rate Request for307.2 kbps Long Format

SECT-CARR-HCS

EVM_DRC_RATE_38_4 DRC Rate Requests for38.4kbps

SECT-CARR-HCS


SECT-CARR-HCS

EVM_DRC_RATE_614_4_L DRC Rate Request for614.4 kbps Long Format

SECT-CARR-HCS


SECT-CARR-HCS


SECT-CARR-HCS

EVM_FTC_NUM_SLOT_1228_8 Number of Slots Used toTransmit Physical LayerData at 1228.8 kbps onForward Traffic Channel

SECT-CARR-HCS

EVM_FTC_NUM_SLOT_1536 Number of Slots Used toTransmit Physical LayerData at 1536 kbps onForward Traffic Channel

SECT-CARR-HCS


SECT-CARR-HCS


SECT-CARR-HCS



Impacts on service measurements

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008




SECT-CARR-HCS


SECT-CARR-HCS

EVM_FTC_NUM_SLOT_3072 Number of Slots Used toTransmit Physical LayerData at 3072 kbps onForward Traffic Channel

SECT-CARR-HCS


SECT-CARR-HCS


SECT-CARR-HCS


SECT-CARR-HCS


SECT-CARR-HCS


SECT-CARR-HCS


SECT-CARR-HCS




...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


7-17




SECT-CARR-HCS

EVM_FTC_TOT_BYTES_1228_8 Total Physical LayerBytes Transmitted onForward TrafficChannels at 1228.8 kbps

SECT-CARR-HCS

EVM_FTC_TOT_BYTES_1536 Total Physical LayerBytes Transmitted onForward TrafficChannels at 1536 kbps

SECT-CARR-HCS


SECT-CARR-HCS


SECT-CARR-HCS


SECT-CARR-HCS


SECT-CARR-HCS

EVM_FTC_TOT_BYTES_3072 Total Physical LayerBytes Transmitted onForward TrafficChannels at 3072 kbps

SECT-CARR-HCS


SECT-CARR-HCS




...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008




SECT-CARR-HCS


SECT-CARR-HCS


SECT-CARR-HCS


SECT-CARR-HCS


SECT-CARR-HCS


SECT-CARR-HCS

EVM_CALL_MUTE_STATE_NUM Number of Times inCall Mute State

SECT-CARR-HCS

EVM_CALL_MUTE_STATE_PEAK_DUR

Peak Duration in CallMute State

SECT-CARR-HCS

EVM_CALL_MUTE_STATE_TOT_DUR

Total Duration in CallMute State

SECT-CARR-HCS

EVM_CONN_BLOCK_STATE_NUM Number of Times inConnection Block State

SECT-CARR-HCS

EVM_CONN_BLOCK_STATE_PEAK_DUR

Peak Duration inConnection Block State

SECT-CARR-HCS

EVM_CONN_BLOCK_STATE_TOT_DUR

Total Duration inConnection Block State

SECT-CARR-HCS

EVM_FWD_PACKETS_1228_8_L_TOTAL_COUNT

Tot pkts trans fwrd trafchan 1228.8 kbps-longformt



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


7-19




SECT-CARR-HCS

EVM_FWD_PACKETS_1228_8_TOTAL_COUNT

Tot pkts trans fwrd trafchan 1228.8 kbps

SECT-CARR-HCS



SECT-CARR-HCS



SECT-CARR-HCS



SECT-CARR-HCS



SECT-CARR-HCS



SECT-CARR-HCS



SECT-CARR-HCS



SECT-CARR-HCS



SECT-CARR-HCS



SECT-CARR-HCS



SECT-CARR-HCS

SM_LT_NOISE_FLOOR_EST Long Term Noise FloorEstimation

SECT-CARR-HCS

SM_SILENCE_INT_NOISE_FLOOR_EST

Silence Interval NoiseFloor Estimation

SECT-CARR-HDRC

AN_INIT_CONN_ATMPT_FAIL_OTHER_PRETCA

AN-Initiated ConnectionAttempt Failures - OtherReasons Pre TCA

(Modified)



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008




SECT-CARR-HDRC

AT_INIT_CONN_ATMPT_FAIL_OTHER_PRETCA

AT-Initiated ConnectionAttempt Failures - OtherReasons Pre TCA

(Modified)

SECT-CARR-HDRC

AVG_ACTIVE_CONN_PER_SECTOR_Rev. A

Average Active Rev AConnections persector-carrier

SECT-CARR-HDRC

NUM_CONN_BLOCKED Number of ConnectionsBlocked

SECT-CARR-HDRC

NUM_SUBPKTS_RL_1024 Number of subpacketsreceived on reversetraffic channels forphysical packet size of1024 bits

SECT-CARR-HDRC


SECT-CARR-HDRC


SECT-CARR-HDRC


SECT-CARR-HDRC




...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


7-21




SECT-CARR-HDRC


SECT-CARR-HDRC


SECT-CARR-HDRC


SECT-CARR-HDRC


SECT-CARR-HDRC

NUM_SUBPKTS_RL_6144 Number of subpacketsreceived on reversetraffic channel forphysical packet size of6144 bits

SECT-CARR-HDRC


SECT-CARR-HDRC




...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008




SECT-CARR-HDRC

PEAK_ACTIVE_CONN_PER_SECTOR_Rev. A

Peak Active Rev AConnections per sector

SECT-CARR-HDRC

REVERSE_FRAME_ERROR_COUNT 1xEV Frames in Erroron RTC

(Modified)

SECT-CARR-HDRC

REV_LINK_FRAME_ERROR_COUNT_153_6_KBPS

Reverse link frame errorcount-153.6

(Modified)

SECT-CARR-HDRC



(Modified)

SECT-CARR-HDRC



(Modified)

SECT-CARR-HDRC



(Modified)

SECT-CARR-HDRC



(Modified)

SECT-CARR-HDRC

REV_OL_PC_TOTAL_SETPOINT_1024 Total setpoint forreverse outer loop powercontrol for 1024 bitpackets

SECT-CARR-HDRC

REV_OL_PC_TOTAL_SETPOINT_12288

Total setpoint forreverse outer loop powercontrol for 12288 bitpackets

SECT-CARR-HDRC




...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


7-23




SECT-CARR-HDRC


SECT-CARR-HDRC


SECT-CARR-HDRC


SECT-CARR-HDRC


SECT-CARR-HDRC


SECT-CARR-HDRC


SECT-CARR-HDRC


SECT-CARR-HDRC


SECT-CARR-HDRC




...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008




SECT-CARR-HDRC

REV_OUTER_LOOP_PC_FRAME_COUNT_0KBPS

1xEV Reverse OuterLoop Pwr Cntrl Frm Cnt- 0 kbps

(Modified)

SECT-CARR-HDRC


1xEV Reverse OuterLoop Pwr Cntrl Frm Cnt- 153.6 kbps

(Modified)

SECT-CARR-HDRC



(Modified)

SECT-CARR-HDRC



(Modified)

SECT-CARR-HDRC



(Modified)

SECT-CARR-HDRC



(Modified)

SECT-CARR-HDRC

REV_OUTER_LOOP_PC_TOTAL_OUTPUT_0KBPS

1xEV Reverse OuterLoop Pwr Cntrl Tot Out- 0 kbps

(Modified)

SECT-CARR-HDRC


1xEV Reverse OuterLoop Pwr Cntrl Tot Out- 153.6 kbps

(Modified)



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


7-25




SECT-CARR-HDRC



(Modified)

SECT-CARR-HDRC



(Modified)

SECT-CARR-HDRC



(Modified)

SECT-CARR-HDRC



(Modified)

SECT-CARR-HDRC

REV_PACKETS_1024_TOTAL_COUNT Total physical packetsreceived on reversetraffic channels forpacket size of 1024 bits

SECT-CARR-HDRC

REV_PACKETS_12288_TOTAL_COUNT

Total physical packetsReceived on reversetraffic channels forpacket size of 12288bits

SECT-CARR-HDRC


SECT-CARR-HDRC




...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008




SECT-CARR-HDRC


SECT-CARR-HDRC


SECT-CARR-HDRC


SECT-CARR-HDRC


SECT-CARR-HDRC


SECT-CARR-HDRC


SECT-CARR-HDRC


SECT-CARR-HDRC


SECT-CARR-HDRC

TOTAL_REVERSE_FRAME_COUNT 1xEV Total ReverseLink Frames



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


7-27

Inter and Intra-Radio Network Controller (RNC) Handoff Enhancement (FID12078.7)

These new service measurements are related to Personality Switches introduced in RevA by FID 12078.7.

The Inter and Intra-Radio Network Controller (RNC) Handoff Enhancement featureaffects the Executive Cellular Processor (ECP) service measurements that are identifiedin Table 7-2, “Inter and Intra-Radio Network Controller (RNC) Handoff EnhancementFeature: New Service Measurements” (p. 7-28)

Table 7-2 Inter and Intra-Radio Network Controller (RNC) HandoffEnhancement Feature: New Service Measurements



AP NUM_AT_REL0_SESS_ESTABLISHED

Number of ATs with Rel 0as the highest personalitynegotiated

AP NUM_AT_Rev.A_SESS_ESTABLISHED

Number of ATs with RevA/DPA as the highestpersonality negotiated

SECT-CARR-HDRC AHO_PERS_SWTCH_Rev.A_TO_REL0

Number of PersonalitySwitches During ActiveConnections from RevA/DPA to Rel 0

SECT-CARR-HDRC CONN_SETUP_PERS_SWTCH_REL0_TO_Rev. A

Number of PersonalitySwitches DuringConnection Setup From Rel0 to Rev A/DPA

SECT-CARR-HDRC CONN_SETUP_PERS_SWTCH_Rev. A_TO_REL0

Number of PersonalitySwitches DuringConnection Setup FromRev A/DPA to Rel 0

SECT-CARR-HDRC CONN_SETUP_PERS_SWTCH_UNKNOWN_TO_REL0

Number of PersonalitySwitches DuringConnection Setup FromUnknown to Rel 0

SECT-CARR-HDRC CONN_SETUP_PERS_SWTCH_UNKNOWN_TO_Rev. A

Number of PersonalitySwitches DuringConnection Setup FromUnknown to Rev A/DPA



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Reference

For detailed information about 1xEV-DO service measurements, see 401-614-326,Flexent® Wireless Networks 1xEV-DO Service Measurements



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


7-29


Process

The 1xEV-DO Basic Rev. A Feature Bundle are activated via a software licensing keymechanism instead of the usual FAF/QFAF mechanism.

The license key is used for the activation of the 1xEV-DO Basic Rev. A FeatureBundle for one or more Rev. A-capable BTS-Carrier served by the RNC. The Rev. Asoftware licensing key is installed via the EMS.

The Rev. A software license key is used to:

• enable one or more BTS-Carriers to support features included in the″Basic Rev. AFeature Bundle″ served by the RNC, and

• allow RNC application to set up Rev. A connections from a″Basic Rev. A FeatureBundle” enabled. The Rev. A Release RNC base software will support parts of theMandatory Rev. A operation which do not depend on the enhanced physical layer(without control of the license key). That includes multiple personalities negotiationand changing the personality in the AT by GAUP, and communicating thosepersonalities on A13. All Rev-A operations which require the enhanced physicallayer under control of the Rev. A license key.

The Enhanced Rev. A Feature bundle is an optional bundle controlled by FAF on a perservice node basis. The activation of the enhanced Rev. A Feature bundle depends onthe Basic Rev. A Feature bundle, this means the Basic Rev. A Feature bundle needs tobe activated before the activation of the Enhanced Rev. A Feature bundle. In otherwords, the Enhanced Rev. A Feature Bundle depends on the Rev. A Basic FeatureBundle.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Purpose

This procedure activates the 1xEV-DO Basic Rev. A Feature Bundle in aFlexent®

wireless network.

The following scenario explains at high level the activation process of the 1xEV-DOBasic Rev. A Feature Bundle Bundle using the license key.

For more detailed procedure, see 401-614-101, Flexent® Wireless NetworksCDMA2000® 1xEV-DO Radio Access System.

Procedure

...................................................................................................................................................................................................

1 Service provider logs into the lead AP and obtains the host ID of the first AP.

...................................................................................................................................................................................................

2 Service provider calls Technical Support who provides AP Host ID and the desirednumber of licenses, and asks for Rev. A software license key to be generated.

...................................................................................................................................................................................................

3 Technical Support generates a Rev. A software license key and sends the softwarelicense key to the service provider.

...................................................................................................................................................................................................

4 Service provider installs the Rev. A Software Licensing Key. Service provider entersthe software license key information on the EMS.

...................................................................................................................................................................................................

5 EMS sends the license key information to the RNC. The RNC validates the licensekey.

...................................................................................................................................................................................................

6 Service provider inputs the BTS-Carrier to be activated from the EMS. The EMS sendsthe information to the RNC. The RNC checks whether or not there are unused licenses.If so, assigns one license to the BTS-carrier Rev. A capable (SB-EVM/SB-EVMm), theBTS updates the configuration for that BTS-carrier.

If the BTS-carrier is Rev. A capable (SB-EVM/SB-EVMm), the BTS updates theconfiguration for that BTS-carrier.

E N D O F S T E P S...................................................................................................................................................................................................


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


7-31

8 8Enhanced Data Only Revision A(DOrA) Application Quality ofService (QoS) Features

Overview...................................................................................................................................................................................................................................

Purpose

This optional feature description describes the following Enhanced Data Only RevisionA (DOrA) Application Quality of Service (QoS) Features in theCDMA2000®

EVolution Data Optimized (1xEV-DO) Network. This group of features are identifiedas the″DOrA Application QoS Features″ and use DOrA Application Licenses toenable/disable.

The DOrA Application QoS Features consist of:


• Radio Access Network (RAN) Quality of Service Enhancements for High RatePacket Data (HRPD) Rev. A (FID 12078.10)

• More Quality of Service (QoS) Enhancements for the High Rate Packet Data(HRPD) Revision A (Rev. A) Network (FID 12078.11)

• Data Over Signaling Protocol (FID 12078.12)

• Enhanced Idle State Protocol (FID 12078.13)

• 1xEV-DO Revision A (Rev. A): Data Over Signaling Protocol - FL (FID 12078.36)

• 1xEV-DO Basic Push-To-Talk (PTT) Using 1xEV-DO Rev. A Network (FID12184.1)

• High Rate Packet Data (HRPD) Push-to-Talk (PTT) Paging Enhancements (FID12184.5)

• Push-to-Talk (PTT) Enhancements (FID 12184.7)

Feature summary

In addition to the 1xEV-DO Basic Rev. A Feature Bundle there are sets of optionalRev. A, VoIP and PTT related features called the DOrA Application QoS Features. TheDOrA Application QoS Features are made up of: FIDs 12078.9, 12078.10,12078.11,12078.12, 12078.13,12078.36, 12184.1, 12184.5 and 12184.7, where the

....................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


8-1

12078.x FIDs provide the QoS infrastructure and the QoS for Voice Over IP (VoIP)and video, and the 12184.x FIDs provide QoS for Push-To-Talk (PTT) capabilities. TheDOrA Application QoS Features are an optional bundle controlled by an ApplicationDOrA License as described in1xEV-DO RAS Planning and Implementation Guide,401-614-101.

The activation of the DOrA Application QoS Features depends on the 1xEV-DO BasicRev. A Feature Bundle, this means the 1xEV-DO Basic Rev. A Feature Bundle needs tobe activated before the activation of the DOrA Application QoS Features. In otherwords, the DOrA Application QoS Features depend on the 1xEV-DO Basic Rev. AFeature Bundle.

All the DOrA Application QoS Features are enabled by the DOrA ApplicationLicenses. The FAF entries for all of these features are now enabled in all customersFeature Activation Files (FAF). FAFs are not used to manage ANY of these features.The only FAF legacy situation exists is that the 12078.x series of FIDs has a singleFAF entry, while the 12184.x FIDs have separate entries. However, it is not themechanism to turn on these features - the DOrA Application Licenses are themechanism.

Application Based Quality of Service (QoS) Support for HRPD Rev. A (FID12078.9)

This feature is not part of the Rev. A Basic package of features. It supports QoS perapplication flow based on request from the user, user QoS profile and allocatableresource at the system. This feature only includes the Radio Access Network (RAN)network elements. This feature is supported on both existing FMS and next generationRadio Network Controller (RNC) platforms. Also this feature is supported on any basestation that supports the basic package for Rev. A. This feature will be configured onboth OMC-RAN and Operations and Maintenance Platform (OMP-FX) platforms.

Radio Access Network (RAN) Quality of Service Enhancements for High RatePacket Data (HRPD) Rev. A (FID 12078.10)

This feature includes enhancements to the Application Based Quality of Service (QoS)Support for HRPD Rev. A (FID 12078.9). The enhancements are:

• Enhanced Service Measurements

• Support of Signaling Bus-1xEV-DO Modem (SB-EVM) Processor OverloadControl

• Support of the RNC being able to modify the granted QoS

• Overload Control enhancements which includes LIU Processor and RF Overloadsituations

Enhanced Data Only Revision A (DOrA) ApplicationQuality of Service (QoS) Features

Overview

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

More Quality of Service (QoS) Enhancements for the High Rate Packet Data(HRPD) Revision A (Rev. A) Network (FID 12078.11)

This feature supports the following functionality to enhance Quality of Service (QoS)operation for EV-DO Rev. A network, such as:

• Enhanced carrier selection in mixed network (Rev. 0 /Rev. A).

• FL Scheduler work to support additional states and allow to use RNC timestamp.

• Infrastructure for improving TP clock accuracy and Switching Module (SM) countsto support Backhaul and RNC processing Delays.

• Enhanced Radio Network Controller (RNC) Overload Control and Session StatusCommand support for Rev. A and MFPA.

• Enhanced SMs and Per Call Measurement Data (PCMD) support .

• Synchronizing RTCMAC attributes between AN and AT after they change in thedatabase.

Data Over Signaling Protocol (FID 12078.12)

This feature supports the Data over Signaling (DoS) Protocol (FID 12078.12). It allowssmall amounts of data to be sent over the signaling channel when there is no trafficchannel connection. Applications that require quick message timing (such as, push totalk), burst transport (such as, short message service) benefit from DoS.

This feature covers DoS for the reverse link. DoS over the forward link is covered inFID 12076.36.

Important! Only MO-DOS is supported in R28.0.

Enhanced Idle State Protocol (FID 12078.13)

This feature supports the Enhanced Idle State protocol. The Enhanced Idle State offersthe following benefits over the Default Idle State defined in Rel 0, such as

• shorter slot cycles for reducing paging delay

• dynamic slot cycles defined for different ATs

• longer slot cycles for improving battery life

• “enhanced hashing” defined for improving paging delivery

This feature is applicable for all the BTS types that HRPD currently supports, withclassic EVMs/EVMms or SB-EVMs/SB-EVMms.

1xEV-DO Revision A (Rev. A): Data Over Signaling Protocol - FL (FID 12078.36)

This feature enables the support of transmission of small amounts of end user dataover the control channel (forward link) using the Data over Signaling (DoS) protocoldefined in the HRPD Rev. A standard. This feature is a complementary feature to FID12078.12 which enables the support of transmission of small amounts of end user dataover the access channel (reverse link) using the DoS protocol.


Overview

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


8-3

1xEV-DO Basic Push-To-Talk (PTT) Using 1xEV-DO Rev. A Network (FID 12184.1)

The 1xEV-DO Basic PTT Using 1xEV-DO Rev. A Network feature provides the basicPTT functionality in the HRPD RAN using HRPD Rev. A. HRPD Rev. A is required tohelp meet the tight delay requirements. The feature provides support for PTT specificFlowProfileID s as defined in TIA TSB-58-G, specifically PTTSignalingFlowProfileID 1283 and PTTMedia FlowProfileID s 261 through 280.

The 1xEV-DO Basic PTT Using 1xEV-DO Rev. A Network feature also includespaging enhancements that can be used to provide flexibility to trade-off pagingefficiency and paging latency. For PTT, locating the users on the first paging attempt iscrucial for minimizing the initial setup delay. The Basic PTT using 1xEV-DO Rev. ANetwork feature introduces″QoS Paging″ where differentQoS FlowProfileID s canhave individual paging strategies. Each paging strategy can use two paging area types:

• Last Active Set

• Last Seen RNC (Color Code)

HRPD PTT Paging Enhancements (12184.5)

The High Rate Packet Data (HRPD) Push-to-Talk (PTT) Paging Enhancements featureextends the QoS Paging capabilities provided by the Basic PTT feature above.

The HRPD PTT Paging Enhancements introduces support of two paging area typeswhen performing QoS Paging:

• Neighbor RNC

• RNC Group

The High Rate Packet Data (HRPD) Push-to-Talk (PTT) Paging Enhancements featureadds the ability to have Priority Paging and additional paging areas options for RNCpaging.

Both features 12184.1 and 12184.5 are enhancements required for High Rate PacketData (HRPD) network to improve PTT performance by reducing the setup delays andmedia delays for the Radio Access Network (RAN) components (base station, backhauland Radio Network Controller (RNC)). PTT services are based on HRPD Revision A(Rev. A) to take advantage of the Enhanced Physical Layer and Quality of Service(QoS) features that provide support for Voice Over IP (VoIP) and Multimedia services.The PTT application is expected to prevent operation of the PTT service if High RatePacket Data Rev. A (HRPD-A) is not available.

Push-to-Talk (PTT) Enhancements (FID 12184.7)

To support applications like PTT that generate a significant paging load, thePush-to-Talk (PTT) Enhancements feature adds distance based paging as an additionalpaging method for QoS paging that was introduced in previous release by features12184.1 and 12184.5. Also, this feature introduces the ability to specify QoS pagingstrategy per RNC Group.


Overview

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


The features that are described in this document impact the following user interfaces:


DOrA Application QoSFeatures: FIDs 12087.9,12078.10, 12078.11,12078.12, 12078.13,12078.36, 12184.1, 12184.5and 12184.7

Element Management System(EMS) or Operations andMaintenance Center - RadioAccess Network (OMC-RAN)

See“Implementing thefeatures” (p. 8-52)

Service measurements See“Impacts onservice measurements”(p. 8-24)


None


None

Intended audience

This document is intended for technicians, engineers, and system administrators whoimplement or maintain the DOrA Application QoS Features in aCDMA2000®

1xEV-DO Network.



Contents

Availability 8-6

Prerequisites 8-7

Feature descriptions: DOrA Application QoS Features 8-9







Overview

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


8-5


Availability...................................................................................................................................................................................................................................


The following table identifies the AMPS/PCS software releases in which the DOrAApplication QoS Features are available.


FIDs 12087.9, 12078.10, 12078.12, 12078.1 3,12184.1, and 12184.5


FIDs 12078.11, 12078.36 and 12184.7 Release 29.0 and later

Market availability

The DOrA Application QoS Features are available in the following market:


DOrA Application QoS Features All markets


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Prerequisites...................................................................................................................................................................................................................................

Introduction

The DOrA Application QoS Features have the following prerequisites.


The DOrA Application QoS Features support the following air-interface technologies:

• EV-DO


DOrA Application QoS Features depend on the following features:

• Basic Revision A (Rev. A) Feature Bundle (12078.2, 12078.3, 12078.4, 12078.5,12078.7)

• The operation of the PTT features (12184.1, 12184.5, 12184.7) depend on differentPTT applications that include AT with PTT client and a compatible PTT server.

• MLPPP is required on the BTS-RNC backhaul for QoS features (12078.10). SincePTT is a QoS application, MLPPP is required for any PTT feature deployment.

MLPPP is required for all the QoS features. The BTS-RNC Backhaul for QoS feature(12078.10) was chosen as the feature to identified with MLPPP but since features12078.9 and 12078.10 are both required for all the other features, all Enhanced DataOnly Revision A (DOrA) Application Quality of Service (QoS) Features are dependenton MLPPP.

1xEV-DO Basic PTT Using 1xEV-DO Rev. A Network (FID 12184.1)

The 1xEV-DO Basic PTT Using 1xEV-DO Rev. A Network (FID 12184.1) featurerequires ECP Releases 28.0 or later.

The 1xEV-DO Basic PTT Using 1xEV-DO Rev. A Network (FID 12184.1) feature iscontrolled by the PTT Feature Activation File (FAF) per Service Node basis. The PTTFAF can be activated only if the Enhanced HRPD Rev. A package FAF is activated.The Enhanced Rev A package are required for PTT and contain the following features:


• Data Over Signaling Protocol (FID 12078.12)


In addition to FAF control the operator will have the ability to turn the featureON/OFFon Service Node basis.


The following summarizes the features described in this document.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


8-7


The 1xEV-DO Basic PTT Using 1xEV-DO Rev. A Network (FID 12184.1) featurerequires Multi Link Point-to-Point Protocol (MLPPP) on the backhaul in order tosupport QoS. MLPPP is replacing the Cisco HDLC (cHDLC) protocol used in previousreleases and needs to be supported by the cells, routers and RNC. Since PTT is a QoSapplication, MLPPP is required for PTT deployment.

HRPD PTT Paging Enhancements(FID 12184.5)

The High Rate Packet Data (HRPD) Push-to-Talk (PTT) Paging Enhancements featurerequires no hardware beyond the standard hardware in aCDMA2000® Network.

PTT Enhancements (FID 12184.7)

Push-To-Talk Enhancements feature requires no hardware beyond the standardhardware for Application Based Quality of Service (QoS) support.

Obtain New License Keys

Customers will obtain new license keys depending on the type of swings:

• Intra-RNC swing with the same BTS ID - No new license key is required

• Intra-RNC swing with different BTS ID - New BTS license keys are required

• Inter-RNC swing with the same or different BTS ID - New license keys arerequired on both source and target RNC and BTS

• License keys for target RNC and BTS must be installed prior to the swing. Licensekeys for source RNC and BTS must be installed after the swing.

For more details and specifics on how to obtain new license keys, see 401-614-101,CDMA2000® 1xEV-DO Network Radio Access System.


Prerequisites

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Feature descriptions: DOrA Application QoS Features...................................................................................................................................................................................................................................

Introduction

The following information defines the functionality, benefits, and operation of theDOrA Application QoS Features.

Functionality

The DOrA Application QoS Features are made up of: FIDs 12078.9, 12078.10,12078.11,12078.12, 12078.13,12078.36, 12184.1, 12184.5 and 12184.7, where the12078.x FIDs provide the QoS infrastructure and the QoS for Voice Over IP (VoIP)and video, and the 12184.x FIDs provide QoS for Push-To-Talk (PTT) capabilities. TheDOrA Application QoS Features are an optional bundle controlled by an ApplicationDOrA License as described in1xEV-DO RAS Planning and Implementation Guide,401-614-101.

Benefits

QoS provides support for differentiated treatment based on Service Categories ProfileID, etc. The Paging features allow different paging strategies to be set for each ProfileID.


Refer to the sections below for a detailed description of how the DOrA ApplicationQoS Features operate:

Application Based Quality of Service (QoS) support for HRPD Rev. A (FID12078.9)

This feature supports QoS per application flow based on request from the user, userQoS profile and allocatable resource at the system. It only includes the RAN networkelements. With VoIP, there are IMS Network elements that need to support QoS. Thisfeature is supported on both existing FMS and next generation RNC platforms. Also itis supported on any base station that supports the basic package for Rev. A. Thisfeature is configured on both OMC-RAN and OMP-FX platforms.

Service provider has the option to enable/disable this feature on a per service node(SN) basis. The service provider populates a set of QoS profile IDs that they want thesystem to support. This set will be from the set of Profile IDs that the productsupports.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


8-9

RAN Quality of Service Enhancements for HRPD Rev A (FID 12078.10)

This feature provides enhancements to the Application Based Quality of Service (QoS)support for HRPD Rev. A (FID 12078.9). This feature is dependent on the backhaulprotocol to be upgraded to MLPPP (Multi Link Point to Point Protocol) for T1/E1links.

• This feature offers the capability of the PDSN to modify the granted/ungrantedQoS for an existing reservation: If the AT sends a reservation request which grantsa reservation to the RAN, but the PDSN has a local policy that forbids it, this willmake the PDSN ungrant the reservation. The corollary of this situation is when aspecific AT requests a Profile Id that is not in the AAA server and should not begranted, but the PDSN overrides this decision.

• BTS Overload Control functionality: This includes complete Support of SB-EVMProcessor Overload Control and incremental support of LIU Overload Control. TheLIU Overload Control for Best Effort flows is already supported. This feature willalso take QoS flows into account.

• Critical Service Measurements: The above two items include Service Measurementsrelated to the specific functionality. In addition to that, there are some specificService Measurements that the customers have already asked for. These are listedin Section 8 of this document.

• Overload Control enhancements which includes RF and Backhaul OverloadControl: This includes incremental improvements over Overload Detection andControl mechanisms defined for FID 12078.9.

The control of this feature is the same as the basic QoS feature (12078.9). FID 12078.9is enabled or disabled through FAF per SN basis. If 12078.9 is enabled, 12078.10 willautomatically be enabled.

More Quality of Service (QoS) Enhancements for the High Rate Packet Data(HRPD) Revision A (Rev. A) Network (FID 12078.11)

The More Quality of Service (QoS) Enhancements for the High Rate Packet Data(HRPD) Revision A (Rev. A) Network feature is supported by the same FAF as12078.9 and 12078.10.

Important! This FID is able to support up to six flows.

After a Rev. A carrier is assigned to a Rev. A capable mobile, the previousimplementation automatically assigned a Rev. A personality to the mobile. In somescenarios (one example is when the neighboring carriers are Rev. 0), it makes sense toconsider a Rev. 0 personality. This consideration is part of the feature.

A new Threshold is added for carrier selection such that if the number of users in aRev. A carrier is above that threshold, the Rev. A only mobile (without QoSapplications) will be assigned to Rev. 0 carriers.


Feature descriptions: DOrA Application QoS Features

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

A new Threshold is added for carrier selection such that when a Rev. 0 mobileaccesses the network through a Rev. A carrier, the customer has the ability to control ifthe Rev. 0 mobile is assigned to the originating Rev. A carrier, or to a Rev. 0 carrier.The decision is based on the relative number of users in the Rev. 0 and Rev.A carrierand the threshold.

A new Threshold is added that specifies the minimum pilot strength for supporting aRev. A personality (Rev. A/DPA, Rev. A) without downgrading. That is if the combinedsignal strength for current Rev. A personality is larger that the MinCombinedPilot-StergnthRevA, personality downgrade will not be conducted.

The CSM6800 Scheduler uses 8 priority states for bit and bit stuffing metric butprevious implementation only allows maximum 3 priority states for each flow. Theenhancement increases the maximum number of priority states from 3 to 5 to improvescheduler performance.

Previous implementation uses BTS timestamp for scheduling. The enhancement allowsthe scheduler to use the RNC timestamp for scheduling. The scheduling performancewill be improved since the RNC timestamp includes the delay from RNC to the BTS.A number of new translations are added for enabling or disabling this enhancement,and for controlling the thresholds that defines when the RNC timestamp or the BTStimestamp should be used by the FL scheduler.

Critical SM and PCMD support including delay counts:

• Peak and Average Open Flows Per Service Category.

• Reservation Terminations because of excessive Packet Loss for ConversationalSpeech and Conversational Voice, and PTT applications.

• Traffic Delay SMs that measures the Forward Link scheduling delays at the BTSand also the Backhaul delays between RNC to BTS.

• Special Engineering Studies for SB-EVM Overload Control.

Session Status Command:

• The Session State Information Record will be enhanced to include Rev A protocolsand MFPA information.

TP and AP Overload Control Enhancement:

• For AP Overload Control enhancement, paging request throttling will givepreference to throttling BE related paging requests before QoS related pagingrequests. When a TP is in overload when a Reservation Request is received alongwith a connection request, an alternate TP should be selected. For PTT Call Setup,an alternate TP will be selected in a similar situation.

Synchronizing RTCMAC attributes between AN and AT after they change intranslations and tunables:

• If there is a change in RTCMAC attribute in RNC DB, ensure that AT also changesthe same in next connection.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


8-11


DoS is part of the Multi-Flow Packet Application (M-FPA) and is not separatelynegotiated between the AN and the AT. With M-FPA (provided in 12078.9), the ATestablishes RLP flows with the network. When certain criteria is met, DoS is used tocarry the flow data.

The DoS message format has the following characteristics:

• Carry the RLP flow ID - identify the RLP flow the data is associated with

• Can indicate if acknowledgment to the receipt of DoS message is required

• Carry message sequence number to allow duplicated message detection

• Contain entire higher layer packet (for example, entire HDLC frame packet)

In the reverse link direction, the AT application decides if the RLP flow packets needto be sent via DoS. The RLP flow is first established between the AT and the AN (viasession configuration or GAUP) and activated. Once activated (and the associatedreservation is in the open state), the RLP flow packets is sent via the access channelusing DoS and the AN forwards the packets to the PDSN over the associated A10connection.

In the forward link direction, the AN will send DoS to the AT only when the AT isdormant (such as, traffic channel has not been established). If a traffic channel isavailable, incoming packets received from the PDSN are sent over the traffic channel.When the AT is dormant, the AN decides if the incoming packet is appropriate to besent using DoS or should the AT be paged. It examines the size of the packet, theavailability of the control channel and the DoS filtering criteria to decide.

The DoS filtering criteria specified by the operator, defines the properties of the RLPflow for which DoS can be considered. It includes options such as matching DSCP(Differentiated Services Code Point) and QoS Profile data that are used as the filter. Ifthe condition is not in favor of sending DoS, the AT is paged to receive the data.

As DoS packets is sent to the AT while it is dormant, different DoS sending algorithms(for example, number of retries, number of sectors receiving DoS, locate AT firstbefore sending DoS) is adopted for different RLP flows depending on the associatedQoS profile data.

This feature supports DoS which is part of the Multi-Flow Packet Application(M-FPA).

This feature is bundled together with 12078.9 and 12078.13 as a single package(Enhanced Rev A Feature Bundle) and is controlled by FAF on a per service nodebasis.

Important! Only MO-DOS is supported in R28.0.



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


In a HRPD data session, the AT switches between the connected state and the idlestate. In the connected state, traffic channels are assigned and data is sent and received.When there are no data activities for a predefined period, the traffic channels arede-assigned and the AT is in the idle state. In the Default Idle State operation, the ATsleeps 12 control channel (CC) cycles (5.12 seconds) during idle and wakes upperiodically to monitor the CC for events such as paging. The AN keeps track of theAT wake up time and sends paging to the AT via the CC only at the AT wake up time.This approach has the following drawbacks:

• Waking up every 5.12 seconds may be too long for handling paging

To address the issues, Enhanced Idle State adopts the following approach:

• The periods that the AT sleeps are variables negotiated between the AT and the ANduring session configuration (or using GAUP)

• Three periods are defined with wake up intervals and period duration

• AN sends paging to AT via CC only at the AT wake up time (same as Default IdleState)

• Page mask also defined to identify the time that the mobile is not monitoring theCC for paging (for example, tune away for 3G-1X operation)

The T_Page1 parameter is the paging escalation timer for this feature. When this timerexpires, the AN broadens the area over which it will page the AT. By doing so, itincreases the backhaul load of the network. To minimize the impact to the networkload the parameter value of60 is used as an off switch. Instead of a broaden page areaafter 60 minutes, the paging escalation is turnedoff when the value is set to60. Sowhen the default is set to60, the default setting isoff.

This feature works together with 12078.9 and 12078.12 as a single package (EnhancedRev A Feature Bundle) and is controlled by FAF on a per service node basis.


This feature enables the support of transmission of small amounts of end user dataover the control channel (forward link) using the Data over Signaling (DoS) protocoldefined in the HRPD Rev. A standard. This feature is a complementary feature to FID12078.12 which enables the support of transmission of small amounts of end user dataover the access channel (reverse link) using the DoS protocol.


The 1xEV-DO Basic PTT Using 1xEV-DO Rev. A Network feature provides basic PTTfunctionality in the HRPD RAN using HRPD Rev. A. The HRPD Rev. A feature isrequired to help meet the tight QoS requirements.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


8-13

The 1xEV-DO Basic PTT Using 1xEV-DO Rev. A Network feature improves PTTperformance by up to three distinct QoS flows for PTT applications to use to providedifferentiated QoS in the RAN. It also provides the ability to provide paginglatency/efficiency tradeoffs by allowing the service provider to individually specify thepaging strategy for different types of QoS flows.

Although PTT applications can function over a best effort EVDO RAN network (e.g.using Default Packet Application), to be a viable commercial service the QoScapabilities provided by the Multi-Flow Packet Application are required.

The PTT application resides in the mobile client and the PTT servers. The applicationsignaling and traffic path are originated/terminated in the mobile clients and controlledby the PTT server. PTT signaling can be SIP-based or proprietary SIP-like protocol.The RAN function is to recognize the PTT application and insure minimum delay forsignaling and media, based on the QoS treatment specified.

The PTT requires half-duplex communication so the requirements are different thanfull-duplex VoIP requirements: PTT has more stringent signaling delay requirementswhile VoIP has more stringent media delay requirements. The feature is based on theMultiflow Packet Application (MFPA) and does not require header compression. RTPframe bundling may be used by PTT application to reduce Internal Protocol/UniversalDatagram Protocol/Rate Time Protocol (IP/UDP/RTP) header overhead by allowingmultiple vocoder frames into one IP packet, thereby increasing air interface capacity.The 1xEV-DO Basic PTT Using 1xEV-DO Rev. A Network feature is intended to bethe initial DO PTT implementation that can be deployed with the first HRPD Rev. AATs that might not support Robust Header Compression (ROHC) are required for VoIP.

The 1xEV-DO Basic PTT Using 1xEV-DO Rev. A Network feature is defined to beindependent of the PTT application implementations as long as they comply to thestandard HRPD Rev. A and QoS as defined in TIA TSB-58-G, TIA-856-A-2, andTIA-835-D. The feature is expected to work with different PTT solutions. If additionalenhancements are required for OMA PoC compliance with a specific PTT application(for example, OMA POC), a separate feature will be required.

The PTT service performance (setup and media latencies) are heavily dependent on thedifferent PTT solutions.

The RAN delay component (including backhaul delay) is one of the several elementsthat determine the PTT service delay performance. Other components of the overalldelay are: mobile client PTT application, PDSN processing, core network legacy, PTTservers. These elements are outside the scope of this feature.

RAN QoS Background



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

The Application Based Quality of Service (QoS) Support for HRPD Rev. A feature(FID 12078.9) and the RAN Quality of Service Enhancements for HRPD Rev Afeature (FID 12078.10) provide the fundamental capabilities to support the Multi-FlowPacket Application (MFPA). These features provide support for four Service Categories(that is, groupings of related application flows that share common QoS controls)

• Media Control Signaling (MCS): not delay sensitive

• Best effort (BE): not delay sensitive, high capacity

• Conversational Speech (CS): delay sensitive, low latency

• Conversational Video (CV): delay sensitive, low latency

Each Service Category may contain multiple IP flow types (labeled with aProfileID )with similar QoS requirements. Each Service Category is assigned with a dedicatedRLP flow and each RLP flow is one to one mapped to an A10 connection.

The initial PTT feature assumes the use of MFPA and requires separate flows identifiedby differentProfileID for PTT signaling and PTT media. TIA TSB-58-G defines theFlowProfileID s that can be used for different applications, including PTT. EachProfileID maps to a specificFlowProfileID . The PTT application must use a supportedProfileID to allow the adequate QoS treatment. Verbose negotiation of QoS flowparameters is not supported.

The PTT application will use a specificProfileID to allow the adequate QoS treatment.

To meet the unique QoS requirements of PTT, two new service categories are added asfollows:

• Low Latency Media Control Signaling (LL-MCS) service category is added tosupport PTT signaling

• Conversational PTT Speech service category is added to accommodate the differentQoS needs of the PTT bearer

The 1xEV-DO Basic PTT Using 1xEV-DO Rev. A Network feature also introduces fournew Profile IDs for PTT:

Under the LL-MCS Service Category:

• PTT Call Setup SignallingProfileID

• PTT In-Call SignallingProfileID

Under the Conversational PTT Speech Service Category:

• PTT Speech Bearer 1ProfileID

• PTT Speech Bearer 2ProfileID



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


8-15

These new service categories andProfileID s allow the service provider to differentiatethe treatment of PTT related flows with respect to other types of data traffic. WithFeature 12184.1, the mapping between theProfileID (for example. PTT Speech Bearer1) and the TSB-58-GFlowProfileID is not fixed, but can be configured. However, theRAN is configured to best support the following configuration:

FeatureProfileID FlowProfileID Value

PTT Call Setup Signaling ProfileID 1283

PTT In-Call Signaling ProfileID Blank

PTT Speech Bearer 1 ProfileID 280

PTT Speech Bearer 2 ProfileID Blank

If this profile ID is configured, then theprofile ID parameters are applicable toProfileID 261.

Important! Whenever a PTT Speech Bearer ProfileID is modified, please contactAlcatel-Lucent support to update the appropriate header compression capability forthe PTT forward link backhaul bearer traffic processing messages.

In a multi-media model, PTT data arriving for a dormant AT must be treated differentlythan the best effort data-only case. PTT introduces data traffic with different QoSrequirements for different flows. Voice applications in general and especially PTTrequire lower latency for initial setup. Therefore, paging methods must be moreintelligent and require flexibility to accommodate different classes of traffic.

To accommodate the stringent delays requirements for initial call setup, a new″QoSPaging Strategy″ is introduced for PTT. The QoS paging strategy is a perProfileIDstrategy that can be configured per attempt for different paging areas. Up to 8 pagingattempts can be specified for eachProfileID . The paging area is defined to be one ofthe following types (defined on a per Profile ID/per page attempt basis):

• Last_Active_Set

• Last_Seen_RNC

Subscriber perspective: The PTT service fills the average person’s need for fast shortcommunication. The ability to instantaneously communicate “at the push of a button”with one and even a group of people appeals to different segments of users from chattyteenagers to first responders. PTT services are in big demand for commercial networks(private use and enterprise markets) and public safety networks.

Service-provider perspective: Deploying PTT services using HRPD air interface is anevolution allowing operators to take advantage of the VoIP capabilities and enhancedperformance of the new HRPD networks while maintaining the capacity andperformance of legacy circuit voice services. The 1xEV-DO Basic PTT Using



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

1xEV-DO Rev. A Network feature allows the service providers to offer a competitivePTT service to their subscribers while increasing the value of their wireless datapackage.

The HRPD PTT can be integrated with IMS increasing the set of blended servicesoffered to subscribers. Blended services are IMS services that share a set of capabilitiesand databases allowing different applications to be integrated.

High Rate Packet Data (HRPD) Push-to-Talk (PTT) Paging Enhancements (FID12184.5)

The HRPD PTT Paging Enhancements feature includes the following functionality:

• Priority paging: which allows pages to be scheduled based on certain criteria. Thecriteria areProfileID (for example, PTT versus conversational speech) , page area(for exampleLast_Active_Set versusLast_Seen_RNC) and page attempt. Thepriority of the criteria is provisionable (for exampleFirst Rank Pages based onProfileID , thenPageAarea , and thenPage Attempt ).

• RNC paging: which allows paging over multiple RNCs. QoS paging introduced by1xEV-DO Basic PTT Using 1xEV-DO Rev. A Network (FID 12184.1) is extendedto includeRNC Group andNeighbor RNC paging areas methods. These methods areimplemented under the RNC Grouping to Improve Idle Hand-off Performancefeature (12456.1), only their use for QoS paging is part of the HRPD PTT PagingEnhancements feature (FID 12184.5).

• QoS Paging De-escalation

The HRPD PTT Paging Enhancements feature improves PTT performance by reducingthe setup delays and media delays for the RAN components (base station, backhaul andRNC).

It adds the ability to QoS Paging for Priority Paging, Paging Areas that span RNCs ina Group, and Paging De-escalation.

Deploying PTT services using HRPD air interface is an evolution allowing operators totake advantage of the VoIP capabilities and enhanced performance of the new HRPDnetworks while maintaining the capacity and performance of legacy circuit voiceservices. The HRPD PTT Paging Enhancements feature allows the service providers tooffer a competitive PTT service to their subscribers while increasing the value of theirwireless data package.

The HRPD PTT can be integrated with IMS increasing the set of blended servicesoffered to subscribers. Blended services are IMS services that share a set of capabilitiesand databases allowing different applications to be integrated.


Distance based paging allows the paging area to be defined based on distance from thelast registered cell. The radius of the paging area is defined using 4 tiers and isprovisionable. The first tier is specified to be based on the radius used for



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


8-17

RouteUpdateRadius . The RouteUpdateRadius parameter, when set to a non-zerovalue, is used to require the AT to do distance based registration. The other three tierscan be defined to provide greater flexibility. Distance based paging is supported withinan RNC group. The 4 Distance based paging tiers are added as additional pagingmethods for QoS paging that was introduced in the previous release by features FIDs12184.1 and 12184.5.

After this feature is implemented, the paging strategy for aProfileID allows thefollowing paging methods for each paging attempt:

• Last_Active_Set

• Last_Seen_RNC

• Neighbor_RNC

• RNC_Group

• Distance_Tier0

• Distance_Tier1

• Distance_Tier2

• Distance_Tier3

Distance based paging is introduced to improve the paging efficiency, especially whenthe RNC group capability is supported. Customers can defined a region where AT isrequired to report to AN when it has moved out of the region. So AT can be pagedreliably within a distance based region. The distance based paging region can beoptimized to balance the paging efficiency and AT reporting frequency. This isespecially useful when RNC group capability is supported. RNC grouping is introducedby FID 12456.1, see Chapter 11 of this document, as a way to reduce theUATIRequest ping-ponging and paging failures at RNC borders. At the same time, bynot having UATIRequest at the RNC borders, the RAN looses the ability to be able toknow the location of the AT within the RNC group. Distance based paging allows theRAN to use a smaller paging area than the entire RNC group.

To allow additional flexibility, the PTT Enhancements feature provides the option toprovision the paging strategy for aProfileID per RNC group. This is in addition to perSN/ProfileID provisioning provided by FIDs 12184.1, and 12184.5.

Having the paging strategy forProfileID be provisionable per RNC group in additionto per SN allows operators the flexibility of setting QoS Paging Strategy uniformlyacross an RNC Group since an SN can support multiple RNC Groups and RNCGroups are allowed to span multiple SNs.

Distance based paging is controlled by theDistance Paging Enable control field. See“Activating the feature” (p. 8-54)for details.



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Introduction

The DOrA Application QoS Features interact or depend on the following features.

Important! The 1xEV-DO Rev. A VoIP and Application Pricing FID 12905.0 is theApplication Pricing feature fro R28.0 that FIDs 12078.9, 12078.10, etc. aredependent on. The FID 12905.1 is the R29 Application Pricing feature. The DOrAApplication QoS Features cannot be activated without the licenses from FIDs12905.0 and 12905.1.

Basic Revision A (Rev. A) Feature Bundle

FIDs 12078.2, 12078.3, 12078.4, 12078.5 and 12078.7 make up the software collectionreferred to as Rev. A Feature Bundle and are activations via a software licensing keymechanism instead of the usual Feature Activation File/Qualified Feature ActivationFile (FAF/QFAF) mechanism.

The Basic DOrA License Key must be purchased in order to enable DOrA Applicationfunctionality. The license key is used for the activation of the DOrA Applicationfunctionality for one or more Rev. A-capable Base Transceiver Station (BTS)-Carriersserved by the RNC.

Basic DOrA License Key is managed by the RNC and is enabled per carrier. Forexample:

• Base station 1 has one Rev A carrier, therefore, 1 Rev A license is required.

• Base station 2 has two Rev A carriers, therefore, 2 Rev A licenses are required.

• Base station 3 has three Rev A carriers, therefore, 3 Rev A licenses are required.

The service provider needs to install the license key via Element Management System(EMS) or EMS or OMC-RAN GUI on the OMP-FX and assign license keys to thebase station carriers to enable the base station carrier(s).

When the Basic Rev. A Features are activated within the Radio Access System they arereferred to as HRPD Rev. A system.

The HRPD Rev. A system supports Release 27.0 FIDs and any new Rev. A features.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


8-19


This feature is part of the Basic Rev. A Feature Bundle, also referred to as Basic Rev.A Feature Bundle. This feature introduces the support of the full Rev. A Physical Layerwith the complete set of Rev. A enhanced MAC protocols that is the following MACprotocols are supported:





This feature is supported on all Modular Cell BTS types using the new HRPD Rev. Amodem board, the SB-EVM for Modular Cell 4.0 and variants or the SB-EVMm forModular Cell 1-3. This feature is supported only by the Rev. A capable RNC.


This feature is part of the Basic Rev. A Feature Bundle. This feature allowsconfiguration attribute changes without costly session configuration protocol exchangeand without releasing the connection. It allows the AT and the AN to use the GAUP toupdate values of the session parameter attributes belonging to different lower andhigher layer protocols and applications.

HRPD Rev. A Support on Modular Cell 1-3 BTS Platforms using SB-EVMm (FID12078.4)

This feature is part of the Basic Rev. A Feature Bundle and provides the necessaryhardware and software for the Modular Cell 1-3 products to make use of any otherRev. A feature. This feature supports HRPD Rev. A technology on all Modular Cell1-3. This feature includes Software, OA&M and Service Measurements support relatedto HRPD Rev. A for the Modular Cell 1-3 BTS platforms.

The following Modular Cell 1.0/2.0/3.0 BTS products will be supported:




The term Modular Cell 1-3 is used in this chapter to include the variants listed above.



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

HRPD Rev. A Support on Modular Cell 4.0 BTS Platforms using SB-EVM (FID12078.5)

This feature is part of the Basic Rev. A Feature Bundle and provides the necessaryhardware and software for the Modular Cell 4.0 products to make use of any otherRev. A feature. This feature supports HRPD Rev. A technology on all Modular Cell 4.0Platforms. This feature includes Software, OA&M and Service Measurements supportrelated to HRPD Rev. A for the Modular Cell 4.0 platforms.

The following Modular Cell 4.0 products will be supported:


• Modular Cell 4.0 B

• Compact 4.0

• Compact 4.0 B

• HD 4.0

• HD 4.0 B

• Digital Host 4.0

• Digital Host 4.0 B

The term Modular Cell 4.0 is used in this chapter to include the variants listed above.


This feature is part of the Basic Rev. A Feature Bundle. The purpose of this feature isto support, in both Rel 0 systems and in mixed Rel 0/Rev. A systems:



This feature does not include active handoff from Rel. 0 to Rev. A systems.

Application Based Quality of Service (QoS) Support for HRPD Rev. A (FID 12078.9)

FID 12078.9 depends on the Rev. A Basic Feature Bundle (12078.2, 12078.3, 12078.4,12078.5, 12078.7) for the Basic Rev. A function and interface:

• HDR Reverse Link Overload Control (HROC ) (FID 8048.1)

Important! The HROC feature (FID 8048.1) handles the RF overload in thereverse link. This action takes the user class into account while making decisions.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


8-21

RAN Quality of Service Enhancements for HRPD Rev. A (FID 12078.10)

FID 12078.10 depends on the Rev. A Basic Feature Bundle (12078.2, 12078.3,12078.4, 12078.5, 12078.7) for the Enhanced DOrA Feature Bundle functions andinterfaces and the basic QoS feature 12078.9. This means that 12078.10 isautomatically dependent on any features the above features depend upon.

This feature is also dependent on 1xEV-DO Backhaul with Multi Link Point-to-PointProtocol (MLPPP) at Layer 2 Over T1/E1 (FID 12304.11) , Chapter 9, at layer 2 overT1/E1 links. This essentially means that the operator needs to transition from HDLC toMLPPP if they would like to take advantage of Quality of Service feature and theassociated applications.

In addition, 1xEV-DO Rev. A VoIP and Application Pricing (FID 12905.0) Chapter 10,introduces a separate pricing structure based on various QoS applications. This meansthat any new QoS application will be priced according an algorithm defined by FID12905.0. FID 12078.10 has interactions with FID 12905.0 since it supports VideoTelephony application.

More Quality of Service (QoS) Enhancements for the High Rate Packet Data (HRPD) Revision A(Rev. A) Network (FID 12078.11)

This feature is dependent on the basic Rev. A package (FIDs 12078.2, 12078.3,12078.4, 12078.5 and 12078.7) and the QoS features. This feature is still automaticallydependent on 1x- EV-DO Backhaul with Mutli Link Point-to-Point Protocol (MLPPP),FID 12304.11, Chapter 9 of this document. If the backhaul is not upgraded to MLPPP,customers can not take advantage of QoS features or services.


FID 12078.12 depends on the Rev. A Basic Feature Bundle (12078.2, 12078.3,12078.4, 12078.5, 12078.7) for the Enhanced DOrA Feature Bundle functions andinterfaces.

Data over Signaling is part of the Multi-Flow Packet Application (M-FPA). Thisfeature therefore depends on (FID 12078.9) the QoS feature that supports M-FPA. DoScannot be used unless M-FPA is first configured. If quicker handling of DoS over thecontrol channel is desirable, FID 12078.13 (Enhanced Idle State) is applied.


FID 12078.13 depends on the Rev. A Basic Feature Bundle (12078.2, 12078.3,12078.4, 12078.5, 12078.7) for the Enhanced DOrA Feature Bundle functions andinterfaces.



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


FID 12078.36 depends on the Rev. A Basic Feature Bundle (12078.2, 12078.3,12078.4, 12078.5, 12078.7) for the Enhanced DOrA Feature Bundle functions andinterfaces. This feature is a complementary feature to FID 12078.12.


The 1xEV-DO Basic PTT Using 1xEV-DO Rev. A Network (FID 12184.1) introducesQoS paging using two paging area types: Last Seen Active Set and Last Seen RNC(Color Code). The HRPD PTT Paging Enhancements (FID 12184.5) feature adds theability to have Priority Paging and extends it to include RNC Group and NeighborRNC paging areas.

HRPD PTT Paging Enhancements (FID 12184.5)

The HRPD PTT Paging Enhancements feature interacts with the following features:

• 1xEV-DO Basic PTT Using 1xEV-DO Rev. A Network (FID 12184.1)

• Radio Network Controller (RNC) Grouping to Improve Idle Hand-off Performance(FID 12456.1)


PTT Enhancements interacts with the following features:

• HRPD PTT Paging Enhancements (FID 12184.5)




...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


8-23


Introduction

The DOrA Application QoS Features affect the following categories of servicesmeasurements:


The major focuses of the new service measurements for the Application Based Qualityof Service (QoS) Support for HRPD Rev. A feature are to provide information on howthe system supports the QoS applications, and how the service providers can betterengineer the system. The SMs for Application Based Quality of Service (QoS) Supportfor HRPD Rev. A feature are grouped into the following categories:

• Setup related counts

• Connection request relate

• Reservation related

• Reservation downgrade (priority change) counts

• Reservation termination/drop counts

• Personality switch counts (minimum)

• Overload related counts

The SM counts defined for Application Based Quality of Service (QoS) Support forHRPD Rev. A feature will be reported as zeros if the feature is disabled. The SMcounts that are required for all Rev A services, are included in Protocols with Rev. APhysical Layer (12078.2) feature or/and the Inter and Intra-Radio Network Controller(RNC) Handoff Enhancement (FID 12078.7) feature instead of the Application BasedQuality of Service (QoS) Support for HRPD Rev. A feature. Also, many of the existingRel 0 and Basic Rev-A SMs are carried forward in the Application Based Quality ofService (QoS) Support for HRPD Rev. A feature. What this means is that most (if notall) of the existing counts remain applicable to measure the system performance invarious aspects when the Application Based Quality of Service (QoS) Support forHRPD Rev. A feature is enabled, regardless whether the AT is using the QoS servicesor not.

RAN Quality of Service Enhancements for HRPD Rev. A (FID 12078.10)

These new service measurements are related to RAN Quality of Service Enhancementsfor HRPD Rev. A (FID 12078.10).


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

The RAN Quality of Service Enhancements for HRPD Rev. A (FID 12078.10) featureaffects the service measurements that are identified inTable 8-1, “RAN Quality ofService Enhancements for HRPD Rev. A Feature: New Service Measurements”(p. 8-25)

Table 8-1 RAN Quality of Service Enhancements for HRPD Rev. A Feature:New Service Measurements



CG CONTL SM_FL_BH_PACKET_LOSS_RATE_CPS

FL BH Packet Loss Ratefor Push-to-Talk

CG CONTL SM_FL_BH_PACKET_LOSS_RATE_CS

FL BH Packet Loss Ratefor Conversational Speech

CG CONTL SM_FL_BH_PACKET_LOSS_RATE_CV

FL BH Packet Loss Ratefor Conversational Video

CG CONTL SM_RL_BH_PACKET_LOSS_RATE_CPS

RL BH Packet Loss Ratefor Push-to-Talk DSCP

CG CONTL SM_RL_BH_PACKET_LOSS_RATE_CS

RL BH Packet Loss Ratefor Conversational SpeechDSCP

CG CONTL SM_RL_BH_PACKET_LOSS_RATE_CV

RL BH Packet Loss Ratefor Conversational VideoDSCP

CG EVM AVG_PERC_FLOWS_MUTED_BAP

Average percentage of RLBE flows muted due toBAP overload

CG EVM AVG_PERC_FLOWS_MUTED_BMP

Average percentage of RLBE flows muted due toBMP overload

CG EVM AVG_PERC_PACKETS_DROPPED_BAP

Average percentage of FLEF packets dropped due toBAP overload

CG EVM AVG_PERC_SLOTS_SKIPPED_BMP

Average percentage of FLslots skipped in DSP dueto BMP overload

CG EVM AVG_PERC_WINDOW_SHRANK_BAP

Average percentage of FLBE flows window sizeshrank due to BAPoverload



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


8-25

Table 8-1 RAN Quality of Service Enhancements for HRPD Rev. A Feature:New Service Measurements (continued)

CG EVM PEAK_PERC_FLOWS_MUTED_BAP

Peak percentage of RL BEflows muted due to BAPoverload

CG EVM PEAK_PERC_FLOWS_MUTED_BMP

Peak percentage of RL BEflows muted due to BMPoverload

CG EVM PEAK_PERC_PACKETS_DROPPED_BAP

Peak percentage of FL EFpackets dropped due toBAP overload

CG EVM PEAK_PERC_SLOTS_SKIPPED_BMP

Peak percentage of FLslots skipped in DSP dueto BMP overload

CG EVM PEAK_PERC_WINDOW_SHRANK_BAP

Peak percentage of FL BEflows window size shrankdue to BAP overload

CG OHM CPS_RESV_CLOSED_PDSN_A11_SESSION_UPDATE

Push-to-Talk reservationsclosed due to A11 SessionUpdate

CG OHM CS_RESV_CLOSED_PDSN_A11_SESSION_UPDATE

Conversational Speechreservations closed due toA11 Session Update

CG OHM CV_RESV_CLOSED_PDSN_A11_SESSION_UPDATE

Conversational Videoreservations closed due toA11 Session Update

CG OHM RESV_GRANTED_PDSN_A11_SESSION_UPDATE

Reservations granted byA11 session update fromthe PDSN

CG OHM RESV_NULLED_PDSN_A11_SESSION_UPDATE

Reservations nulled by A11session update from thePDSN

SECT-CARR-HCS EVM_ACCESS_CH_MAC_PACKETS_19_2

Number of Access MACLayer Packets Received onAccess Channel at19.2kbps


Number of Access MACLayer Packets Received onAccess Channel at38.4kbps



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008



Number of Access MACLayer Packets Received onAccess Channel at 9.6kbps

SECT-CARR-HCS EVM_AVG_USERS_PER_MUP

Average Number of Usersper Multiple User Packet

SECT-CARR-HCS EVM_FL_MUPS Number of Multiple UserPackets Transmitted onForward Link

SECT-CARR-HCS EVM_RLP_RETXED_FTC_BE

RLP Octets Retransmittedon the Forward TrafficChannels for Best Effort

SECT-CARR-HCS EVM_RLP_RETXED_FTC_DARQ_BE

RLP Octets Retransmittedon Forward TrafficChannels due to DARQ forBest Effort

SECT-CARR-HCS EVM_RLP_RETXED_FTC_DARQ_CPS

RLP Octets Retransmittedon Forward TrafficChannels due to DARQ forPush-to-Talk

SECT-CARR-HCS EVM_RLP_RETXED_FTC_DARQ_CS

RLP Octets Retransmittedon Forward TrafficChannels due to DARQ forConversational Speech

SECT-CARR-HCS EVM_RLP_RETXED_FTC_DARQ_CV

RLP Octets Retransmittedon Forward TrafficChannels due to DARQ forConversational Video

SECT-CARR-HCS EVM_RLP_RETXED_FTC_DARQ_SMC

RLP Octets Retransmittedon Forward TrafficChannels due to DARQ forSMC

SECT-CARR-HCS EVM_RLP_RETXED_FTC_SMC

RRLP Octets Retransmittedon the Forward TrafficChannels for SMC

SECT-CARR-HCS EVM_RLP_TXED_FTC_BE

RLP Octets Transmitted onthe Forward TrafficChannels for Best Effort



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


8-27


SECT-CARR-HCS EVM_RLP_TXED_FTC_CPS

RLP Octets Transmitted onthe Forward TrafficChannels for Push-to-Talk

SECT-CARR-HCS EVM_RLP_TXED_FTC_CS

RLP Octets Transmitted onthe Forward TrafficChannels forConversational Speech

SECT-CARR-HCS EVM_RLP_TXED_FTC_CV

RLP Octets Transmitted onthe Forward TrafficChannels forConversational Video

SECT-CARR-HCS EVM_RLP_TXED_FTC_SMC

RLP Octets Transmitted onthe Forward TrafficChannels for SMC

SECT-CARR-HCS RLP_RCVD_RTC_SMC RLP Octets Received onthe Reverse TrafficChannels for SMC

TP A11_SESSION_UPDATE_ACCEPTED

A11 session updateaccepted

TP A11_SESSION_UPDATE_RECEIVED

A11 session updatereceived

TP A11_SESSION_UPDATE_REJECTED

A11 session updaterejected

More QoS Enhancements for the HRPD Rev. A Network (FID 12078.11)

The More QoS Enhancements for the HRPD Rev. A Network (FID 12078.11) featureincludes a number of service measurements meant to measure the QoS capabilitiesalready implemented in 12078.9 and 12078.10. These SMs can be grouped in to thefollowing categories:

• SBEVM Overload related measurements defined in terms of SES (SpecialEngineering Studies) SMs.

• Reservation termination are new SMs capturing additional reservation terminationscenarios.



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

• Personality (especially MFPA) related SMs are MFPA specific SMs that couldnot be incorporated in the earlier release, although the corresponding capability isalready implemented. (Note that since Rev. A has distinct personalities, such asDPA (Default Packet Application), and MFPA (Multi-Flow Packet Application), andare not always distinguished, MFPA may use Rev. A general SMs defined in otherfeatures.

• Usage related SMs include the average and peak open flows of each servicecategory. Also, since certain service categories have multiple rates, average andpeak bandwidth allocated are collected as well for these categories.

• FL Packet Drops in TP for each service category when TP is in overload.

• Delays are SMs measuring FL BTS delay , FL RNC delay as well as FL and RLbackhaul delays.

The More QoS Enhancements for the HRPD Rev. A Network (FID 12078.11) featureaffects the service measurements that are identified in theTable 8-2, “More QoSEnhancements for the HRPD Rev. A Network: Modified Service Measurements”(p. 8-29), Table 8-3, “More QoS Enhancements for the HRPD Rev. A Network: NewService Measurements” (p. 8-30), Table 8-4, “More QoS Enhancements for the HRPDRev. A Network: Existing Service Measurements Pegged by Feature” (p. 8-38)andTable 8-5, “More QoS Enhancements for the HRPD Rev. A Network: Renamed ServiceMeasurements” (p. 8-38).

Important! The following counts were defined for DBEVM. The names anddescriptions were modified and reused for SBEVM with out creating new counts.

Table 8-2 More QoS Enhancements for the HRPD Rev. A Network: ModifiedService Measurements



SNHCS-CTID-EVM FLM_BAP_AVG_PROC_OCCUPANCY

FLM/BAP AverageProcessor Occupancy

SNHCS-CTID-EVM FLM_BAP_PEAK_PROC_OCCUPANCY

FLM/BAP AverageProcessor Occupancy

SNHCS-CTID-EVM FLM_BAP_OVERLOAD_DURATION

Duration of FLM/BAP inOverload

SNHCS-CTID-EVM FLM_BAP_OVERLOAD_NUM

Number of timesFLM/BAP in Overload

SNHCS-CTID-EVM RLM_BMP_AVG_PROC_OCCUPANCY

RLM/BMP AverageProcessor Occupancy

SNHCS-CTID-EVM RLM_BMP_PEAK_PROC_OCCUPANCY

RLM/BMP Peak ProcessorOccupancy



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


8-29

Table 8-2 More QoS Enhancements for the HRPD Rev. A Network: ModifiedService Measurements (continued)

SNHCS-CTID-EVM RLM_BMP_OVERLOAD_DURATION

Duration of RLM/BMP inOverload

SNHCS-CTID-EVM RLM_BMP_OVERLOAD_NUM

Number of timesRLM/BMP in Overload

Table 8-3 More QoS Enhancements for the HRPD Rev. A Network: New ServiceMeasurements



SN-HCS-CTID-EVM TIMES_SLOTS_SKIPPED_BMP_10

FL slots skipped due tooverload in the BMP isbetween 1 to 10 percent.

















...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Table 8-3 More QoS Enhancements for the HRPD Rev. A Network: New ServiceMeasurements (continued)

SN-HCS-CTID-EVM TIMES_FLOWS_MUTED_BMP_10

RL BE flows are muted dueto overload in the BMP isbetween 1 to 10 percent.Note that there is 1 flow percall in Rev. 0 and multipleflows per call in Rev. A.













...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


8-31






SN-HCS-CTID-EVM TIMES_WINDOW_SHRANK_BAP_10

FL BE flows window sizeshrank due to overload inthe BAP is between 1 to 10percent.













...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008






SN-HCSCTID- EVM TIMES_FLOWS_MUTED_BAP_10

RL BE flows are muted dueto overload in the BAP isbetween 1 to 10 percent.Note that there is 1 flow percall in Rev. 0 and multipleflows per call in Rev. A.











...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


8-33








SN-HCS-CTID-EVM TIMES_PACKETS_DROPPED_BAP_10

FL EF packets are droppeddue to overload in the BAPis between 1 to 10 percent.















...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008






SN-HCS-ANT-CARR FL_RESV_TERM_DROPPED_PKTS_EX_THRESH

FL reservations terminateddue to number of droppedpackets exceeding threshold:Conversational PTT Speech,Speech, Video

SN-HCS-ANT-CARR RL_RESV_RM_OPPOSITE_RESV_DROP

RL Reservations Terminateddue to Termination ofOpposite Reservations:Conversational PTT Speech,Speech, Video

SN-HCS-ANT-CARR FL_RESV_TERM_INV_BH

FL reservations terminateddue to unacceptable BH typeof newly added sector toactive set: ConversationalPTT Speech, Speech, Video

SN-HCS-ANT-CARR RL_RESV_TERM_INV_BH

RL reservations terminateddue to unacceptable BH typeof newly added sector toactive set: ConversationalPTT Speech, Speech, Video

SN-HCS-ANT-CARR PERS_SWTCH_CONN_TCA

Traffic Channel Assignmentsfor Personality Switch

SN-HCS-ANT-CARR PERS_SWTCH_CONN_ESTABLISHED

Established Connections forPersonality Switch

SN-IEnd- FMS-OHM NUM_AT_MFPA_SESS_ESTABLISHED

ATs with Rev. A/MFPA asthe highest personalitynegotiated.

SN-HCS-ANT-CARR AVG_OPEN_FL_FLOW Average FL BandwidthAllocated for ConversationalPTT Speech, Speech, Video



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


8-35


SN-HCS-ANT-CARR AVG_OPEN_RL_FLOW Average FL BandwidthAllocated for ConversationalPTT Speech, Speech, Video

SN-HCS-ANT-CARR PEAK_OPEN_FL_FLOW Peak Number of Open FLFlows: Conversational PTTSpeech, Speech, Video

SN-HCS-ANT-CARR PEAK_OPEN_RL_FLOW Peak Number of Open RLFlows: Conversational PTTSpeech, Speech, Video

SN-HCS-ANT-CARR AVG_FL_BW_ALLOCATED_CV

Average FL BandwidthAllocated for ConversationalVideo

SN-HCS-ANT-CARR AVG_RL_BW_ALLOCATED_CV

Average RL BandwidthAllocated for ConversationalVideo

SN-HCS-ANT-CARR PEAK_FL_BW_ALLOCATED_CV

Peak FL BandwidthAllocated for ConversationalVideo

SN-HCS-ANT-CARR PEAK_RL_BW_ALLOCATED_CV

Peak RL BandwidthAllocated for ConversationalVideo

SN-FMS-TP A10_PKT_SENT_TO_RLP

A10 Packets Sent to RLP

SN-FMS-TP RLP_PKT_SENT_TO_PCF

RLP Packets Sent to PCF

SN-FMS-TP FL_PACKETS_DROPPED_TP_OVLD_EF

FL EF Packets Droppedwhen TP is in overload

SN-FMS-TP FL_PACKETS_DROPPED_TP_OVLD_SMC

FL SMC Packets Droppedwhen TP is in overload

SN-FMS-TP FL_PACKETS_DROPPED_TP_OVLD_BE

FL BE Packets Droppedwhen TP is in overload

SN-HCS-ANT-CARR FL_BTS_DELAY_SUM FL BTS delay aggregate forRLP packets: BE, CS, CPS,CV, LLMCS, and SMC.

SN-HCS-ANT-CARR FL_BTS_DELAY_TOTAL_PKTS

FL BTS delay RLP packetssampled: BE, CS, CPS, CV,LLMCS, and SMC.



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


SN-HCS-ANT-CARR FL_BTS_DELAY_S_PEAK

FL BTS delay smoothedpeak for RLP packets: BE,CS, CPS, CV, LLMCS, andSMC.

SN-FMS-BTS FL_RNC_DELAY_SUM FL RNC delay aggregate forRLP Packets: BE, CS, CPS,CV, LLMCS, and SMC.

SN-FMS-BTS FL_RNC_DELAY_TOTAL_PKTS

FL RNC delay RLP Packetssampled: BE, CS, CPS, CV,LLMCS, and SMC.

SN-FMS-BTS FL_RNC_DELAY_S_PEAK

FL RNC Delay smoothedpeak for RLP Packets: BE,CS, CPS, CV, LLMCS, andSMC.

SN-HCSCTID FL_RNC_N_BH_DELAY_SUM

FL RNC + BH delayaggregate for RLP packets:BE, CS, CPS, CV, LLMCS,and SMC.

SN-HCSCTID FL_RNC_N_BH_DELAY_TOTAL_PKTS

FL RNC + BH delay RLPpackets sampled: BE, CS,CPS, CV, LLMCS, andSMC.

SN-HCSCTID FL_RNC_N_BH_DELAY_S_PEAK

FL RNC + BH delay RLPpackets sampled: BE, CS,CPS, CV, LLMCS, andSMC.

SN-FMS-BTS RL_BTS_N_BH_DELAY_SUM

RL BTS + BH delayaggregate for RLP packets:BE, CS, CPS, CV, LLMCS,and SMC.

SN-FMS-BTS RL_BTS_N_BH_DELAY_TOTAL_PKTS

RL BTS + BH delay RLPpackets sampled: BE, CS,CPS, CV, LLMCS, andSMC.

SN-FMS-BTS RL_BTS_N_BH_DELAY_S_PEAK

RL BTS + BH delaysmoothed peak for RLPpackets: BE, CS, CPS, CV,LLMCS, and SMC.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


8-37


SN-FMS-TP AVG_CLK_ROOT_DISPERSION

Average clock rootdispersion

SN-FMS-TP AC_RL_TP_EF_QUE_OVLD

Number of RL reservationadmission failures due to TPEF Queue Overload

SN-HCS-ANT-CARR EVM_PCNT_RAB_SET_TO_ONE

Percentage of RAB set toone during the hour

Table 8-4 More QoS Enhancements for the HRPD Rev. A Network: ExistingService Measurements Pegged by Feature



SN-HCS-ANT-CARR AHO_PERS_SWTCH_REVA_TO_REL0

Number of PersonalitySwitches During ActiveConnections from RevA/DPA to Rel. 0.

SN-HCS-ANT-CARR CONN_SETUP_PERS_SWTCH_REL0_TO_REVA

Number of PersonalitySwitches During ConnectionSetup From Rel. 0 to RevA/DPA.

SN-HCS-ANT-CARR CONN_SETUP_PERS_SWTCH_REVA_TO_REL0

Number of PersonalitySwitches During ConnectionSetup From Rev A/DPA toRel 0

SN-HCS-ANT-CARR CONN_SETUP_PERS_SWTCH_UNKNOWN_TO_REVA

Number of PersonalitySwitches During ConnectionSetup From Unknown toRev A/DPA

Table 8-5 More QoS Enhancements for the HRPD Rev. A Network: RenamedService Measurements



SN-IEnd-FMS-OHM RESV_CLOSED_A11_SESS_UPDATE_CS

Conversational Speechreservations closed due toA11 Session Update.



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Table 8-5 More QoS Enhancements for the HRPD Rev. A Network: RenamedService Measurements (continued)

SN-IEnd-FMS-OHM RESV_CLOSED_A11_SESS_UPDATE_CV

Conversational Videoreservations closed due toA11 Session Update.

SN-IEnd-FMS-OHM RESV_CLOSED_A11_SESS_UPDATE_CPS

Push-to-Talk reservationsclosed due to A11 SessionUpdate.

SN-IEnd-FMS-OHM RESV_GRANTED_A11_SESS_UPDATE

Reservations granted by A11session update from thePDSN.

SN-IEnd-FMS-OHM RESV_NULLED_A11_SESS_UPDATE

Reservations nulled by A11session update from thePDSN.

SN-HCS-ANT-CARR SM_ENHANCED_AVG_RSSIRISE

Average Enhanced RSSI RiseOver An Hour.

SN-HCS-ANT-CARR EVM_RESV_DWNGRD_FL_CPS

Number of FL ReservationDowngraded forConversational PTT Speechreservations.

SN-HCS-ANT-CARR EVM_RESV_DWNGRD_FL_CS

Number of FL ReservationDowngraded forConversational Speechreservations.

SN-HCS-ANT-CARR EVM_RESV_DWNGRD_FL_CV

Number of FL ReservationDowngraded forConversational Videoreservations.

SN-HCS-ANT-CARR EVM_RF_IN_OVLD_FL_CS

Number of Times FL CS RFis in Overload.

SN-HCS-ANT-CARR EVM_RF_IN_OVLD_FL_CV

Number of Times FL CV RFis in Overload.

SN-HCS-ANT-CARR EVM_RF_IN_BLOCK_RL_CS

Number of Times RL RFCongestion Overload ControlCS State Machine EntersBlock State from Normal.

SN-HCS-ANT-CARR EVM_RF_IN_BLOCK_RL_CV

Number of Times RL RFCongestion Overload ControlCV State Machine EntersBlock State from Normal.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


8-39


SN-HCS-ANT-CARR EVM_RF_IN_OVLD_TOT_DUR_FL_CS

Total Duration FL CS RF IsIn Overload.

SN-HCS-ANT-CARR EVM_RF_IN_OVLD_TOT_DUR_FL_CV

Total Duration FL CV RF IsIn Overload.

SN-HCS-ANT-CARR EVM_RF_IN_BLOCK_TOT_DUR_RL_CS

Total Duration RL RFCongestion Overload ControlCS State Machine Is InBlock.

SN-HCS-ANT-CARR EVM_RF_IN_BLOCK_TOT_DUR_RL_CV

Total Duration RL RFCongestion Overload ControlCV State Machine Is InBlock.

SN-HCS-ANT-CARR AT_INIT_CONN_ATMPT_FAIL_ROR_REJECTED

AT-Initiated ConnectionAttempt Failures -ReservationOnRequestrejected.

SN-HCS-ANT-CARR RESV_DROP_PERS_SWITCH_CPS

Number of ConversationalPTT SPeech ReservationsDropped When thePersonality is switched fromRev. A/MFPA to Rev. A/DPAor Rev. 0.

SN-HCS-ANT-CARR RESV_DROP_PERS_SWITCH_CS

Number of ConversationalSpeech Reservations DroppedDue to Personality Switch.

SN-HCS-ANT-CARR RESV_DROP_PERS_SWITCH_CV

Number of ConversationalVideo Reservations DroppedDue to Personality Switch.

SN-HCS-ANT-CARR RESV_DROP_BH_OVLD_FL_CPS

Number of FL ConversationalPTT Speech ReservationsDropped due to BackhaulOverload.

SN-HCS-ANT-CARR RESV_DROP_BH_OVLD_FL_CS

Number of FL ConversationalSpeech Reservations Droppeddue to Backhaul Overload.

SN-HCS-ANT-CARR RESV_DROP_BH_OVLD_FL_CV

Number of FL ConversationalVideo Reservations Droppeddue to Backhaul Overload.



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


SN-HCS-ANT-CARR AC_RF_RES_FAILURE_FL_CPS

Number of FL reservationadmission failures forConversational PTT Speechdue to FL RF resource.

SN-HCS-ANT-CARR AC_BH_RES_FAILURE_FL_CS

Number of FL reservationadmission failures forConversational Speech due toFL Backhaul Resource.

SN-HCS-ANT-CARR AC_RF_RES_FAILURE_FL_CS

Number of FL reservationadmission failures forConversational Speech due toFL RF Resource.

SN-HCS-ANT-CARR AC_BH_RES_FAILURE_FL_CV

Number of FL reservationadmission failures forConversational Video due toFL Backhaul Resource.

SN-HCS-ANT-CARR AC_RF_RES_FAILURE_FL_CV

Number of FL reservationadmission failures forConversational Video due toFL RF Resource.

SN-HCS-ANT-CARR AC_BH_RES_FAILURE_FL_CPS

Number of FL reservationadmission failures forConversatoinal PTT Speechdue to FL BackhaulResource.

SN-HCS-ANT-CARR RESV_ADMITTED_FL_CPS

Number of FL ReservationsAdmitted for ConversationalPTT Speech.

SN-HCS-ANT-CARR RESV_ADMITTED_FL_CS

Number of FL ReservationsAdmitted for ConversationalSpeech.

SN-HCS-ANT-CARR RESV_ADMITTED_FL_CV

Number of FL ReservationsAdmitted for ConversationalVideo.

SN-HCS-ANT-CARR RESV_REQ_FL_CPS Number of FL ReservationsRequested for ConversationalPTT Speech.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


8-41


SN-HCS-ANT-CARR RESV_REQ_FL_CS Number of FL ReservationsRequested for ConversationalSpeech.

SN-HCS-ANT-CARR RESV_REQ_FL_CV Number of FL ReservationsRequested for ConversationalVideo.

SN-HCS-ANT-CARR RESV_DROP_BH_OVLD_RL_CPS

Number of RLConversational PTT SpeechReservations Dropped due toBackhaul Overload.

SN-HCS-ANT-CARR RESV_DROP_RF_OVLD_RL_CPS

Number of RLConversational PTT SpeechReservations Dropped due toRL RF Overload.

SN-HCS-CTID-EVM RESV_DROP_RF_OVLD_RL_CV

Number of RLConversational Rate VideoReservations Dropped due toRL RF Overload.

SN-HCS-ANT-CARR RESV_DROP_BH_OVLD_RL_CS

Number of RLConversational SpeechReservations Dropped due toBackhaul Overload.

SN-HCS-ANT-CARR RESV_DROP_RF_OVLD_RL_CS

Number of RLConversational SpeechReservations Dropped due toRL RF Overload.

SN-HCS-ANT-CARR RESV_DROP_BH_OVLD_RL_CV

Number of RLConversational VideoReservations Dropped due toBackhaul Overload.

SN-HCS-ANT-CARR AC_BH_RES_FAILURE_RL_CPS

Number of RL reservationadmission failures forConversational PTT Speechdue to RL BackhaulResource.

SN-HCS-ANT-CARR AC_RF_RES_FAILURE_RL_CPS

Number of RL Reservationadmission failures forConversational PTT Speechdue to RL RF Resource.



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


SN-HCS-ANT-CARR AC_BH_RES_FAILURE_RL_CS

Number of RL reservationadmission failures forConversational Speech due toRL Backhaul Resourceo.

SN-HCS-ANT-CARR AC_RF_RES_FAILURE_RL_CS

Number of RL reservationadmission failures forConversational Speech due toRL RF Resource.

SN-HCS-ANT-CARR AC_BH_RES_FAILURE_RL_CV

Number of RL reservationadmission failures forConversational Video due toRL Backhaul Resource.

SN-HCS-ANT-CARR AC_RF_RES_FAILURE_RL_CV

Number of RL reservationadmission failures forConversational Video due toRL RF Resource.

SN-HCS-ANT-CARR RESV_ADMITTED_RL_CPS

Number of RL ReservationsAdmitted for ConversationalPTT Speech.

SN-HCS-ANT-CARR RESV_ADMITTED_RL_CS

Number of RL ReservationsAdmitted for ConversationalSpeech.

SN-HCS-ANT-CARR RESV_ADMITTED_RL_CV

Number of RL ReservationsAdmitted for ConversationalVideo.

SN-HCS-ANT-CARR RESV_REQ_RL_CPS Number of RL ReservationsRequested for ConversationalPTT Speech.

SN-HCS-ANT-CARR RESV_REQ_RL_CS Number of RL ReservationsRequested for ConversationalSpeech.

SN-HCS-ANT-CARR RESV_REQ_RL_CV Number of RL ReservationsRequested for ConversationalVideo.

SN-HCS-ANT-CARR RLP_RCVD_RTC_CPS RLP Octets Received onReverse Traffic Channels forConversational PTT Speech.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


8-43


SN-HCS-ANT-CARR RLP_RCVD_RTC_CS RLP Octets Received onReverse Traffic Channels forConversational Speech.

SN-HCS-ANT-CARR RLP_RCVD_RTC_CV RLP Octets Received onReverse Traffic Channels forConversational Video.

SN-HCS-ANT-CARR RL_LOLAT_PKTS_MISSED_TARGET

Total number of RL loLatPackets Missed TerminationTarget.

SN-FMS-TP RL_LOLAT_PKTS_RCVD

Total number of RL loLatPackets Received at TP..

SN-FMS-TP EF_PKTS_DROP_EF_QUE_OVLD

Number of EF PacketsDropped from EF Queue Dueto EF Queue Full.

SN-FMS-TP TP_AC_FAILURE_EF_QUE_OVLD

TP Admission evaluationfailure due to TP EF QueueOverload.


These new service measurements are related to Data Over Signaling Protocol (FID12078.12).

The Data Over Signaling Protocol (FID 12078.12) feature affects the servicemeasurements that are identified inTable 8-6, “Data Over Signaling Protocol Feature:New Service Measurements” (p. 8-44)

Table 8-6 Data Over Signaling Protocol Feature: New Service Measurements



SECT-CARR-HDRC MO_DOS_BE Mobile Originated DoS BEMessages Received

SECT-CARR-HDRC MO_DOS_CMCS Mobile Originated DoSCMCS Messages Received

SECT-CARR-HDRC MO_DOS_LL_MCS Mobile Originated DoSLL_MCS MessagesReceived



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


The 1xEV-DO Basic PTT Using 1xEV-DO Rev. A Network feature affects thefollowing categories of services measurements:

• RNC sector carrier short interval counts

• HCS sector carrier short interval counts

• HDR sector carrier short interval counts

RNC sector carrier service measurements

The DOrA Application QoS Features feature affects the RNC sector carrier servicemeasurements that are identified inTable 8-7, “RNC sector carrier servicemeasurements” (p. 8-45).

Table 8-7 RNC sector carrier service measurements


Countabbreviation Count name

CG RNC-PGPROFID PAGE_REQ_DROPPED_AP_OVLD

Number of FL ReservationDowngraded for ConversationalPTT Speech reservations

HCS sector carrier service measurements

The DOrA Application QoS Features feature affects the HCS sector carrier servicemeasurements that are identified inTable 8-8, “HCS sector carrier servicemeasurements” (p. 8-45).

Table 8-8 HCS sector carrier service measurements



SECT-CARR-HCS EVM_NUM_FL_RESERVATION_DOWNGRADED_CPS

AN-Initiated ConnectionRequests for Predictive FlowAdmission



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


8-45

HDR sector carrier service measurements

The DOrA Application QoS Features feature affects the HDR sector carrier servicemeasurements that are identified inTable 8-9, “HDR sector carrier servicemeasurements” (p. 8-46).

Table 8-9 HDR sector carrier service measurements



SECT-CARR-HDRC CONV_PTT_SPCH_RESV_DRPD_PER_SWITCH_MFPA_DPA_R0

Number of Conversational PTTSpeech Reservations DroppedWhen the Personality isswitched from Rev A/MFPA toRev A/DPA or Rev 0

SECT-CARR-HDRC FL_RESV_ADMT_CONV_PTT_SPEECH

Number of FL ReservationsAdmitted for ConversationalPTT Speech

SECT-CARR-HDRC FL_RESV_ADMT_FAIL_CONV_PTT_SPCH_FL_BKHAUL_RES

Number of FL reservationadmission failures forConversational PTT Speech dueto FL Backhaul Resource

SECT-CARR-HDRC FL_RESV_ADMT_FAIL_CONV_PTT_SPCH_FL_RF_RES

Number of FL reservationadmission failures forConversational PTT Speech dueto FL RF resource

SECT-CARR-HDRC FL_RESV_DRPD_CONV_PTT_SPCH_BKHAUL_OVL

Number of FL ConversationalPTT Speech ReservationsDropped due to BackhaulOverload

SECT-CARR-HDRC FL_RESV_REQ_CONV_PTT_SPEECH

Number of FL ReservationsRequested for ConversationalPTT Speech

SECT-CARR-HDRC RLP_OCT_RX_RTC_CONV_PTT_SPCH_CPS

RLP Octets Received onReverse Traffic Channels forConversational PTT Speech(CPS)

SECT-CARR-HDRC RL_RESV_ADMT_CONV_PTT_SPEECH

Number of RL ReservationsAdmitted for ConversationalPTT Speech



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Table 8-9 HDR sector carrier service measurements (continued)



SECT-CARR-HDRC RL_RESV_ADMT_FAIL_CONV_PTT_SPCH_RL_BKHAUL_RES

Number of RL reservationadmission failures forConversational PTT Speech dueto RL Backhaul Resource

SECT-CARR-HDRC RL_RESV_ADMT_FAIL_CONV_PTT_SPCH_RL_RF_RES

Number of RL Reservationadmission failures forConversational PTT Speech dueto RL RF Resource

SECT-CARR-HDRC RL_RESV_DRPD_CONV_PTT_SPCH_BKHAUL_OVL

Number of RL ConversationalPTT Speech ReservationsDropped due to BackhaulOverload

SECT-CARR-HDRC RL_RESV_DRPD_CONV_PTT_SPCH_RL_RF_OVL

Number of RL ConversationalPTT Speech ReservationsDropped due to RL RF Overload

SECT-CARR-HDRC RL_RESV_DRPD_CONV_PTT_SPCH_TP_EF_Q_OVL

Number of RL ConversationalPTT Speech ReservationsDropped due to TP EF QueueOverload

SECT-CARR-HDRC RL_RESV_REQ_CONV_PTT_SPEECH

Number of RL ReservationsRequested for ConversationalPTT Speech

HRPD PTT Paging Enhancements (FID 12184.5)

The HRPD PTT Paging Enhancements feature affects the following categories ofservices measurements:

• Overhead Manager (OHM)-PageableProfileID counts

• Overhead Manager (OHM)-PageableProfileID-PageAttempt counts



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


8-47

OHM-PageableProfileID service measurements

The HRPD PTT Paging Enhancements feature modify these existing the OHM-ProfileID service measurements introduced by DOrA Application QoS Features identified inTable 8-10, “OHM-PageableProfileID service measurements” (p. 8-48).

Table 8-10 OHM-PageableProfileID service measurements



OHM-PGPROFID PAGE_ABORT_HIGHER_PID

Page Aborts Due to HigherPriority ProfileID Override

OHM-PGPROFID PAGE_ESC Paging Escalations

OHM-PageableProfileID-PageAttempt service measurements

The HRPD PTT Paging Enhancements feature modify these existing the OHM-ProfileID service measurements introduced by DOrA Application QoS Features identified inTable 8-11, “OHM-PageableProfileID-PageAttempt service measurements” (p. 8-48).

Table 8-11 OHM-PageableProfileID-PageAttempt service measurements



OHM-PGPROFID-PGAT PAGES Pages

OHM-PGPROFID-PGAT PAGE_CR_RCVD Connection Requests Received


The PTT Enhancements feature affects the following categories of servicesmeasurements:

• Overhead Manager (OHM)-PageableProfileID counts

• Overhead Manager (OHM)-PageableProfileID-PageAttempt counts

• RNC pgpf counts



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

OHM-PageableProfileID service measurements

The HRPD PTT Paging Enhancements feature adds new counts to theOHM-PageableProfileID service measurements introduced by DOrA Application QoSFeatures are identified inTable 8-12, “OHM-PageableProfileID service measurements”(p. 8-49).

Table 8-12 OHM-PageableProfileID service measurements



OHM-PGPROFID PAGE_DE_ESC Paging De-Escalations

OHM-PGPROFID PAGE_DE_ESC_RESP

Paging De-Escalation Responses

OHM-PGPROFID PAGE_ESC_RESP Paging Escalation Responses

OHM-PageableProfileID-PageAttempt service measurements

The HRPD PTT Paging Enhancements feature modifies this new and existing counts inthe OHM-PageableProfileID-PageAttempt service measurements introduced by DOrAApplication QoS Features are identified inTable 8-13, “OHM-PageableProfileID-PageAttempt service measurements” (p. 8-49).

Table 8-13 OHM-PageableProfileID-PageAttempt service measurements



Existing Count

OHM-PGPROFID-PGAT PAGE_ESC Paging Escalations

New Count

OHM-PGPROFID-PGAT PAGE_SECTORS Page Sectors

RNC-pgpf service measurements

The HRPD PTT Paging Enhancements feature adds new counts to the RNC-pgpfservice measurements introduced by DOrA Application QoS Features identified inTable 8-14, “RNC-pgpf service measurements” (p. 8-49).

Table 8-14 RNC-pgpf service measurements



SN-RNC-pgpf RNC_GROUP_ID RNC Group ID



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


8-49

References


• CDMA2000® 1xEV-DO Network Service Measurements,401-614-326



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Introduction

The features described in this document are subject to the following special issuesand/or caveats.

Caveats

The PTT features will be delivered in several phases. The 1xEV-DO Basic PTT Using1xEV-DO Rev. A Network (FID 12184.1), is the first feature available. It is using theMultiflow Packet Application without header compression in order to work with thefirst HRPD Rev. A ATs. The 1xEV-DO Basic PTT Using 1xEV-DO Rev. A Network(FID 12184.1) feature integration with different PTT servers will be done based oncustomer demands/configurations.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


8-51


Process

This procedure activates the DOrA Application QoS Features and related features in aCDMA2000® 1xEV-DO Network.

For detailed procedure, see 401-614-101, CDMA2000® 1xEV-DO Network RadioAccess System.

Implementing the DOrA Application QoS Features

The PTT features are optional features controlled by PTT FAF on Service Node basis.The 1xEV-DO Basic PTT Using 1xEV-DO Rev. A Network (FID 12184.1) iscontrolled by the PTT FAF per Service Node basis. The PTT FAF can be activatedonly if the Enhanced HRPD Rev. A bundle FAF is activated.

These DOrA Application QoS Features are required for PTT:


• RAN Quality of Service Enhancements for HRPD Rev A (FID 12078.10)

• More Quality of Service (QoS) Enhancements for the High Rate Packet Data(HRPD) Revision A (Rev. A) Network (FID 12078.11)

• Data over Signaling Protocol (FID 12078.12)


• 1xEV-DO Basic Push-To-Talk (PTT) Using 1xEV-DO Rev. A Network (FID12184.1)

• High Rate Packet Data (HRPD) Push-to-Talk (PTT) Paging Enhancements (FID12184.5)

• Push-to-Talk (PTT) Enhancements (FID 12184.7)


In addition to FAF control the operator will have the ability to turn the featureON/OFFon Service Node basis.




...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008







Implementing the features

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


8-53


Purpose

Activation of the DOrA Application QoS Features depends on the 1xEV-DO Basic Rev.A Feature Bundle, this means the 1xEV-DO Basic Rev. A Feature Bundle needs to beactivated before the activation of the DOrA Application QoS Features. In other words,the DOrA Application QoS Features depend on the 1xEV-DO Basic Rev. A FeatureBundle.

All the DOrA Application QoS Features are enabled by the DOrA ApplicationLicenses. The FAF entries for all of these features are now enabled in all customersFeature Activation Files (FAF). FAFs are not used to manage ANY of these features.The only FAF legacy situation exists is that the 12078.x series of FIDs has a singleFAF entry, while the 12184.x FIDs have separate entries. However, it is not themechanism to turn on these features - the DOrA Application Licenses are themechanism.


Procedure


...................................................................................................................................................................................................

1 Ensure the correct FAF entry is activated.

Ask your account executive to activate the following entry in your Feature ActivationFile (FAF):

• FAF entry for FID 12078.9 and FID 12078.10 is1xEV-DO Application based Quality of Service (QoS) support for HRPDRevA (QOS_REVA). SeeStep 3.

• FAF entry for FID 12078.11 is1xEV-DO Application based Quality of Service (QoS) support for HRPDRevA (QOS_REVA). SeeStep 4.

• FAF entry for FID 12078.12 is1xEV-DO Application based Quality of Service (QoS) support for HRPDRevA (QOS_REVA). SeeStep 5.

• Important! The Enhanced Idle State Protocol (FID 12078.13) feature shares thesame FAF with FIDs 12078.9, 12078.10, and 12078.12 yet is not included in theDOrA Application QoS Features application license applied features. To enabe FID12078.13, seeStep 6.

• FAF entry for FID 12184.1 is1xEV-DO Basic PTT using 1xEV-DO RevA Networks. SeeStep 7.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

• FAF entry for FID 12184.5 isHRPD PTT Paging Enhancement (1xEV-DO RevA).The FAF entry for FID 12184.5 requires the FAF entry for 1xEV-DO RNCGrouping Infrastructure FID 12456.1. SeeStep 9.

• There is no separate FAF entry for FID 12184.7. It uses the FID 12184.5 FAFentry HRPD PTT Paging Enhancement (1xEV-DO RevA). SeeStep 10.

• FAF entry for FID 12078.36 isHRPD PTT Paging Enhancement (1xEV-DO RevA).SeeStep 11.

...................................................................................................................................................................................................

2 Go to EMS GUI Configuration Data Page and provision the required translations forthe corresponding feature.

...................................................................................................................................................................................................

3 For Application Based Quality of Service (QoS) Support for HRPD Rev. A (FID12078.9) and RAN Quality of Service Enhancements for HRPD Rev A (FID12078.10):

1. From EMSConfiguration Data Page , click on Service Nodes .

2. Click onService Node ID to provision, then click onGeneral Section 3 fromthe scroll box.

3. From theGeneral Service Node Attributes - section 3 page, setPer ApplicationQOS feature Enable field to Enabled.

4. Click onSubmit at the bottom of the page.

...................................................................................................................................................................................................

4 For More Quality of Service (QoS) Enhancements for the High Rate Packet Data(HRPD) Revision A (Rev. A) Network (FID 12078.11):

1. No new translations are required if FIDs 12078.9 and 12078.10 inStep 3arealready provisioned.

...................................................................................................................................................................................................

5 For Data over Signaling Protocol (FID 12078.12):

1. From EMS GUIConfiguration Data Page , click on Service Nodes .

2. Click on theService Node ID to provision, then click onGeneral Section 1 fromthe scroll box.

3. From theGeneral Service Node Attributes - section 1 Page, setData OverSignaling Enable field to Yes.

4. Go back to EMS GUI Configuration Data Page, click onService Categories .

5. Click on Best Effort from the Service Categories Page.

6. Click on General from the scroll box.

7. SetAT originated DoS Message filed to Yes.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


8-55

8. Click on Submit at the bottom of the page.

9. Go back to Service Categories Page, repeat above sub-steps5 through8 to setAToriginated DoS Message filed to Yes for each of the following service categories:Signaling Media Control , Conversational PTT Speech andLow Latency MediaControl Signaling

...................................................................................................................................................................................................

6 Important! The Enhanced Idle State Protocol (FID 12078.13) shares the same FAFwith FIDs 12078.9, 12078.10, and 12078.12 yet it is not included in the 1xEV-DORev. A QoS application license applied features:

To enable Enhanced Idle State Protocol (FID 12078.13), proceed with the following:

1. Ensure the FAF entry of1xEV-DO Application based Quality of Service (QoS) support for HRPDRevA (QOS_REVA) is activated.


3. Click on theService Node ID to provision, then click onEnhanced Idle StateProtocol from the scroll box.

4. From theEnhanced Idle State Protocol Page , setEnhanced Idle State ProtocolEnabled field to Yes.


...................................................................................................................................................................................................

7 For 1xEV-DO Basic Push-To-Talk (PTT) Using 1xEV-DO Rev. A Network (FID12184.1):



3. From theGeneral Service Node Attributes - section 1 Page, setBasic PTT1xEV-DO Rev A Network Enable field to Yes.

4. AccessProfile ID view underConfiguration Data page, then go toGeneral andverify that appropriateProfile ID is Enabled

• PTT CallSetup Signaling

• PTT InCall Signaling

• PTT Speech Bearer1


5. Go to theProfileID Paging Strategy Attribute s page and verify theQoS ProfileID Value is the appropriate value. Repeat this step for eachProfileID in 4.

6. PopulateUse QoS Page Strategy to y



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

7. ConfigurePaging Areas on theProfileID Paging Strategy Attributes page withappropriate values.The choices for QoS Paging areas:

• Two basic paging areas:Last_Active_Set andLast_Seen_RNC

• Need to enable FID 12184.5 (Step 9) for enhanced paging areas:Neighbor_RNCandRNC_Group

• Need to enable FID 12184.7 (Step 10) for distance based paging areas:Distance_Tier0, Distance_Tier1, Distance_Tier2, Distance_Tier3

...................................................................................................................................................................................................

8 Important! RNC group is not present when RNC grouping FID is not turned on.

For 1xEV-DO Basic Push-To-Talk (PTT) Using 1xEV-DO Rev. A Network (FID12184.1), the optionally configure the QoS Paging Strategy per RNC Group:

1. From EMS GUIConfiguration Data Page , click on RNC Group Profile IDs .

2. Click onPTT CallSetUp Signaling for RNC Group ID .

3. Click onPaging Strategy General from the scroll box.

4. Set theUse QoS Page Strategy field to Yes.

5. Click onRNC Group QoS Paging Override field to Yes.


7. Click onPaging Strategy General from the scroll box.

8. Specify the DOS method and paging area for each attempt. For a list of validcombinations for DoS method and paging area settings, seeTable 8-15, “ValidCombinations for DoS Method and Paging Area Settings” (p. 8-61).If no DOS method is set, set the paging area field to any of the values listed inTable 8-15, “Valid Combinations for DoS Method and Paging Area Settings”(p. 8-61).The choices for QoS Paging areas:





10. Go back to theRNC Group Profile IDs page.

11. Repeat sub-steps2 through10 for each of the followingProfile IDs .

• PTT InCall Signaling





...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


8-57

Important! The 1xEV-DO RNC Groups that include RNCs from different servicenodes should use the same settings for QoS Paging parameters in theProfile ID orRNC Group Profile ID views. No cross-checking between service nodes is performed,but if the settings are different, unexpected results can occur.

Important! Distance Tiers should not be selected for QoS Paging Areas until all theRNCs in an RNC Group have been upgraded to R29.0 or a later load. The operation ofdistance-based paging may result in unexpected behavior when an RNC in an RNCGroup is not running 1xEV-DO R29.0 or a later RNC load.

...................................................................................................................................................................................................

9 Important! The FAF entry for FID 12184.5 requires the FAF entry for 1xEV-DORNC Grouping Infrastructure FID 12456.1. FID 12184.5 is a dependant feature ofFID 12456.1.

For High Rate Packet Data (HRPD) Push-to-Talk (PTT) Paging Enhancements (FID12184.5):

1. From EMS GUIConfiguration Data Page , click on Service Nodes II .

2. Click on theService Node ID to provision, then click onGeneral from the scrollbox.

3. From theService Nodes II General Page , setPaging Enhancements Enablefield to Yes.


...................................................................................................................................................................................................

10 Important! There is no separate FAF entry for FID 12184.7. It uses the FID12184.5 FAF entryHRPD PTT Paging Enhancement (1xEV-DO RevA).

For Push-to-Talk (PTT) Enhancements (FID 12184.7):

1. From EMS GUIConfiguration Data Page , click on Service Nodes II .

2. Click on theService Node ID to provision, then click onGeneral from the scrollbox.

3. From theGeneral Page , setDistance Paging Enable field to Yes. Withdistance-based paging, a page is sent to all sectors within a radius of the last seensector. The distance between sectors is calculated from the provisioned Latitudeand/or Longitude of each sector. Only cells in RNCs in the same RNC group as thesession controlling RNC are paged. The paging radius is configureable.

4. Provision Distance_Tier0 settings :Distance_Tier0 is based on the setting of theRadius for Registration Updateparameter. Provision this parameter at theService Node level or at theSectorLevel .



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

When theRadius for Registration Update parameter is set with a value at thesector level, it overrides the setting at the service node level.

• At the Service Node level, from theConfiguration Data Page , click ServiceNodes . Select the ID to provision and then clickGeneral Section 1 .

• At the sector level, from theConfiguration Data Page , click Sectors . Specifyvalues forBTS ID, Sector ID , Service Node ID andFMS Frame ID to filter forthe desired sector IDs. Select theSector ID to provision, and then clickGeneral .

5. Provision Distance_Tier1, Distance_Tier2, and Distance_Tier3 settings

The following caveats should be noted:

• Do not turn on distance based paging unless all sectors have been correctlyprovisioned with their latitude and longitude (in the sector view). Otherwise,paging to sectors with incorrect positions may be affected.

• For compatibility with geolocation services, it is recommend that latitude andlongitude be based on the World Geodetic Survey 1984 (WGS-84).

• When entering the sizes of distance tiers, note that these are 2D distances basedon the equation from TIA-856-A-2 8.7.6.1.5.4 Route Update Report Rules. Thisis NOT a 3D distance that includes the curvature of the earth.

• If more than 250 pageable entities (cells or sectors with unique position) arewithin the radius provisioned for a distance based tier, only the closest 250pageable entities will actually be paged.

Distance_Tier1, Distance_Tier2, andDistance_Tier3 values are based on thesettings of theSize of Distance Paging Tier1,Size of Distance Paging Tier2, andSize of Distance Paging Tier3parameters, respectively. These parameters can be set at theService Node , BTS,andSectorLevels .

• At the Service Node level, from theConfiguration Data Page , click ServiceNode II . Select the ID to provision and then clickGeneral .

• At the BTS level, from theConfiguration Data Page , click BTSs . Specifyvalues forBTS ID, Service Node ID andFMS Frame ID to filter for thedesired sector IDs. Select theBTS ID to provision, and then clickGeneralSection 1 .

• At the Sector level, from theConfiguration Data Page , click Sectors .Specify values forBTS ID, Service Node ID andFMS Frame ID to filter forthe desired sector IDs. Select theSector ID to provision, and then clickGeneral .

The settings of these parameter take precedence in the following order:

a. settings in theSector page

b. settings in theBTS page

c. settings in theService Node page



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


8-59

Important! The 1xEV-DO RNC Groups that include RNCs from different servicenodes should use the same setting for theDistance Paging Enable field. Nocross-checking between service nodes is performed, but if the settings are different,unexpected results can occur.

...................................................................................................................................................................................................

11 For 1xEV-DO Revision A (Rev. A): Data Over Signaling Protocol - FL (FID12078.36):



3. From theGeneral Service Node Attributes - section 1 Page, setData OverSignaling Enable field to Yes.

4. Go back to EMS GUIConfiguration Data Page , click on Profile IDs .

5. Click onPTT CallSetup Signaling from theProfile IDs Page.

6. Click onData Over Signaling from the scroll box.

7. SetFirst DSCP marking for DoS request to useDoS .


9. Return to theProfile IDs screen.

10. Click onPaging Strategy Areas .

11. SetDoS Method For First Attempt to Direct_DOS , Mixed_DOS , or RUR_DOS.Specify the DOS method and paging area for each attempt. Set theDoS MethodFor First Attempt field to Direct_DOS , Mixed_DOS , or RUR_DOS, then specify avalue for thePaging Area For First Attempt field. For a list of valid combinationsfor DoS method and paging area settings, seeTable 8-15, “Valid Combinations forDoS Method and Paging Area Settings” (p. 8-61).If no DOS method is set, set the paging area field to any of the values listed inTable 8-15, “Valid Combinations for DoS Method and Paging Area Settings”(p. 8-61).

12. Click onSubmit at the bottom of the page.

13. Repeat sub-steps10 through12 to configure settings for additional attempts;configure up to eight attempts.

14. Go back toProfile ID Page, and repeat above sub-steps5 through12 to set ATterminated DoS for each of the followingProfile IDs : Best Effort , PTT call SetupSignalling , PTT InCall Signalling , PTT speech Bearer1 andPTT Speech Bearer2.



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

E N D O F S T E P S...................................................................................................................................................................................................

DoS Method and Paging Area Settings

The Table 8-15, “Valid Combinations for DoS Method and Paging Area Settings”(p. 8-61)lists the valid combinations of DoS Method and Paging Area settings. Validcombinations are indicated by an “X”.

The choices for QoS Paging areas:




Table 8-15 Valid Combinations for DoS Method and Paging Area Settings

Paging Area Setting DoS Method setting

Null Direct_DoS

Mixed_DoS

RUR-DoS

Basic Paging Areas

Last_Active_Set X X

Last_Seen_RNC X X X

Enhanced Paging Areas

Neighbor_RNC1 X

RNC_Group1 X

Distance Paging Areas

Distance_Tier02 X X X X




1. SpecifyNeighbor_RNC or RNC_Group only when FID12184.5 isenabled.

2. SpecifyDistance_Tier# only when FID 12184.7 isenabled.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


8-61

9 9CDMA 3G-1x EVolution DataOptimized (1xEV-DO) Backhaulw/Multi Link Point-to-PointProtocol at Layer 2 Over T1/E1

Overview...................................................................................................................................................................................................................................

Purpose

This optional feature description describes the CDMA 3G-1x EVolution DataOptimized (1xEV-DO) Backhaul with Multi Link Point-to-Point Protocol (MLPPP) atLayer 2 Over T1/E1 optional feature inCDMA® 1xEV-DO networks.

Feature summary

The current data only (DO) backhaul over T1 uses Cisco HDLC (cHDLC) as layer 2protocol. The EVolution Data Optimized (1xEV-DO) Backhaul with Multi LinkPoint-to-Point Protocol (MLPPP) at Layer 2 Over T1/E feature replaces the cHDLCwith Multi Link Point-to-Point Protocol (MLPPP) as layer 2 protocol. Backhaul trafficload-balance and Quality of Service (QoS) will be handled under MLPPP extensionprotocol, which is IETF standard. The MLPPP protocol has been developed 3rdGeneration CDMA Internet Protocol Backhaul (3G1X IPBH) under program so that theDO will reuse the developed protocol from the Base Transceiver Station (BTS). Edgerouter in the DO backhaul should also support the MLPPP protocol.


A unique Feature Identifier (FID) is assigned to each feature. The FID of the CDMA3G-1x EVolution Data Optimized (1xEV-DO) Backhaul with Multi Link Point-to-PointProtocol (MLPPP) at Layer 2 Over T1/E1 feature is FID 12304.11.

....................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


9-1


The CDMA 3G-1x EVolution Data Optimized (1xEV-DO) Backhaul with Multi LinkPoint-to-Point Protocol (MLPPP) at Layer 2 Over T1/E1 affects the user interfaces thatare listed in the following table.


Element Management System (EMS) (orOMC-RAN)

See“Element Management System (EMS)configuration management” (p. 9-10).

Service measurements See“Impacts on service measurements”(p. 9-11).


None


None

Intended audience

This document is intended for technicians, engineers, and system administrators whoimplement or maintain the 1xEV-DO Backhaul with MLPPP at Layer 2 Over T1/E1feature in aCDMA2000® 1xEV-DO network.



Contents

Availability 9-4

Prerequisites 9-5



Element Management System (EMS) configuration management 9-10





CDMA 3G-1x EVolution Data Optimized (1xEV-DO)Backhaul w/Multi Link Point-to-Point Protocol at Layer 2Over T1/E1

Overview

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Provisioning cell2 RC/V form 9-15


Overview

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


9-3

Availability...................................................................................................................................................................................................................................


The 1xEV-DO Backhaul with MLPPP at Layer 2 Over T1/E1 feature is available inECP Releases 28.0 and later.

Market availability

The 1xEV-DO Backhaul with MLPPP at Layer 2 Over T1/E1 feature is available in theNorth American Region (NAR) market only.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Prerequisites...................................................................................................................................................................................................................................

Introduction

The 1xEV-DO Backhaul with MLPPP at Layer 2 Over T1/E1 feature has the followingprerequisites.


The 1xEV-DO Backhaul with MLPPP at Layer 2 Over T1/E1 feature is supported inthe following air-interface technologies:

• CDMA cellular

• CDMA PCS


The 1xEV-DO Backhaul with MLPPP at Layer 2 Over T1/E1 feature requires ECPRelease 28.0 or later. The 1xEV-DO Backhaul with MLPPP at Layer 2 Over T1/E1feature is not dependent on other features.


The 1xEV-DO Backhaul with MLPPP at Layer 2 Over T1/E1 feature requires the edgerouter supporting MLPPP/Multi Carrier (MC) protocol instead of HDLC. As networkcontrol protocol, Dynamic Host Configuration Protocol (DHCP) will continuesupporting to assign BTS IP address.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


9-5


Introduction

The following information describes the functionality, benefits, and operation of theCDMA 3G-1x EVolution Data Optimized (1xEV-DO) Backhaul with Multi LinkPoint-to-Point Protocol (MLPPP) at Layer 2 Over T1/E1 feature.

Functionality

The CDMA 3G-1x EVolution Data Optimized (1xEV-DO) Backhaul with Multi LinkPoint-to-Point Protocol (MLPPP) at Layer 2 Over T1/E1 feature replaces the cHDLCwith Multi Link Point-toPoint Protocol (MLPPP) as layer 2 protocol. Backhaul trafficload-balance and Quality of Service (QoS) will be handled under MLPPP extensionprotocol, which is IETF standard.


Since the current Edge router is configured as cHDLC in layer 2 protocol, the CDMA3G-1x EVolution Data Optimized (1xEV-DO) Backhaul with Multi Link Point-to-PointProtocol (MLPPP) at Layer 2 Over T1/E1 feature allows it to be reconfigured withMLPPP. A significant difference from the cHDLC based backhaul is that one IPaddress is assigned to a Multi-Link bundling multiple T1s. The current backhaul overcHDLC link assigns IP address per T1 link. The MLPPP will provide equivalent oradditional functions to the current cHDLC protocol as follows:

• Link continuity verification: MLPPP provides Link Control Protocol (LCP)message as L2HB

• Traffic Load balance within the MLG: MLPPP backhaul also provides the trafficload balance across T1s within the same Multi-Link Group (MLG) over ForwardLink as well as Reverse Link.

As illustrated inFigure 9-1, “EVDO Network Configuration Diagram with a MLPPP”(p. 9-7), the EVDO backhaul will require reconfiguration in the backhaul networkincluding BTS, Data Only Radio Network Controller (DO RNC) and the aggregationrouters.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

As part of reconfiguration at the BTS, the following are required:

• MLG configuration: All T1s at the same Universal Radio Controller (URC) mustbe provisioned into the same MLG. Multi-Router Automatic Protection Switching(MR-APS) should be supported to perform the MLG switch-over in case of routerfailure. Under the 1xEV-DO Backhaul with MLPPP at Layer 2 Over T1/E1 feature,EVDO backhaul supports single MLG configurations only.

• IP Address provisioning at the Aggregation Router: As part of MLPPPconnection setup procedure, BTS will receive the IP address via IPCP. Theaggregation router should provision the IP address pool that will be used for the IPaddress allocation to the BTS. In order to support for the MR-APS, bothaggregation routers should maintain the same IP address pool

• QoS parameters configuration based on DiffServ: DiffServ is the QoS protocolused in EVDO backhaul. Since the MLPPP will bundle multiple T1s QoSparameters should be reconfigured based on MLG.

When the layer 2 protocol of EVDO Rev. A backhaul is converted from cHDLC toMLPPP, base station and edge router should be reconfigured to support MLPPP.Protocol conversion from cHDLC to MLPPP will be completed without the cellsitevisit. According to the transport network design, T1 lines may need to bere-provisioned into the same multilink. URC will be rebooted as part of the protocolconversion.

Figure 9-1 EVDO Network Configuration Diagram with a MLPPP


Feature description

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


9-7

The EVDO cell will use IPCP to receive the basic IP addresses including BTS IPaddress. When the MLPPP connection is established, it will receive further informationfor the operation from the DHCP server. In addition, upon the increase of linkbandwidth assigned on an IP address, backhaul transport QoS parameters and trafficengineering might be reconfigured at BTS, RNC and Edge router.

Since MLPPP uses different type of backhaul continuity verification methods definedas part of standard (RFC-1661), instead of SLARP message under cHDLC protocol,Link Control Protocol (LCP) Echo request and response messages are periodicallyexchanged between the BTS and the Edge router. MLPPP also provides a new alarmupon the loss of the whole MLG member links.

Loss of each T1 link will not turn on the alarm in MLPPP if there is at least anotherT1 operating. All existing Service Measurement will continue to be supported overMLPPP.


The 1xEV-DO Backhaul with MLPPP at Layer 2 Over T1/E1 feature allows theprotocol conversion from cHDLC to MLPPP, or from MLPPP to cHDLC completiondoes not require a cellsite visit.


Feature description

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Introduction

The 1xEV-DO Backhaul with MLPPP at Layer 2 Over T1/E1 feature does not interactwith other features.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


9-9

Element Management System (EMS) configuration management...................................................................................................................................................................................................................................

Configuration management pages

The 1xEV-DO Backhaul with MLPPP at Layer 2 Over T1/E1 feature affects the RecentChange and Verify (RC/V) forms that are listed inTable 9-1, “Related RC/V forms”(p. 9-10).

Table 9-1 Related RC/V forms

Form abbreviation Form name

SERIES 2 CELL cell2

cell2 page

The cell2 form is used. The 1xEV-DO Backhaul with MLPPP at Layer 2 Over T1/E1feature uses a new fields in thecell2 form, as shown inTable 9-2, “Related fields inthe cell2 page” (p. 9-10).

Table 9-2 Related fields in the cell2 page

Parameter name Description Allowedvalues

MP Enabled This parameter is used to indicate whetherMP is used layer 2 protocol on thebackhaul of the cell.

y or n

Default = n

References

For more information about these RC/V forms and fields, see the followingCDMA2000® wireless networks documents:

• Database Update Manual,401-610-036

• Text Recent Change and Verify (RC/V) Reference,401-610-038


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Introduction

The 1xEV-DO Backhaul with MLPPP at Layer 2 Over T1/E1 feature affects thefollowing categories of services measurements:

• Data link counts

Data link counts

The 1xEV-DO Backhaul with MLPPP at Layer 2 Over T1/E1 feature affects the1xEV-DO service measurements that are identified inTable 9-3, “1xEV-DO servicemeasurements - Data link counts” (p. 9-11).

Table 9-3 1xEV-DO service measurements - Data link counts


DL_UPLINK_AVG_THRUPUT Datalink Uplink with Average Throughput

DL_UPLINK_PEAK_THRUPUT Datalink Uplink with Peak Throughput

DL_DOWNLINK_AVG_THRUPUT Datalink Downlink with AverageThroughput

DL_DOWNLINK_PEAK_THRUPUT Datalink Downlink with Peak Throughput

References

For detailed information about 1xEV-DO service measurements, see CDMA2000®

1xEV-DO Service Measurements,, 401-614-326.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


9-11


Introduction

The 1xEV-DO Backhaul with MLPPP at Layer 2 Over T1/E1 feature is subject to thefollowing special issues and/or caveats.

Caveats

Mixture configuration of EVDO Revision 0 (Rev. 0) and Revision A (Rev. A) issupported over a single MLPPP protocol in either a single URC or multiple URCsconfiguration. Mixture of 3G1X and EVDO allows different L2 protocols (for example,FR PP and MLPPP).

The 3G1X IP BH uses IPCP as NCP under MLPPP/MC as layer 2 protocol. SinceEVDO has been used the DHCP as NCP and is used in Ethernet backhaul, EVDOcontinues to use DHCP as NCP in addition to IPCP. The following is a typical scenarioregarding IP address assignment: When the EVDO URC boots, it will initially get theIP address via IPCP, and connect to the BSSA. To get these addresses, it sends aDHCP request. The response provides these addresses, including the address of theBSSA.

The LU-EVDO-MLPPP continues to support only Shared Signaling. This means that IPSignaling continues to be a non-supported setup, even after the change to MLPPP.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Overview

To implement the 1xEV-DO Backhaul with MLPPP at Layer 2 Over T1/E1 feature,perform the following procedures in sequence:

“Implementing the feature” (p. 9-13)

“Provisioning cell2 RC/V form” (p. 9-15)


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


9-13


Purpose

This 1xEV-DO Backhaul with MLPPP at Layer 2 Over T1/E1 feature is a standardfeature that is not controlled by Feature Activation File/Quality Feature Activation File(FAF/QFAF). In order to enable this feature per cell site, the customer should provisionthe RC/V form for a particular cell site.

For details on DOMLPPP conversion, seeCDMA Wireless Networks BTS Conversionfrom HDLC to ML-PPP over T1/E1,401-710-104.



Procedure


...................................................................................................................................................................................................

1 Proceed to“Provisioning cell2 RC/V form” (p. 9-15).

E N D O F S T E P S...................................................................................................................................................................................................


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Provisioning cell2 RC/V form...................................................................................................................................................................................................................................

Purpose

This procedure provisions the RC/Vcell2 form for the 1xEV-DO Backhaul withMLPPP at Layer 2 Over T1/E1 feature.

Fields to populate

The fields that you must populate in thecell2 form are described inTable 9-4,“Fields to be populated in the cell2 form” (p. 9-15).

Table 9-4 Fields to be populated in the cell2 form

Field nameText RC/Vname

Value tobeentered Restrictions

MP Enabled mp_enabled y or n

Default =n

When updating thisfield, a warningmessage will populate:MP Enabled is anon-updatableparameter. Any changemust be followed by astable clear. It willaffect service.

Steps


...................................................................................................................................................................................................

1 Launch the RC/Vcell2 form.

...................................................................................................................................................................................................

2 Advance to the screen that contains theMP Enabled field.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


9-15

Result: The cell2 form is displayed, as shown in the following example. In thisexample, fields that relate to the 1xEV-DO Backhaul with MLPPP at Layer 2 OverT1/E1 feature are in italics inFigure 9-2, “RC/V form cell2” (p. 9-16).

...................................................................................................................................................................................................

3 In the MP Enabled field, enter

n

E N D O F S T E P S...................................................................................................................................................................................................

Figure 9-2 RC/V form cell2

FLEXENTWireless SERIES 2 CELL (cell2) Screen 35 of 38Networks Cell ___

IP/Ethernet Backhaul InformationEthernet Backhaul Enabled...........................@488) n

IP Backhaul Enabled.................................@489) nBackhaul Offload.....................................490) n

Prim AltRNC Number..............................491) __ 496) __RNC Backhaul Server Number..............492) _ 497) _Switching Module Number (SM)............493) ___ 498) ___Packet Switching Unit Number (PSU)......494) _ 499) _DCS Backhaul Server Number..............495) __ 500) __

MLG Loading Bias Translation (BIASMLG)...............501) 0Enable MLG Sharing for Bearer Traffic................502) n

Subnetwork ID....................................505) ___.___.___.___Network Mask.....................................510) ___.___.___.___Default Gateway..................................515) ___.___.___.___

MP Enabled..........................................@503) n


Provisioning cell2 RC/V form

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

10 10EVolution Data Only(1xEV-DO) Revision A (Rev. A)Voice Over Internet Protocol(VoIP) and Application Pricing

Overview...................................................................................................................................................................................................................................

Purpose

This optional feature description describes the EVolution Data Only (1xEV-DO)Revision A (Rev. A) Voice Over Internet Protocol (VoIP) and Application Pricing andrelated optional features in theCDMA2000® 1xEV-DO networks.


A unique Feature Identifier (FID) is assigned to each feature:

• 1xEV-DO Rev. A VoIP and Application Pricing (FID 12905.0)

• 1xEV-DO Rev A Application Pricing Enhancements (FID 12905.1)

Feature summary

1xEV-DO Rev. A VoIP and Application Pricing (FID 12905.0)

The 1xEV-DO Rev. A VoIP and Application Pricing optional feature introduces amechanism for pricing the Radio Access Network (RAN) software that supports VoiceOver Internet Protocol (VoIP), Push-to-Talk (PTT) and other applications which requireunique Quality of Service (QoS) treatment over the High Rate Packet Data Revision ARadio Access Network (RHRPD Rev. A RAN). This mechanism allows the customer topay for QoS applications as demand grows in a similar fashion as in circuit voice. Thisfeature is introduced corresponding to the “Pay As You Grow” initiative, allowing amore attractive pricing option to be offered to the operator for initial deployment. Atinitial deployment, the capacity need typically is low. As the capacity demand grows,the operator can purchase more capacity in step with the growth of its revenue.

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


10-1

1xEV-DO Rev A Application Pricing Enhancements (FID 12905.1)

The 1xEV-DO Rev A Application Pricing Enhancements feature is for incorporatingapplication license key functionalists that were descoped from FID 12905.0 due toresource constraints. The functionality includes:

• generation of a license installation″token″• providing a special license usage service measurements log

• migrating AP base application license into FID 12905.0 infrastructure


The 1xEV-DO Rev. A VoIP and Application Pricing and related features affect the userinterfaces that are listed in the following table.

Feature Name User interface Feature impact

1xEV-DO Rev. A VoIP andApplication Pricing (FID12905.0)

Element ManagementSystem (EMS) orOperations andMaintenance Center -Radio Access Network(OMC-RAN)

None

Service measurements See“Impacts on servicemeasurements: 1xEV-DORev. A VoIP andApplication Pricing (FID12905.0)” (p. 10-20).


None


None

EVolution Data Only (1xEV-DO) Revision A (Rev. A)Voice Over Internet Protocol (VoIP) and ApplicationPricing

Overview

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Feature Name User interface Feature impact

1xEV-DO Rev AApplication PricingEnhancements (FID12905.1)


None



None


None

Intended audience

This document is intended for technicians, engineers, and system administrators whoimplement or maintain the 1xEV-DO Rev. A VoIP and Application Pricing optionalfeature in aCDMA2000® 1xEV-DO network.



Contents

Availability 10-5

Prerequisites 10-6

Feature description: 1xEV-DO Rev. A VoIP and Application Pricing (FID12905.0)

10-7

Feature description: 1xEV-DO Rev A Application Pricing Enhancements(FID 12905.1)

10-13

Feature interactions: 1xEV-DO Rev. A VoIP and Application Pricing(FID 12905.0)

10-17

Feature interactions: 1xEV-DO Rev A Application Pricing Enhancements(FID 12905.1)

10-19


Overview

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


10-3


Impacts on service measurements: 1xEV-DO Rev. A VoIP andApplication Pricing (FID 12905.0)

10-20

Impacts on service measurements: 1xEV-DO Rev A Application PricingEnhancements (FID 12905.1)

10-23

License Key Installation 10-24


Overview

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Availability...................................................................................................................................................................................................................................


The 1xEV-DO Rev. A VoIP and Application Pricing and related optional features areavailable in:

• 1xEV-DO Rev. A VoIP and Application Pricing (FID 12905.0) - Releases 28.0 andlater.

• 1xEV-DO Rev. A Application Pricing Enhancements (FID 12905.1) - Releases 29.0and later.

Market availability

The 1xEV-DO Rev. A VoIP and Application Pricing and related optional features areavailable in the North American Region (NAR) market only.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


10-5

Prerequisites...................................................................................................................................................................................................................................

Introduction

The 1xEV-DO Rev. A VoIP and Application Pricing and related optional features havethe following prerequisites.


The 1xEV-DO Rev. A VoIP and Application Pricing and related optional features aresupported in the following air-interface technologies:

• CDMA cellular

• CDMA PCS

HLR configuration

The 1xEV-DO Rev. A VoIP and Application Pricing and related optional features aresupported by both the Integrated Home Location Register (IHLR) configuration and theStand-alone Home Location Register (SHLR) configuration.


The 1xEV-DO Rev. A VoIP and Application Pricing optional feature requires ECPRelease 28.0 or later. The 1xEV-DO Rev. A VoIP and Application Pricing optionalfeature is dependent on:


The 1xEV-DO Rev. A Application Pricing Enhancements (FID 12905.1) optionalfeature requires ECP Releases 29.0 and later. The 1xEV-DO Rev. A Application PricingEnhancements optional feature is dependent on:




The 1xEV-DO Rev. A VoIP and Application Pricing and related optional featuresrequire no hardware beyond the standard hardware in aCDMA2000® 1xEV-DOnetwork.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Feature description: 1xEV-DO Rev. A VoIP and ApplicationPricing (FID 12905.0)...................................................................................................................................................................................................................................

Introduction

The following information describes the functionality, benefits, and operation of the1xEV-DO Rev. A VoIP and Application Pricing (FID 12905.0) optional feature.

Functionality

The 1xEV-DO Rev. A VoIP and Application Pricing (FID 12905.0) optional featureprovides a generic license key mechanism that can be used to support new and existinglicense keys with little or no change to the infrastructure. The license key mechanismincludes a license key generator, license key processing functionality on the RNC, andlicense key management capabilities on Element Management System (EMS),Operations and Maintenance Center/Radio Access Network (OMC/RAN) andOperations and Maintenance Platform for Flexent (OMP-FX). The license keygenerator is for generating software license keys to″unlock″ various resources on anRNC or BTS and for decoding protected data. The OMP-FX provide the license keymanagement capabilities such as installing license key, query license key status andgenerating license key request form. The RNC application will be responsible forvalidating and maintaining license keys, enforce license limit and report problems. The1xEV-DO Rev. A VoIP and Application Pricing optional feature will support thefollowing license types. The 1xEV-DO Rev. A VoIP and Application PricingEnhancements optional feature introduces AP base application software:

• Basic Rev A bundle carrier by FID 12078.2

• Generic QoS application new in FID 12905.0

• RNC VoIP application new in FID 12905.0

• RNC PTT application new in FID 12905.0

• RNC Video application new in FID 12905.0

• BTS application EQU new in FID 12905.0

• AP base application software new in FID 12905.1

The main motivation for using a license key mechanism is to address issues with theoptional FAFable optional feature approach.

The 1xEV-DO Rev. A VoIP and Application Pricing and related optional features haveno feature control FAF or QFAF.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


10-7

Benefits

The 1xEV-DO Rev. A VoIP and Application Pricing and related optional featuresintroduce a new pricing mechanism for QoS/VoIP applications, supporting the “Pay AsYou Grow” initiative that allows a more attractive pricing option for the serviceproviders, particularly during the initial deployment phase.

The addresses the critical issue of ensuring technical support receive an ongoingrevenue stream from VoIP analogous to the current revenue stream for 1X circuitvoice. The 1xEV-DO Rev. A VoIP and Application Pricing and related optional featuresprovide a mechanism for charging applications which requires special QoS treatment inthe HRPD Rev A RAN. This pricing mechanism will supplement the Rev A LicenseFee introduced in Enhanced Reverse and Forward Links using Enhanced MACProtocols with Rev. A Subtype 2 Physical Layer (FID 12078.2) for the basic Rev Afeature bundle.


The right to use VoIP, PTT and other QoS based applications over HRPD Rev A RANare provided by technical support in the form of RNC and BTS license fees referred toas Rev. A RAN Application License Fees. This pricing applies to customers who wishto purchase advanced Rev. A capabilities on top of the basic Rev. A functionality totransport QoS applications over their HRPD Rev. A RAN. These advanced capabilitiesinclude, but are not limited to, per application QoS, Data Over Signaling, EnhancedIdle State and Enhanced Multi-Flow Packet Application. This pricing will supplementthe per-subscriber VoIP application pricing defined for the FS5000 TelephonyApplication Server (TAS) and associated IP Multimedia Subsystem TelephonyApplication Server (IMS TAS) client software, as well as the client/server pricingstructure established for any other application. Customers purchasing the end-to-endVoIP solution will be charged both the VoIP over HRPD Rev. A pricing, in addition tothe per-subscriber FS5000 VoIP application pricing and any other VoIP-related softwareon any IMS or core network elements.

This QoS pricing mechanism over the Rev. A RAN introduces new software licensingcapabilities. The license Keys will contain information such as the number of QoSapplication sessions allowed, number of allowed QoS Units per BTS, RNC ID, etc.that are necessary to enable the purchased application or resources on the appropriatenetwork elements in the customer network. The license keys will be created anddelivered to customers the same way as for Rev. A license key. Two types of softwarelicenses will be introduced as part of this feature:

• Radio Network Controller (RNC) Application License: to allocate capacity on aRNC to support application sessions with unique QoS treatment

• Base Transceiver Station (BTS) Application License: to allocate capacity on aBTS to support application sessions with unique QoS treatment


Feature description: 1xEV-DO Rev. A VoIP andApplication Pricing (FID 12905.0)

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Both Licenses are needed for any QoS application to be granted by the RNC.

RNC Application License

The RNC Application License Key is on a per RNC basis and will include the numberof licenses in each QoS service category. The quantity of licenses used are counted bythe number of open reservations in a QoS service category. One license is counted foreach pair of open reservation in forward and reverse directions for each QoS ProfileID.For a given application, if a reservation is opened in only one direction (the otherclosed or not required), one license is counted. The service category supported in thisfeature will include the one in Application Based Quality of Service (QoS) Support forHRPD Rev. A (FID 12078.9) (conversational speech and video) and DOrA ApplicationQoS Features (PTT) features. Additional service categories will be introduced insubsequent releases.

Customers pay an incremental fee for each open reservation in a QoS service categorysuch as conversational speech (VoIP), conversational video (real time video), etc. Anycombination of open reservations in unique QoS service categories is allowed (forexample 1000 simultaneous VoIP sessions plus 100 simultaneous video sessions, etc.)up to the engineering limits defined for the RNC. For applications such as videotelephony, which utilize flows in different QoS service categories (for exampleconversational speech and conversational video), customers must purchase support forthe appropriate number of open reservations in both of the QoS service categories (forexample to support 100 video telephony sessions, customer must purchase support for100 conversational speech open reservations and 100 conversational video openreservations).

Alternatively, for customers with a very uncertain traffic mix, the RNC ApplicationLicensing mechanism does support purchasing a specific number of genericreservations which can be used for any application on any QoS service category.However, the customer must purchase either a number of reservations of each QoSservice category that are simultaneously supported on a RNC or a number of genericreservations that can be used for any applications (mixed case is not supported). It isindicated that the price of a generic reservation will be higher than certain reservationsand lower than others (for example the price of a generic reservation will be higherthan the price of a VoIP reservation and lower than a Video reservation). The pricingfor these different types of applications/reservations is beyond the scope of this feature.

The RNC application will check the license usage whenever a new reservation for QoSflow(s) is requested from the Access Terminal (AT). The RNC will maintain an activereservation count for each QoS service category. If the active reservation count is lessthan the licensed quantity, the new reservation request will be granted (subject to theQoS admission control mechanism introduced in Application Based Quality of Service(QoS) Support for HRPD Rev. A (FID 12078.9) to check if there is enough RadioFrequency (RF) and backhaul resources before accepting a new reservation.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


10-9

If not, warning messages will be displayed as the purchased capacity for QoSapplications is reached and a grace period is initiated:

• Once a grace period is started, new reservations will continue to be granted up tothe physical limitations of the system.

• Once the grace period expires, new reservations in excess of the license limit willbe rejected.

• The duration of the grace period is currently under consideration. It is believed thatthe grace period will be in the length of hours. The final value will be shared withcustomers during the request of the License Key.

• Once started, a grace period can be terminated by obtaining a new license, thatincreases the license limit, or by obtaining a grace period emergency override fromtechnical support.

BTS Application License

It is based on the portion of a Rev A carrier that is allocated for applications whichrequire unique QoS treatment.

The BTS application license implementation will be based on an “Equivalent QoS Unit(EQU)” method. EQU is an equivalent measure of carrier resources that are required tosupport a QoS Profile ID. For convenience, the EQU is normalized to the resourcerequired to support a VoIP call, such as one EQU is needed for each VoIP call. Otherapplications, such as video telephony will require multiple EQUs to support a singlevideo telephony call. For example, a conversational video (40 kbps) may use fourtimes the resources of a VoIP call and therefore requires four EQUs. Note that a VoIPcall corresponds to a call made using EM-FPA and ROHC. For a VoIP call made withMFPA (ROHC is not used) more than one EQU is needed

Customers pay an incremental fee for each QoS Unit used. Customer can purchase anumber of QoS Units per BTS up to the defined engineering limits. These units ofQoS capacity can be used by any QoS sensitive application such as VoIP, PTT andvideo telephony. The BTS Application License will include the total allowed QoSUnits per BTS.

The BTS application license is sold in total EQUs for a BTS regardless of theapplication type. The total is an aggregate of EQU for individual open reservation pair(counted once for symmetric application) or reservation (for asymmetric application).

The RNC will maintain a total count of QoS Units used by all active QoS reservationsfor each BTS (this apply to all Rev A carriers supported in a BTS, such as, no Rev 0carriers, as QoS is not supported over Rev 0). When a new reservation is requestedfrom the AT, the RNC will convert the requested QoS Profile ID to QoS Units and



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

accept or reject the new request based on the total QoS Units count. Once the numberof purchased EQUs is fully utilized, warning message will be displayed as thepurchased capacity for QoS applications is reached and a grace period is initiated:

• Once a grace period is started, new reservations will continue to be granted up tothe physical limitations of the system.

• Once the grace period expires, new reservations in excess of the license limit willbe rejected.

• Once started, a grace period can be terminated by obtaining a new license, thatincreases the license limit, or by obtaining a grace period emergency override fromtechnical support.

As mentioned previously a grace period will be implemented to allow temporaryoverruns of the RNC and/or BTS license limits. During this grace period, the BTS andRNC will handle QoS traffic (such as VoIP, PTT, video telephony) in any combinationup to the capacity limits of the hardware purchased. During grace period, the customermust contact technical support and request one of the following actions:

• Purchase additional RNC and/or BTS licenses to prevent a future overrun.

• Obtain an emergency override license key to extend the grace period until aspecific date to address a onetime emergency situation. This request will beprocessed with equal urgency to a severity 1 service affecting outage.

If the customers takes one of these two actions within the grace period, the graceperiod will be reset and restarted in the event of the next overrun.

If the customer takes no action within the grace period, and when the grace periodexpires the system will enforce the purchased RNC and BTS license limits as hardlimits.

Warning messages will instruct the customer on the action to be taken.

Service Measurements

A set of service measurements related to the RNC and BTS application licenses usagewill be provided. The service measurements defined in this feature serve the purposesof alerting the service provider that license limits have been exceeded, and alsoproviding information on usage patterns during the normal time, the grace period, andthe enforcing period. There are two sets of SMs in 1xEV-DO Rev. A VoIP andApplication Pricing feature:

• setup counts

• usage counts

The setup counts reveal the information on rejections and acceptance when the licenselimits are exceeded. The usage counts show in average and peak how many licensesare being used concurrently. The service provider may also use other service



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


10-11

measurements defined in other features such as Application Based Quality of ServiceQoS Support for HRPD Rev. A (FID 12078.9) to get a complete picture of how theQoS based applications are supported.

Service measurements for 1xEV-DO Rev. A VoIP and Application Pricing (FID12905.0) are detailed in the“Impacts on service measurements: 1xEV-DO Rev. A VoIPand Application Pricing (FID 12905.0)” (p. 10-20)section of this chapter.

Service measurements for Application Based Quality of Service QoS Support forHRPD Rev. A (FID 12078.9) are detailed in Chapter 7 of this document.


The 1xEV-DO Rev. A VoIP and Application Pricing and related optional features offerthe following advantages:

• Lower up-front costs for launching enhanced and QoS based services such VoIPand PTT over HRPD Rev A

• “Pay As You Grow” - incremental payments as the traffic volume and quantity ofservice offerings grows

• Pay only for actual services deployed (such as VoIP, or PTT, or Video Telephony,etc.)



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Feature description: 1xEV-DO Rev A Application PricingEnhancements (FID 12905.1)...................................................................................................................................................................................................................................

Introduction

The following information describes the functionality, benefits, and operation of the1xEV-DO Rev A Application Pricing Enhancements (FID 12905.1) optional feature.

Functionality

The 1xEV-DO Rev A Application Pricing Enhancements (FID 12905.1) optionalfeature introduces enhancements to the 1xEV-DO Rev. A VoIP and Application Pricing(FID 12905.0) feature which include:

SM data collection every 15 minutes for QoS licenses in the following states:

• Grace

• Override

Handling AP Base Application license:

• Overhead Manager (EVDO) (OHM) Initialization

• Invalid AP license Alarm

Additional enhancements:

• Allowing QoS License quantity reduction

• Allow Overdraft capability when license is in Grace State

• Token: when a new license key with less quantity is installed over an existinglicense key, RNC will generate an installation token.

• Audit modifications to allow valid local memory data to overwrite invalid DB datafor given license

• OHM Initialization – modification for handling AP Base Application licenseinstallation through License Installation Tool (LIT) to LLM License Limit Manager(LLM)

Benefits

The 1xEV-DO Rev A Application Pricing Enhancements (FID 12905.1) optionalfeature provides a “Pay As You Grow” pricing mechanism for charging the RANsoftware that supports applications which require unique QoS treatment over the 1xEV-DO Rev A RAN such as PTT and VT.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


10-13


The 1xEV-DO Rev A Application Pricing Enhancements (FID 12905.1) optionalfeature enhances license mechanisms introduced in Release 28.0 for 1xEV-DO Rev. AVoIP and Application Pricing (FID 12905.0).

As with the previous feature the customer is able to view their current Licensequantities and license order form through a License Installation Tool which resides onthe OA&M Platform for the OMP-FX. The 1xEV-DO Rev A Application PricingEnhancements (FID 12905.1) optional feature provides the ability to request a LicenseQuantity reduction for an existing license and request an AP Base Application license.

Once the order is processed, the license key will be crated and delivered to customersthe same was as for Rev. A license key. The 1xEV-DO Rev A Application PricingEnhancements (FID 12905.1) optional feature allows the ability to specify an Overdraftto be included in generating the license key(s).

The Overdraft option will be enforced when a license is in Grace State. While thelicense is in Grace State the system will enforce the purchased RNC and BTS licenselimits (with additional Overdraft) as limit.

When the customer invokes the License Installation Tool (LIT) to install the plain-textlicenses file on the appropriate RNC. If LLM License Limit Manager (LLM) detects alicense reduction, a token file is created. The LLM will create an AP Base Applicationlicense in the format and stored in the location introduced by 1xEV FMS SoftwareLicensing (Phase 1) (FID 9050.0).

Once the customer has access to the License Token file is should be provided tocustomer support for cerificate of license reduction. Token files are found underdirectory structure:/omp-data/logs/LicenseTools/tokenfiles

The LLM manages the license data and usage information obtained from the LicenseLimit Agent (LLA) and determines if requests should continue to be allowed. Forlicenses that are in Grace, Enforce or Overriding state the Service Measurements (SM)that are collected in the LLM are written into an SMLog file collection every 15minutes.

The SMLog files are found under directory structure :/omp-data/logs/LicenseTools/smlogs directory

The SMLog file is named as follows :LicenseSMLOGYYMMDDHHMM = LicenseSMLOG +

YY(year)+MM(Month)+DD(day)+HH(Hour)+MM(Minute)

Periodically (every 12 hours) the LIT checks with the LLM for an available SMLogfile. If a log file is available on the AP then the LIT transfers the SMLog file(s) to theOMP-FX. The SMLog files can be extracted using the command lines:


Feature description: 1xEV-DO Rev A Application PricingEnhancements (FID 12905.1)

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

For collecting SMLogs from all RNCs use:

• licenseSMLog

For collecting individual RNCs use:

• omppclo root> licenseSMLog -r 26

Starting the SM Log Retrieval

Executing function:

• Create_RNC_list

• List of RNCs fromHdrNeConfig.datfile are 23 24 26 25

• /opt/fasttrack/docs/ems/classes/com/lucent/autoplex/ems/cm/frames_to_version.map does not exist, copy all the RNC to valid RNC list

• List of valid RNCs are23 24 26 25

Pulling Files for RNC ID 26

RNC 26:

• Primary AP - flx251, IP 172.32.13.80

• Secondary AP - flx252, IP 172.32.13.81

Using 172.32.13.80 for all the Licensing operations

• The resultOffset =1

• The return code from evLIT isSM_FILE_NOT_EXIST

• licenseSMLog exiting with status0

The AP initialization and OHM Initialization are modified to check for a valid AP Baseapplication license during OHM Initialization. The License Audit is modified tovalidate the local image and update the Database image if applicable.


The service provider must apply an AP Base application license(s) for any AP growthusing 1xEV-DO Rev A Application Pricing Enhancements (FID 12905.1)(ompLicenseTool) or 1xEV-DO RNC SW Licensing (Phase 2) (FID 9050.1). If thelicense is not available during OHM Initialization an Alarm report is triggered to notifythe customer and OHM initialization will be complete, but no call processing isallowed.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


10-15

123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789

**46 REPT: EVDO: AP 221, ALARMAP 221 Base Software License Key is not installed or invalidPERCEIVED SEVERITY: MAJ, CAUSE: Software Error2007-06-19 13:46:56 REPORT #000001 FINAL

04 REPT: EVDO: AP 221, ALARM CLEAREDAP 221 Base Software License Key is not installed or Invalid2007-06-19 14:04:49 REPORT #000001 FINAL



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Feature interactions: 1xEV-DO Rev. A VoIP and ApplicationPricing (FID 12905.0)...................................................................................................................................................................................................................................

Introduction

The 1xEV-DO Rev. A VoIP and Application Pricing (FID 12905.0) optional featureinteracts with the following features:

• Enhanced Reverse and Forward Links using Enhanced MAC Protocols with Rev. ASubtype 2 Physical Layer (FID 12078.2)


• DOrA Application QoS Features

The 1xEV-DO Rev. A VoIP and Application Pricing (FID 12905.0) and the 1xEV-DORev. A Application Pricing Enhancements optional feature are dependent on theApplication Based Quality of Service (QoS) Support for HRPD Rev. A (FID 12078.9)optional feature that will create the Rev A QoS infrastructure for Multiflow PacketApplication (MFPA). The Application QoS Support for HRPD Rev. A feature supportsconversational speech (CS) and conversational video (CV) QoS service categories andselected QoS Profile ID under those service categories. Although service provider isunlikely to provide VoIP or video telephony application based on MFPA, CS and CVQoS capabilities it will be supported by Application QoS Support for HRPD Rev. A(FID 12078.9) feature and therefore the 1xEV-DO Rev. A VoIP and Application Pricing(FID 12905.0) will provide the license key capability for those QoS service categories.

The DOrA Application QoS Features is available at the same release as 1xEV-DO Rev.A VoIP and Application Pricing (FID 12905.0). The Application QoS Support forHRPD Rev. A (FID 12078.9) feature will also provide the license key infrastructuresupport for CS and CV QoS service categories operating in the EM-FPA mode. For the1xEV-DO Rev. A VoIP and Application Pricing optional feature (FID 12905.0), themain difference between application operating in MFPA and EM-FPA mode is in theBTS resources, such as how EQU is used. The 1xEV-DO Rev. A VoIP and ApplicationPricing (FID 12905.0) will need to count EQU in accordance with the mode theapplication is supported with.

The License Key mechanism for 1xEV-DO Rev. A VoIP and Application Pricing (FID12905.0) optional feature will be developed based on the License Key implementationprovided in Enhanced Reverse and Forward Links using Enhanced MAC Protocolswith Rev. A Subtype 2 Physical Layer (FID 12078.2).


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


10-17


This optional feature is part of the Rev. A mandatory package of features, also referredto as Mandatory Rev. A Feature Bundle. This optional feature introduces the support ofthe full Rev. A Physical Layer with the complete set of Rev. A enhanced MediumAccess Control (MAC) protocols that is the following MAC protocols are supported:





This optional feature is supported on all Modular Cell BTS types using the new HRPDRev. A modem board, the SB-EVM for Modular Cell 4.0 and variants or theSB-EVMm for Modular Cell 1-3. This optional feature is supported only by the Rev. Acapable RNC.


This optional feature is not part of the Rev. A mandatory package of features. Itsupports QoS per application flow based on request from the user, user QoS profileand allocatable resource at the system. This optional feature only includes the RadioAccess Network (RAN) network elements. This optional feature is supported on bothexisting FMS and next generation RNC platforms. Also this optional feature issupported on any base station that supports the mandatory package for Rev. A. Thisoptional feature will be configured on both OMC-RAN and OMP-FX platforms.

DOrA Application QoS Features

The Basic PTT on HRPD-A optional feature provides the basic PTT functionality inthe HRPD RAN using HRPD Rev. A. HRPD Rev. A is required to help meet the tightdelay requirements.

The Basic PTT on HRPD-A optional feature includes paging enhancements that can beused to increase the effectiveness of paging. Paging effectiveness is defined as theability to locate the terminating user with minimum paging attempts. For PTT, locatingthe users on the first paging attempt is crucial for minimizing the initial setup delay.The Basic PTT on HRPD-A optional feature introduces QoS paging using two pagingarea types:

• Last Seen Active Set

• Last Seen RNC (such as Color Code)


Feature interactions: 1xEV-DO Rev. A VoIP andApplication Pricing (FID 12905.0)

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Feature interactions: 1xEV-DO Rev A Application PricingEnhancements (FID 12905.1)...................................................................................................................................................................................................................................

Introduction

The 1xEV-DO Rev A Application Pricing Enhancements optional feature interacts withthe following features:


• 1xEV FMS Software Licensing (Phase 1) (FID 9050.0)

• 1xEV-DO RNC SW Licensing (Phase 2) (FID 9050.1)

The 1xEV-DO Rev A Application Pricing Enhancements optional feature builds uponthe functionality introduced in 1xEV-DO Rev. A VoIP and Application Pricing (FID12905.0), specifically the new LLM Virtual Cluster Virtual Machine (VCVM) processin RNC OA&M. This The 1xEV-DO Rev A Application Pricing Enhancements optionalfeature also uses the check_key function introduced by FIDs 9050.0 and 9050.1 whichverify that the AP Base Application license is formatted properly. Once the 1xEV-DORev A Application Pricing Enhancements optional feature is introduced and the featureis enabled, the check_key function is called during OHM Initialization. If the feature isnot introduced the function is called during AP bring up as currently implemented.

1xEV FMS Software Licensing (Phase 1) (FID 9050.0)

The feature introduces a license key within the 1xEV software running on the 1xEVFMS to prevent customers from replicating 1xEV software on multiple servers withoutpaying our per copy RTU fee. The 3G-1X PCF IWF has an implementation based onMD5 shareware that can be used.

1xEV FMS Software Licensing (Phase 2) (FID 9050.1)

This feature is an enhancement to the 1xEV FMS Software Licensing (Phase 1) (FID9050.0) feature that modifies the result of key validation failure on a DO RNC AP.This feature aborts the initialization process when a key is invalid resulting in all DOAP application software becoming out of service.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


10-19

Impacts on service measurements: 1xEV-DO Rev. A VoIP andApplication Pricing (FID 12905.0)...................................................................................................................................................................................................................................

Introduction

The 1xEV-DO Rev. A VoIP and Application Pricing (FID 12905.0) optional featureaffects the following categories of services measurements:

• HDR counts

• HDRC counts

• RNC counts

HDR counts

The 1xEV-DO Rev. A VoIP and Application Pricing optional feature affects the1xEV-DO service measurements that are identified inTable 10-1, “1xEV-DO servicemeasurements - BTS-HDR Counts” (p. 10-20).

Table 10-1 1xEV-DO service measurements - BTS-HDR Counts


AVG_BTS_EQU_LICENSE_USAGE Average BTS EQU License Usage

BTS_EQU_LICENSE_STATE BTS EQU License State

PEAK_BTS_EQU_LICENSE_USAGE Peak BTS EQU License Usage

HDRC counts

The 1xEV-DO Rev. A VoIP and Application Pricing optional feature affects the1xEV-DO service measurements that are identified inTable 10-2, “1xEV-DO servicemeasurements - SECT-CARR-HDRC counts” (p. 10-20).

Table 10-2 1xEV-DO service measurements - SECT-CARR-HDRC counts


CS_RESV_DROPPED_HO_NO_EQU_LICENSE_KEY

Conversational Speech ReservationsDropped during soft handoff when asector in a BTS without valid EQUlicense key is added to the active set

CV_RESV_DROPPED_HO_NO_EQU_LICENSE_KEY

Conversational Video ReservationsDropped during soft handoff when asector in a BTS without valid EQUlicense key is added to the active setexceeded


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Table 10-2 1xEV-DO service measurements - SECT-CARR-HDRC counts(continued)


PTT_RESV_DROPPED_HO_NO_EQU_LICENSE_KEY

Conversational PTT Speech ReservationsDropped during soft handoff when asector in a BTS without valid EQUlicense key is added to the active set

ROR_REJECTED_RNC_LICENSE_LIMIT_EXCEEDED

Reservation On Requests Rejected -- RNCLicense Limit

ROR_REJECTED_TOTAL_BTS_EQU_LIMIT_EXCEEDED

Reservation On Requests Rejected -- TotalBTS EQU Limit Exceeded

RNC counts

The 1xEV-DO Rev. A VoIP and Application Pricing optional feature affects the1xEV-DO service measurements that are identified inTable 10-3, “1xEV-DO servicemeasurements - SN-RNC counts” (p. 10-21).

Table 10-3 1xEV-DO service measurements - SN-RNC counts


AVG_RNC_LICENSE_USAGE_CS Average RNC Conversational SpeechLicense Usage

AVG_RNC_LICENSE_USAGE_CV Average RNC Conversational VideoLicense Usage

AVG_RNC_LICENSE_USAGE_GENERIC Average RNC Generic License Usage

AVG_RNC_LICENSE_USAGE_PTT Average RNC Conversational PTT SpeechLicense Usage

PEAK_RNC_LICENSE_USAGE_CS Peak RNC Conversational Speech LicenseUsage

PEAK_RNC_LICENSE_USAGE_CV Peak RNC Conversational Video LicenseUsage

PEAK_RNC_LICENSE_USAGE_GENERIC

Peak RNC Generic License Usage

PEAK_RNC_LICENSE_USAGE_PTT Peak RNC Push-To-Talk License Usage

RNC_LICENSE_STATE_CS RNC Conversational Speech License State

RNC_LICENSE_STATE_CV RNC Conversational Video License State

RNC_LICENSE_STATE_GENERIC RNC Generic License State


Impacts on service measurements: 1xEV-DO Rev. A VoIPand Application Pricing (FID 12905.0)

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


10-21

Table 10-3 1xEV-DO service measurements - SN-RNC counts (continued)


RNC_LICENSE_STATE_PTT RNC Conversational PTT Speech LicenseState

References

For detailed information about 1xEV-DO service measurements, see 401-614-326,CDMA® Wireless Networks 1xEV-DO Service Measurements.


Impacts on service measurements: 1xEV-DO Rev. A VoIPand Application Pricing (FID 12905.0)

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Impacts on service measurements: 1xEV-DO Rev A ApplicationPricing Enhancements (FID 12905.1)...................................................................................................................................................................................................................................

Introduction

The 1xEV-DO Rev A Application Pricing Enhancements (FID 12905.1) optionalfeature affects no additional services measurements:

References

For detailed information about 1xEV-DO service measurements, see 401-614-326,CDMA2000® Wireless Networks 1xEV-DO Service Measurements.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


10-23

License Key Installation...................................................................................................................................................................................................................................

Reference

Regarding license key installation, refer to the license installation tool on the OMP-FX.For detailed installation procedures see CDMA2000®/ Wireless Networks Operationsand Management Platform (OMP-FX),401-662-108document and the1xEV-DO RASPlanning and Implementation Guide,401-614-101document.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

11 11Radio Network Controller(RNC) Grouping to ImproveIdle Hand-off Performance

Overview...................................................................................................................................................................................................................................

Purpose

This optional feature description describes the Radio Network Controller (RNC)Grouping to Improve Idle Hand-off Performance optional feature inCDMA2000®

1xEV-DO networks.

Feature summary

The RNC Grouping to Improve Idle Hand-off Performance optional feature improvesthe idle handoff performance by cutting down the session transfers and eliminating thesession transfer ping-ponging for ATs moving around RNC borders within the sameRNC Group. It also allows the operator to detect packet loss between RNCs.


A unique Feature Identifier (FID) is assigned to each optional feature. The FID of theRNC Grouping to Improve Idle Hand-off Performance optional feature is FID 12456.1.


The RNC Grouping to Improve Idle Hand-off Performance optional feature affects theuser interfaces that are listed in the following table.


Feature Element Management System(EMS)

See“Radio Network Controller (RNC)Group Setup Scenarios in ElementManagement System (EMS)” (p. 11-19)

Operations and Maintenance Center -Radio Access Network (OMC-RAN)

See“Radio Network Controller (RNC)Group Setup Scenarios in Operations andMaintenance Center - Radio AccessNetwork (OMC-RAN) ” (p. 11-26)

....................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


11-1




None


See“Impacts on TI messages” (p. 11-13)

Intended audience

This document is intended for technicians, engineers, and system administrators whoimplement or maintain the RNC Grouping to Improve Idle Hand-off Performanceoptional feature in aCDMA2000® 1xEV-DO network.



Contents

Availability 11-3

Prerequisites 11-4




Impacts on TI messages 11-13



Radio Network Controller (RNC) Group Setup Scenarios in ElementManagement System (EMS)

11-19

Radio Network Controller (RNC) Group Setup Scenarios in Operationsand Maintenance Center - Radio Access Network (OMC-RAN)

11-26

Radio Network Controller (RNC) Grouping to Improve IdleHand-off Performance

Overview

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Availability...................................................................................................................................................................................................................................


The RNC Grouping to Improve Idle Hand-off Performance optional feature is availablein ECP Releases 28.0 and later. See“Issues and caveats” (p. 11-15)for more detailsrelating to cell releases.

Market availability

The RNC Grouping to Improve Idle Hand-off Performance optional feature is availablein all markets.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


11-3

Prerequisites...................................................................................................................................................................................................................................

Introduction

The RNC Grouping to Improve Idle Hand-off Performance optional feature has thefollowing prerequisites.


The RNC Grouping to Improve Idle Hand-off Performance optional feature issupported in the following air-interface technologies:

• in any band class

HLR configuration

The RNC Grouping to Improve Idle Hand-off Performance optional feature does notuse a Home Location Register (HLR) configuration.


The RNC Grouping to Improve Idle Hand-off Performance optional feature requiresECP Release 28.0 or later.


The RNC Grouping to Improve Idle Hand-off Performance optional feature requires nohardware beyond the standard hardware in aCDMA2000® 1xEV-DO network.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Introduction

The following information describes the functionality, benefits, and operation of theRNC Grouping to Improve Idle Hand-off Performance optional feature.

Important! The Radio Network Controller (RNC) Grouping to Improve IdleHand-off Performance optional feature will be referred to as RNC Groupingthroughout this section.

Functionality

The RNC Grouping to Improve Idle Hand-off Performance optional feature allowsmultiple RNCs to form a group in which the AT can be served by one RNC butcontrolled by another RNC in the group. The PCF entity with the A10 terminationsends page messages across RNC boundaries to any cell within the group. The RNCGrouping to Improve Idle Hand-off Performance optional feature provides thecapability so that the AT does not have to register when crossing an RNC boundary. Ifthe group is configured so the AT does register when it crosses an RNC boundary, theAT is able to keep the same session. The RNC Grouping to Improve Idle Hand-offPerformance optional feature improves the overall system performance by avoiding theidle handoff ping-ponging and RATI ping-ponging at RNC boundaries.

The RNC Grouping to Improve Idle Hand-off Performance optional feature allows theRNCs to send messages to other RNCs in the group, or all RNCs configured in theColor Code Map table, for the purpose of detecting dropped packets. A new alarm willbe raised when there are multiple consecutive dropped packets. A new ROP messageperiodically reports the percentage of dropped packets.

Benefits

The RNC Grouping to Improve Idle Hand-off Performance gives service providers theability to combine multiple RNCs into a group so that an AT can keep its session whenit moves across the RNC borders within the RNC group. This would improve the idlehandoff performance by cutting down the session transfers and eliminating the sessiontransfer ping- ponging for ATs moving around RNC borders within the same RNCgroup.


The RNC Grouping to Improve Idle Hand-off Performance optional feature providesoptions for ATs to send UATI Requests when they cross the RNC boundaries withinthe RNC group or for ATs to stay in the dormant state as they move across RNCborders within the group. By default the SubnetMask is set to70 for RNCs in a group,


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


11-5

which causes ATs to send UATI Requests when crossing RNC boundaries. TheSubnetMask can be changed to64 to cause ATs to not send UATI Requests whenstaying within the RNC group.

When the AT sends a UATI Request when it crosses an RNC boundary within theRNC group, the session controlling AP determines whether it will transfer the session.This determination is based on the session load of the session controlling AP and theserving AP. If the load on the session controlling AP is greater than theSession Load Threshold and the load is higher than that of the serving AP by atleastSession Load Differential, the session is transferred. If the session istransferred, the serving AP assigned a new UATI. If the session is not transferred, thesession controlling AP will reassign the same UATI to the AT. The load balancingfunctionality can be disabled by setting theSession Load Threshold to 100.

A new screen is used to create a new RNC group with an RNC Group ID. Theparameters specific to the RNC group, such asSession Load Threshold andSession Load Differential, are provisioned on this screen. An individual RNCmember in the RNC group is identified by its associated color code. For each member,there must be a corresponding AN IP Address provisioned in the Color Code Mappage. An RNC can be added to (or removed from) an RNC Group in one of threeways:

• add / remove an RNC group member using RNC Group Member page

• modify the Color Code of an existing member using RNC Group Member page

• change the AN IP Address associated with a color code in the Color Code Mappage

Messages are exchanged between RNCs of the group to discover the AP IP Addresses,Service Node ID, and Frame ID of each of the RNCs. For an RNC group with RNCsfrom different Service Nodes, the RNC group and RNC group members need to becreated in each of the Service Nodes.

The RNC Grouping to Improve Idle Hand-off Performance optional feature requiresthat the contents of the SectorID message broadcast by each cell contain additionalinformation. For RNCs that are part of a group, there is RNC grouping informationincluded in the new format of the SectorID message. There is also a new SectorIDVersion field included in the SectorID message that can optionally be enabled ordisabled, by using theSectorID Version Included translation on the SN page. Whenthe Sector ID Version is changed it will force all of the ATs served by that RNC tore-register. The SectorID Version gets incremented automatically whenever AT sessioninformation is lost or inaccessible (for instance, when RNC reboots or RNC is removedfrom an RNC group). The SectorID Version is also synchronized between all membersof an RNC group, so if the SectorID Version changes all of the ATs served by theentire RNC group are forced to re-register. Otherwise, the EV-DO network would notbe able to reach or alert the ATs with invalid sessions.


Feature description

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

The RNC Grouping to Improve Idle Hand-off Performance optional feature providesmore paging options to enhance the paging performance. There are four pagingmethods available, and four associated paging translations which indicate the numberof times to page using each of the methods. The “Paging Strategy” translation has beendeprecated since flood paging can now be enabled or disabled using the newtranslations

• Number of times to page the last active set of cells obtained from the Last RouteUpdate message

• Number of times to page the RNC that was last serving the AT (also known as thelast seen RNC)

• Number of times to page the Neighbor RNCs (last two seen RNCs)

• Number of times to page the entire RNC group

A value of zero for any of these paging parameters will indicate that the associatedpaging method should be skipped. In addition, the sum of the four paging areas cannotexceed eight and the number of times to page the last active set plus the number oftimes to page the last serving RNC cannot be zero.

The general idea is to page the last active set first, then the last serving RNC, then thelast two seen RNCs, and lastly the entire RNC Group. The RNC Grouping to ImproveIdle Hand-off Performance optional feature will page each area the number of times setin translation, separated by a Paging Timer (in paging parameters under service nodetranslation), until the number of times is exhausted, or until the Paging Time-to-LiveTimer (in paging parameters under service node translation) is expired. When thePaging Time-to-Live Timer expires or the number of times to page all areas isexhausted, the paging stops.

There are new alarm and ROP messages that have been added:

• The “Communication Lost” alarm is reported when an RNC detects communicationfailure with another RNC in the group, which will result in the SectorID Versionbeing incremented. This alarm is raised by the RNC that is responsible formanaging the SectorID Version for the group. It is raised when it detects an RNCdid not receive the SectorID Version after several attempts. These messages arecontrolled by the Heartbeat Timer parameter (RNC Group page).

• The AT REREGISTRATION ROP messages are reported whenever all of the ATs areforced to re-register. The ROP messages include the reasons why the ATs are forcedto re-register.

• The “Heartbeat Failure” alarm is reported when multiple consecutive heartbeatswith other RNCs are missed. The heartbeating is controlled by the AuxiliaryService Node Control-1 parameter and is explained below.

• The periodicNETWORK STAT ROP message indicates the percentage of packets thatwere dropped between the RNC and the other RNCs being monitored.


Feature description

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


11-7

The network monitoring performed by the feature is under the control of the AuxiliaryService Node Control-1 parameter (Service Node II/General page). Monitoring can bedisabled, enabled for just RNCs in the RNC Group, or enabled for all RNCsprovisioned in the Color Code Map table. The rate at which the heartbeat messages aresent, and the rate of theNETWORK STAT ROP message, are also configured by the sameparameter.

Network monitoring utilizes proprietary messages introduced by this feature, somonitoring can only be performed with other RNCs running release R28 SU2, orhigher.

The RNC Grouping to Improve Idle Hand-off Performance is intended to improve theidle handoff performance at RNC boundaries. The RNCs to be grouped are those withidle handoff ping-ponging problem or RNCs with coverage gaps at their borders.

The following indicators can be used to identify the RNCs for grouping:

• RNC with high count of Inter-Subnet idle transfer attempts

• RNC with low inter-Subnet idle transfer success rate

• RNC with high count of prior session transfer request

• RNC with high paging failure rate

• RNC with high count of dangling session


Feature description

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Introduction

The RNC Grouping to Improve Idle Hand-off Performance optional feature interactswith no other features.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


11-9


Introduction

The RNC Grouping to Improve Idle Hand-off Performance optional feature affects thefollowing categories of services measurements:

• HDRC counts

HDRC counts

The RNC Grouping to Improve Idle Hand-off Performance optional feature affects the1xEV-DO service measurements that are identified inTable 11-1, “1xEV-DO servicemeasurements - SECT-CARR-HDRC Counts” (p. 11-10).

Table 11-1 1xEV-DO service measurements - SECT-CARR-HDRC Counts


INTER_RNC_CONN_ESTABLISHED Inter-RNC Connection RequestEstablished

INTER_RNC_CONN_REQ Inter-RNC Connection Request Received

INTER_RNC_TCA_SENT Inter-RNC Connection Request - TCA sent

INTRA_RNC_GROUP_BORDER_CROSSED

Intra RNC Group Border Crossed

INTRA_RNC_GROUP_SESS_TRFR_ATTEMPT

Intra-RNC Group Session TransferAttempt

INTRA_RNC_GROUP_SESS_TRFR_SUCCESS

Intra-RNC Group Session TransferSuccess

INTRA_RNC_GROUP_SESS_TRFR_UATI_ASSGN_SENT

Intra-RNC Group Session Transfer - UATIAssignment Sent

INTRA_RNC_GROUP_SESS_TRFR_UATI_COMPLETE_RCVD

Intra-RNC Group Session Transfer - UATIComplete Received

Other Service Measurement Impacts

There may be a decrease in the following Service Measurements due to RNC Groupingto Improve Idle Hand-off Performance. SeeTable 11-2, “Other Service MeasurementImpacts” (p. 11-10)Service Measurements that may be impacted.

Table 11-2 Other Service Measurement Impacts


REQ_WITH_UNRECOGNIZED_UATI Requests with Unrecognized UATI


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Table 11-2 Other Service Measurement Impacts (continued)


DANGLING_SESS_CLOSED Number of Dangling Sessions Closed

SESS_SETUP_UATI_ASSGNMT_MSG_SENT

UATI Assignment Messages Sent

SESS_SETUP_UATI_COMPLETE_MSG_RCVD

UATI Complete Messages Received

AN_INIT_KEEP_ALIVE _REQ AN-Initiated Keep Alive Requests

INT_SUBNET_IDLE_TRFR_A13_REQ_RECVD

Inter-Subnet Idle Transfer A13 RequestsReceived

ISBNT_IDL_TRFR_A13_SESS_INFO_RSP_SENT

Inter-Subnet Idle Transfer A13-SessionInformation Response Messages Sent

INT_SUBNET_IDLE_TRFR_A13_REJECT_SENT

Inter-Subnet Idle Transfer A13 RejectMessages Sent

INT_SUBNET_IDLE_TRFR_A13_CONFIRM_RECVD

Inter-Subnet Idle Transfer A13 ConfirmMessages Received

INT_SUBNET_IDL_TRFR_PRIOR_SES_ATTEMPTS

Inter-Subnet Idle Transfer Attempts forPrior Session

INT_SUBNET_IDL_TRFR_ATTMPT Inter-Subnet Idle Transfer Attempts

ISBNT_IDL_TRFR_FAIL_SRC_IP_ADR_NT_FOUND

Inter-Subnet Idle Transfer Attempt Failure- Source IP address not found

INT_SUBNET_IDLE_TRFR_A13_SIR_RCVD_LATE

Inter-Subnet Idle Transfer A13 SessionInformation Message Received late

ISBNT_IDL_TRFR_FAIL_NO_RSP_PRV_SBNET

Inter-Subnet Idle Transfer Failures - NoResponse from Previous Subnet

ISBNT_IDL_TRFR_FAIL_PRIOR_SES_NO_RSP

Inter-Subnet Idle Transfer Failures - NoResponse from Previous Subnet for PriorSession

INT_SUBNET_IDL_TRFR_PRIOR_SES_BAD_REQ

Inter-Subnet Idle Transfer Failures -Insufficient Information in AT PriorSession Configuration Request

ISBNT_IDL_TRFR_FAIL_ORG_PDSN_CANT_CONN

Inter-Subnet Idle Transfer Failures -Original PDSN Cannot Connect

ISBNT_IDL_TRFR_FAIL_RJCT_MSG_RCVD

Inter-Subnet Idle Transfer Failures -Reject Message is received

INT_SUBNET_IDL_TRFR_FAIL_OTHER_REASON

Inter-Subnet Idle Transfer Failures – OtherReasons



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


11-11

Table 11-2 Other Service Measurement Impacts (continued)


SESS_CLOSE_SESS_TRFR _ABORTED Session Closed - Session Transfer Aborted

SESS_SETUP_ISBNT_UATI_ASSGN_MSG_SENT

Session Setup - Inter-Subnet HandoffUATI Assignment Message Sent

SESS_SETUP_ISBNT_UATI_COMPLETE_MSG_RCVD

Session Setup - Inter-Subnet HandoffUATI Complete Message Received

References

For detailed information about 1xEV-DO service measurements, see 401-614-326,CDMA2000® 1xEV-DO Service Measurements.



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Impacts on TI messages...................................................................................................................................................................................................................................

Introduction

The following information describes the impact of the RNC Grouping to Improve IdleHand-off Performance optional feature on input messages and output messages in theTechnician Interface (TI).

Input messages

The following input messages are existing commands and support the RNC Groupingto Improve Idle Hand-off Performance optional feature:

• OP-UATI-STATUSExecute that input message to request the session status of a given UniversalAccess Terminal Identifier (UATI).

• OP-ESN-STATUSExecute that input message to request the session status of a given Electronic SerialNumber (ESN).

• OP-IMSI-STATUSExecute that input message to request the session status of a given InternationalMobile Station Identity (IMSI).

• OP-MEID-STATUSExecute that input message to request the session status of a given MobileEquipment Identifier (MEID).

Output messages

The output messages of the four above mentioned existing input commands weremodified to also include:

• SERVING SN ID

• BTS SN ID

The RNC Grouping to Improve Idle Hand-off Performance optional feature addedadditional information to the session status output to includeSERVING SN ID andBTS SN ID output messages.

Output messagesREPT-EVDO-RNC-AT-RE-REG andREPT-EVDO-RNC-NETWORK-STAT areintroduced by the RNC Grouping to Improve Idle Hand-off Performance optionalfeature.

References

For detailed descriptions of those input messages, see 401-610-055, CDMA2000®

Wireless Networks Input Messages.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


11-13

For detailed descriptions of those output messages, see 401-610-057, CDMA2000®

Wireless Networks Output Messages.


Impacts on TI messages

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Introduction

The RNC Grouping to Improve Idle Hand-off Performance optional feature is subjectto the following special issues and/or caveats.

Caveats

Before the RNC Grouping to Improve Idle Hand-off Performance optional feature, allConnection Requests were handled within the RNC since the AT needed to get a newUATI once it had moved across the RNC boundary. With the RNC Grouping toImprove Idle Hand-off Performance optional feature, ATs may have the cell serving APand the session controlling AP in different RNCs. The Connection Request isforwarded from a cell serving AP to a session controlling AP in different RNCs. Thisintroduces delays if two RNCs are far away from each other which may affect thesuccess rate of the Connection Request establishment. For best performance, an RNCmust be grouped with RNCs with which they have a low packet loss and delay.

It is also recommended to group RNCs with same feature set, especially with thecapability of supporting Rev. A or Rev 0. When two RNCs with different capabilitiesare grouped together, the capability might not be fully utilized. For example, withmixture of Rev. A and Rev 0 RNCs in the same group, an AT with Rev A capabilitymight not be able to utilize the Rev A function even if it is in a serving area of a RevA RNC. The reason is that this AT might be controlled by another RNC with Rev. 0within the same RNC Group. However, the mixture of RNCs with different functionswill not result in call failures. The configuration with RNCs with different feature setswill only be used on a temporary basis, such as on a system upgrading.

There are two options for setting the SubnetMask when an RNC is in a group. It canbe set to64 or 70. When the subnet mask is set to64 the AT will not send a UATIrequest when it crosses an RNC boundary in the group. When the subnet mask is set to70 the AT will send a UATI request when it crosses an RNC boundary within thegroup.

The advantage of setting the SubnetMask to64 is that it avoids extra UATI requests.When a subnet mask of70 is used, RATI ping-ponging may still occur. This occurswhen there are coverage gaps along an RNC border. In that case the AT might send aUATIRequest (RATI) and use the prior-session transfer to restore the old session. Thiswill introduce extra processing and potentially create a dangling session. Moreseriously, this may cause the session transfer ping-ponging since a new session isgranted for UATIRequest (RATI).

A disadvantage of setting the SubnetMask to64 is that the access network is not ableto track the AT when it moves across RNC boundaries within the RNC group. So theaccess network needs to page a wider area to locate the AT, which would have a


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


11-15

negative impact on the paging efficiency. With a SubnetMask of 64 the OHM sessionload may become unbalanced depending upon the traffic pattern. OHMs controllingcells along the RNC Group border may control an increased number of sessions.

When using a SubnetMask of64 there is a risk of overloading the control channel withpage messages. That issue may be mitigated by enabling distance based route updates.With distance based route updates the AT will send a route update message when it hasmoved beyond a predefined radius from the previous sector that it sent a route updateon. By doing this the access network will have a more accurate view of the ATslocation, which would reduce the number of flood pages that have to be sent.

Important! RNCs should only be grouped if all of the cells controlled by theRNCs are R28 cells, or R27 cells running at least R27.02, or R26 cells running atleast R26.03. These cells have a change which allows the SubnetMask to beupdated dynamically. If an RNC in a group controls cells that are not on one ofthese releases, the cells will need to be rebooted for a new SubnetMask value totake effect.

The RNC Group ID must not be reused by adjacent RNCs outside the group as it isused to identify the coverage area of the RNC group. When using a SubnetMask of64the RNC Group ID defines the RNCs within the group and triggers the AT to sendUATI request when crossing the group border. When using a SubnetMask of70 theRNC Group ID ensures the AT will send a UATI request when crossing a borderbetween two RNCs in separate groups that are using the same RNC Group MemberID.

The RNC Group size is limited by the total number of sector carriers in the Group.The service measurements collected by remote processor needs to be transported to thelocal processor at the end of each hour. The processor to transport the servicemeasurements can only support service measurements of 1300 sector carriers within aRNC Group. If there are more than 1300 sector carriers in the RNC Group some of theservice measurements might be lost during the transport. For example, for RNCsequipped with 200 sector carriers, only 6 RNCs can be grouped together to guaranteethe complete collection of service measurements.

To limit processor occupancy the heartbeat interval for network monitoring should notbe less than 10 seconds when monitoring more than 60 RNCs.

When setting up an RNC group, the customer needs to check the neighboring marketsto be sure the color code maps in those markets include entries for all RNCs in thegroup. With RNC grouping, a neighboring RNC may need to perform an idle handoffwith any RNC in the group, not just the immediate neighbor RNC. The reason for thisis because the AT’s session could be located on any RNC within the group. For moredetailed information about the color code map, see CDMA2000® 1xEV-DOConfiguration Parameters Guide,401-614-324.


Issues and caveats

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

The color code map of a neighboring RNC, which borders an RNC group, needs to beconfigured correctly with the color codes of all RNCs in the group. Otherwise, theremay be an increase in idle handoff failures in the neighboring RNCs. This may alsomake the performance of the RNC group worse along the RNC group borders. Thecustomer can monitor the ROP file for occurrences of CP Fail Error Code 20005 toidentify idle handoff failures where the source RNC IP address can not be found due toa missing color code in the color code map.


Issues and caveats

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


11-17


Overview

The RNC Grouping to Improve Idle Hand-off Performance optional feature creates anew screen for the RNC Group with a RNC Group ID. The parameters specific to theRNC group, such asSession Load Threshold andSession Load Differential, areprovisioned on the new screen. Each individual RNC in the RNC Group is identifiedby its associated color code. For each RNC member, the technician enters the ColorCode of the RNC on a RNC Group Members screen. Before adding an RNC to agroup the technician must verify that the A13 IP address of the RNC is added to theColor Code Maps screen for the corresponding color code.

The RNC Grouping to Improve Idle Hand-off Performance optional feature is FAFable.

To disable the RNC Grouping to Improve Idle Hand-off Performance optional featureall RNC Group Members must be deleted, and then all RNC Groups.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Radio Network Controller (RNC) Group Setup Scenarios inElement Management System (EMS)...................................................................................................................................................................................................................................

Purpose

The RNC Grouping to Improve Idle Hand-off Performance setup scenarios cover howthe groups are created and deleted, and how the RNCs are added to the groups anddeleted from the groups in EMS. Also covered are enabling and disabling networkmonitoring.

Create a new RNC Group for Two or More RNCs in the Same SN

Important! All the RNCs are in service.


...................................................................................................................................................................................................

1 Go to theRNC Group screen, and click on theCreate new RNCGroup instance link.

...................................................................................................................................................................................................

2 EnterRNC Group ID and populate allGroup specific parameters.

...................................................................................................................................................................................................

3 Click Submit

...................................................................................................................................................................................................

4 Go to theRNC Group Members screen, and click on theCreate newRNCGroupMember instance link.

...................................................................................................................................................................................................

5 Populate thegroup ID, member ID, andcolor code parameters.

...................................................................................................................................................................................................

6 Click Submit

...................................................................................................................................................................................................

7 Repeat Substeps 4 - 6 to add all RNCs.

Important! The Color Code of the RNC matches the Color Code entry on theRNCFrame screen and the Color Code in theColor Code to A13 AP IP address table.

...................................................................................................................................................................................................

8 Optional step to verify and modify SubnetMask, openConfiguration Page page.

...................................................................................................................................................................................................

9 Click on FMS frame and select the table with frame number you want to provision –all the parameters in that Frame.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


11-19

...................................................................................................................................................................................................

10 Modify the SubnetMask to the desire value based on the guide. See“Issues andcaveats” (p. 11-15)for more information

...................................................................................................................................................................................................

11 Modify the paging parameters for the service node containing the RNCs added to thegroup. Go to thePaging Parameters page on theService Node screen. Set theparameters as indicated inTable 11-3, “Modify Paging Parameters” (p. 11-20):

Table 11-3 Modify Paging Parameters

Parameter SubnetMask =70

SubnetMask = 64

Number of Times to Page the Last Active Set 2 2

Number of Times to Page the Last Seen RNC 1 1

Number of Times to Page Neighboring RNC 1 0

Number of Times to Page Entire RNC Group 0 1

...................................................................................................................................................................................................

12 Verify the color code maps (CCMap) of adjacent RNCs include all RNCs in the group.

System behaviors

Performing this procedure will add new info in the SectorID and cause all ATs in theserving area to send UATI Request. The UATI Request will be handled by the servingOHM and the serving OHM will assign the same UATI back to the AT.

Create a New RNC Group with RNCs from Different SNs

Important! All RNCs are in service.

...................................................................................................................................................................................................

1 Start with SN1 and follow the steps in the previous procedure,“Create a new RNCGroup for Two or More RNCs in the Same SN” (p. 11-19)to add RNC group andmember information into the SN1.

...................................................................................................................................................................................................

2 Go to each of the other SNs with RNCs in the group and follow the steps in theprevious procedure,“Create a new RNC Group for Two or More RNCs in the SameSN” (p. 11-19)to add RNC group and member information into the SN. On each SN


Radio Network Controller (RNC) Group Setup Scenariosin Element Management System (EMS)

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

E N D O F S T E P S...................................................................................................................................................................................................

make sure to use the same member ID for the same RNC.

System behaviors


Add a RNC to an Existing RNC Group (All in the Same SN)


...................................................................................................................................................................................................

1 Go to theRNC Group Members screen, and click on theCreate newRNCGroupMember instance link.

...................................................................................................................................................................................................

2 Populate thegroup ID, member ID, andcolor code parameters.

...................................................................................................................................................................................................

3 Click Submit

...................................................................................................................................................................................................

4 Verify the color code maps (CCMap) of adjacent RNCs include all RNCs in the group.

System behaviors

The newly added RNC will change the SectorID to include new info so all ATs servedby the newly added RNC will start to send UATI Request. The same UATI will beassigned back to the ATs. The existing RNCs will exchange info with the newly addedRNC in the background but there is no impact to the ATs served by existing RNCmembers.

Add a RNC from a Different SN (SN2) to an Existing RNC Group

Important! All RNC are in service

...................................................................................................................................................................................................




...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


11-21

E N D O F S T E P S...................................................................................................................................................................................................

E N D O F S T E P S...................................................................................................................................................................................................

...................................................................................................................................................................................................

2 Go to the other SNs with RNCs in the group and follow the steps in the previousprocedure,“Add a RNC to an Existing RNC Group (All in the Same SN)” (p. 11-21)to add RNC member information into the SN.

System behaviors


Remove One RNC from the RNC Group (All in the Same SN)

Important! All RNCs are in service

...................................................................................................................................................................................................

1 Go to theGroup Member screen and select the RNC member to be deleted.

...................................................................................................................................................................................................

2 Click on theDelete link on theRNC Group Member page.

...................................................................................................................................................................................................

3 Click Submit

...................................................................................................................................................................................................

4 If there are no longer any RNCs in the SN that are in a group then restore the pagingparameters to the recommended values.

System behaviors

When removing an RNC from the group, the SectorID Version changes for all of theRNCs that remain in the group. For the RNC being removed, the SectorID Versiondoes not change, but the SectorID changes.

All ATs in the deleted RNC coverage area will request a new UATI

• For ATs with sessions controlled by the RNCs still in the RNC Group, the idlehandoff will be performed and sessions will be transferred to the serving RNC.

• For ATs with sessions controlled by the deleted RNC, the same UATI_024 will beassigned back to the ATs.



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

E N D O F S T E P S...................................................................................................................................................................................................

E N D O F S T E P S...................................................................................................................................................................................................

All ATs in the coverage area of the remaining RNC Group members will request a newUATI if the SectorID Version Included flag on the SN page is set toy.

• For ATs with sessions controlled by the deleted RNC, the idle handoff will beperformed and sessions will be transferred to the serving RNC.

• For ATs with sessions controlled by the other RNCs still in the RNC Group, UATIRequest will be treated as regular UATI Requests when ATs cross the RNCboundaries within the RNC Group. The session may be transferred to the servingRNC or stay at the original controlling RNC, depending on the session loads of theRNCs.

Remove One RNC from the RNC Group Spanning Multiple SNs


...................................................................................................................................................................................................

1 Note the color code of each RNC that is to be deleted from the group and theRNCGroup Member ID .

...................................................................................................................................................................................................

2 On each SN that has an RNC in the group follow the steps in the previous procedure,“Remove One RNC from the RNC Group (All in the Same SN)” (p. 11-22)to removethe RNC from the RNC Group Member information for that SN.

System behaviors

The system will behave as described in the previous procedure,“Remove One RNCfrom the RNC Group (All in the Same SN)” (p. 11-22).

Remove an RNC Group


...................................................................................................................................................................................................

1 Note the color code of each RNC that is to be deleted from the group and theRNCGroup Member ID .

Go to theRNC Group Members screen and verify no members are listed with theGroup ID that is to be deleted. If necessary use the previous procedures“Remove OneRNC from the RNC Group (All in the Same SN)” (p. 11-22)and“Remove One RNCfrom the RNC Group Spanning Multiple SNs” (p. 11-23)to remove the members.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


11-23

E N D O F S T E P S...................................................................................................................................................................................................

...................................................................................................................................................................................................

2 On each SN that has the RNC Group configured go to the RNC Groups screen, selectthe ID of the Group to be deleted, and click on the delete button. Click on theOKbutton when prompted to confirm deletion.

...................................................................................................................................................................................................

3 Repeat step two on the remaining service nodes, as applicable.

System behaviors

There is no impact to the operation of the system when RNC Groups are deleted.System behavior is only affected when members are deleted from the group, asdiscussed in the previous two procedures.

Enable or Disable Network Monitoring

...................................................................................................................................................................................................

1 Go to theService Node II General screen and enter the desired value forAuxiliary Service Node Control - 1. Set the values as indicated inTable 11-4,“Values for Auxiliary Service Node Control - 1” (p. 11-24).

Table 11-4 Values for Auxiliary Service Node Control - 1

Value Enabled/Disabled

HeartbeatInterval

(seconds)

ROPReportInterval

(minutes)

RNCs Monitored

0 Disabled n/a n/a n/a

1 Enabled 3 15 RNCs in the RNC Group








9 Enabled 3 15 All RNCs in the CCMap




...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

E N D O F S T E P S...................................................................................................................................................................................................

Table 11-4 Values for Auxiliary Service Node Control - 1 (continued)






System behaviors

When the value ofAuxiliary Service Node Control – 1 is set to0 or 8 nonetwork monitoring is performed. Other values enable monitoring of the other RNCs inthe group, or all RNCs with AN IP addresses provisioned in the CCMap table. Whenenabled the RNC will send a heartbeat message to the other RNCs at the selected rate,and report the percentage of packet loss in the ROP at the specified interval.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


11-25

E N D O F S T E P S...................................................................................................................................................................................................

Radio Network Controller (RNC) Group Setup Scenarios inOperations and Maintenance Center - Radio Access Network(OMC-RAN)...................................................................................................................................................................................................................................

Purpose

The RNC Grouping to Improve Idle Hand-off Performance setup scenarios cover howthe groups are created and deleted, and how the RNCs are added to the groups anddeleted from the groups within the OMC-RAN. Also covered are enabling anddisabling network monitoring.





For more information about the different 1xEV-DO OA&M interfaces that are used inperforming OA&M tasks on the EV-DO controller and it’s managed resources,including the purpose of each interface and how to access it, seeAlcatel-Lucent 9271EV-DO Radio Network Controller,401-614-102, Chapter 3,″User Interfaces″.

Create a new RNC Group for Two or More RNCs in the Same SN

Important! All the RNCs are in service.

In R29 and earlier,FxApx VNE (the FxApx listed at the bottom of the ORCAGroup) gives a global SN general view for all EV-DO RNCs on one FxApx.

In R30 and later,x:R30 Global Config DO wherex is the FxApx for the ORCAGroup) gives a global SN general view for all EV-DO RNCs on one FxApx.


...................................................................................................................................................................................................

1 Go to theGlobal Config DO tab, and click on left arrow ofGlobal Config DO .

...................................................................................................................................................................................................

2 CreateRNC Group under theGlobal Config DO tab.

...................................................................................................................................................................................................

3 Right click on theGlobal Config DO , and createRNC Group.

...................................................................................................................................................................................................

4 Configure the parameters within createdRNC Group following the guide. TheRNC Group Table folder is created.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

...................................................................................................................................................................................................

5 CreateRNC Group Member , under theRNC Group (in Global Config DO of theframe).

...................................................................................................................................................................................................

6 Right click on theRNC Group, and createRNCGroupMember. Repeat for additionalmembers.

...................................................................................................................................................................................................

7 Check the color code map by opening theGlobal Config DO tab by left clicking onthe left arrow ofGlobal Config DO . Ensure the Color Code to AN IP addressmapping is correct in theCCmap .

...................................................................................................................................................................................................

8 Verify the color code maps (CCmap ) of adjacent RNCs include all RNCs in the group.Repeat for all additional color code maps.

...................................................................................................................................................................................................

9 Optional step to verify and modify SubnetMask, openDO-RNC:FMS# tab. Click on leftarrow of DO-RNC:FMS# tab, underDO-RNC:FMS# tab of the frame

...................................................................................................................................................................................................

10 Right click on the desiredHDRFrame and select theDetails .

...................................................................................................................................................................................................

11 In the Details window under theHDRFrame tab, modify theSubnetMask to the desirevalue based on the guide. See“Issues and caveats” (p. 11-15)for more information.

...................................................................................................................................................................................................

12 Modify the paging parameters for the service node containing the RNCs added to thegroup. Go to theGlobal Config DO page (not tab). Right clickGlobal Config DO andselectDetails .

...................................................................................................................................................................................................

13 In the Details window Under SN Page tab, select and modify the desired values ofthe paging under theNumber of Time to Page section. Set the parameters asindicated inTable 11-5, “Modify Paging Parameters” (p. 11-27):

Table 11-5 Modify Paging Parameters

Parameter SubnetMask =70

SubnetMask = 64

Number of Times to Page Neighboring RNC 1 0


Radio Network Controller (RNC) Group Setup Scenariosin Operations and Maintenance Center - Radio Access

Network (OMC-RAN)

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


11-27

Table 11-5 Modify Paging Parameters (continued)

Number of Times to Page Entire RNC Group 0 1

Number of Times to Page the Last Seen RNC 1 1

Number of Times to Page the Last Active Set 2 2

System behaviors


Create a New RNC Group with RNCs from Different SNs


...................................................................................................................................................................................................


...................................................................................................................................................................................................

2 Go to each of the other SNs with RNCs in the group and follow the steps in theprevious procedure,“Create a new RNC Group for Two or More RNCs in the SameSN” (p. 11-26)to add RNC group and member information into the SN. On each SNmake sure to use the same member ID for the same RNC.

System behaviors


Add a RNC to an Existing RNC Group (All in the Same SN)


...................................................................................................................................................................................................

1 Go to theRNC Group Member tab, under theRNC Group (in Global Config DO ofthe frame).



Network (OMC-RAN)

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

E N D O F S T E P S...................................................................................................................................................................................................

E N D O F S T E P S...................................................................................................................................................................................................

...................................................................................................................................................................................................

2 Right click on theRNC Group, and createRNCGroupMember. Repeat for additionalmembers.

...................................................................................................................................................................................................

3 Check the color code map by opening theGlobal Config DO tab by left clicking onthe left arrow ofGlobal Config DO . Ensure the Color Code to AN IP addressmapping is correct in theCCmap .

...................................................................................................................................................................................................

4 Verify the color code maps (CCmap ) of adjacent RNCs include all RNCs in the group.Repeat for all additional color code maps.

System behaviors


Add a RNC from a Different SN (SN2) to an Existing RNC Group

Important! All RNC are in service

...................................................................................................................................................................................................


...................................................................................................................................................................................................

2 Go to the other SNs with RNCs in the group and follow the steps in the previousprocedure,“Add a RNC to an Existing RNC Group (All in the Same SN)” (p. 11-28)to add RNC member information into the SN.



Network (OMC-RAN)

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


11-29

E N D O F S T E P S...................................................................................................................................................................................................

E N D O F S T E P S...................................................................................................................................................................................................

System behaviors


Remove One RNC from the RNC Group (All in the Same SN)


...................................................................................................................................................................................................

1 Go to theRNC Group Member tab, under theRNC Group (in Global Config DO ofthe frame).

...................................................................................................................................................................................................

2 Right click on theRNC Group, and deleteRNCGroupMember. Repeat for additionalmembers.

...................................................................................................................................................................................................

3 Click Submit

...................................................................................................................................................................................................

4 If there are no longer any RNCs in the SN that are in a group then restore the pagingparameters to the recommended values.

System behaviors

When removing an RNC from the group, the SectorID Version changes for all of theRNCs that remain in the group. For the RNC being removed, the SectorID Versiondoes not change, but the SectorID changes.

All ATs in the deleted RNC coverage area will request a new UATI

• For ATs with sessions controlled by the RNCs still in the RNC Group, the idlehandoff will be performed and sessions will be transferred to the serving RNC.

• For ATs with sessions controlled by the deleted RNC, the same UATI_024 will beassigned back to the ATs.



Network (OMC-RAN)

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

E N D O F S T E P S...................................................................................................................................................................................................

All ATs in the coverage area of the remaining RNC Group members will request a newUATI if the SectorID Version Included flag on the SN page is set toy.

• For ATs with sessions controlled by the deleted RNC, the idle handoff will beperformed and sessions will be transferred to the serving RNC.

• For ATs with sessions controlled by the other RNCs still in the RNC Group, UATIRequest will be treated as regular UATI Requests when ATs cross the RNCboundaries within the RNC Group. The session may be transferred to the servingRNC or stay at the original controlling RNC, depending on the session loads of theRNCs.

Remove One RNC from the RNC Group Spanning Multiple SNs


...................................................................................................................................................................................................

1 Note the color code of each RNC that is to be deleted from the group and the RNCGroup Member.

...................................................................................................................................................................................................

2 On each SN that has an RNC in the group follow the steps in the previous procedure,“Remove One RNC from the RNC Group (All in the Same SN)” (p. 11-30)to removethe RNC from the RNC Group Member information for that SN.

System behaviors

The system will behave as described in the previous procedure,“Remove One RNCfrom the RNC Group (All in the Same SN)” (p. 11-22).

Remove an RNC Group


...................................................................................................................................................................................................

1 Note the color code of each RNC that is to be deleted from the group and the RNCGroup Member.

Go to theRNC Group Member tab and verify no members are listed with theRNC Group that is to be deleted. If necessary use the previous procedures“RemoveOne RNC from the RNC Group (All in the Same SN)” (p. 11-30)and“Remove OneRNC from the RNC Group Spanning Multiple SNs” (p. 11-31)to remove themembers.



Network (OMC-RAN)

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


11-31

E N D O F S T E P S...................................................................................................................................................................................................

...................................................................................................................................................................................................

2 On each SN that has the RNC Group configured go to theRNC Group Member tab,select theRNC Group to be deleted, and right click on the desiredRNC Group Memberand select delete.

...................................................................................................................................................................................................

3 Repeat Step 2 on the remaining service nodes, as applicable.

System behaviors

There is no impact to the operation of the system when RNC Groups are deleted.System behavior is only affected when members are deleted from the group, asdiscussed in the previous two procedures.

Enable or Disable Network Monitoring

...................................................................................................................................................................................................

1 Go to theGlobal Config DO page (not tab) and right click on the textGlobal Config DO and selectDetails .

...................................................................................................................................................................................................

2 From theDetails window, underCurrent Engr select and modifyAuxiliary Service Node Control – 1 with the appropriate value. Set the values asindicated inTable 11-6, “Values for Auxiliary Service Node Control - 1” (p. 11-32).

Table 11-6 Values for Auxiliary Service Node Control - 1

Value Enabled/Disabled

HeartbeatInterval

(seconds)

ROPReportInterval

(minutes)

RNCs Monitored











Network (OMC-RAN)

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

E N D O F S T E P S...................................................................................................................................................................................................

Table 11-6 Values for Auxiliary Service Node Control - 1 (continued)









System behaviors

When the value ofAuxiliary Service Node Control – 1 is set to0 or 8 nonetwork monitoring is performed. Other values enable monitoring of the other RNCs inthe group, or all RNCs with AN IP addresses provisioned in the CCMap table. Whenenabled the RNC will send a heartbeat message to the other RNCs at the selected rate,and report the percentage of packet loss in the ROP at the specified interval.



Network (OMC-RAN)

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


11-33

E N D O F S T E P S...................................................................................................................................................................................................

12 12EVolution Data Optimized(EV-DO) PerformanceMonitoring Tools Enhancements

Overview...................................................................................................................................................................................................................................

Purpose

This chapter describes the following features inCDMA2000® 1xEV-DO Networks.Unique Feature Identifiers (FIDs) are assigned to each feature:

• 1xEV-DO Performance Monitoring Tools Enhancements (FID 9253.1)

• 1xEV-DO Tool Interface between Operations and Maintenance Platform forFlexent® (OMP-FX) and 1xEV-DO Radio Network Controller (RNC) (FID 9253.2)

• Access Terminal (AT) Trace Enhancement for Customer Use (FID 9253.3)

Feature summary


1xEV-DO Performance Monitoring Tools Enhancements (FID 9253.1)

The 1xEV-DO Performance Monitoring Tools Enhancements adds Special EngineeringStudies (SMS) tools to provide histogram counts of performance data for capacityplanning purposes including Reverse Link Short and Long Term RSSI, Forward LinkTraffic Percent Busy Slots and Datalink Utilization.

1xEV-DO Tool Interface between OMP-FX and 1xEV-DO RNC (FID 9253.2)

The 1xEV-DO Tool Interface between OMP-FX and 1xEV-DO RNC feature provides anew interface between the OMP-FX and the Optimized Reconfigurable ChipArchitecture Radio Network Controller (ORCA-RNC) for Operations and MaintenanceCenter - Radio Access Network (OMC-RAN) managed RNCs.

AT Trace Enhancement for Customer Use (FID 9253.3)

The Access Terminal (AT) Trace Enhancement for Customer Use feature is a calltracing tool that is anchored on EV-DO RNC. It logs messages traversed through themajor control functions in RNC such as Overhead Management (OHM), Selected

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


12-1

Function Main (SFM), and Packet Control Function (PCF). These messages arepertained to EV-DO standards, including A11/A12/A13 and the HDR Air Interfaces(HAI).

This feature allows the customer to use the tool to trace multiple ATs, no matter if theyare in active, dormant or idle state, across multiple RNCs under the same Service Node(SN). The header of the logged messages are enhanced in such a way that they provideadequate information to allow re-construction of the call flows along the time line. Asa result, the messages logged is translated to the call flows among cell site, RNC(including OHM, SFM and PCF), Packet Data Serving Node (PDSN), and Ran-AAA,which facilitate fault detection and error diagnosis.


The 1xEV-DO Performance Monitoring Tools Enhancements optional feature affectsthe user interfaces that are listed in the following table.


1xEV-DO PerformanceMonitoring ToolsEnhancements (FID9253.1)


None

Service measurements SeeCDMA2000®1xEV-DO Network ServiceMeasurements,401-614-326 for a samplecopy of the SES histogramand full descriptions of theSES counts.


None


See “Impacts on TIMessages”

EVolution Data Optimized (EV-DO) PerformanceMonitoring Tools Enhancements

Overview

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


1xEV-DO Tool Interfacebetween OMP-FX and1xEV-DO RNC (FID9253.2)


None



None


None

AT Trace Enhancement forCustomer Use (FID9253.3)


None



None


None



Contents

Availability 12-5

Prerequisites 12-6

Feature description: 1xEV-DO Performance Monitoring ToolsEnhancements (FID 9253.1)

12-8


Overview

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


12-3


Feature description: 1xEV-DO Tool Interface between OMP-FX and1xEV-DO RNC (FID 9253.2)

12-11

Feature description: AT Trace Enhancement for Customer Use (FID9253.3)

12-13





Activating the feature: 1xEV-DO Performance Monitoring ToolsEnhancements

12-27

Activating the feature: AT Trace Enhancement for Customer Use 12-28

Manual Pages: AT Trace Enhancement for Customer Use 12-29


Overview

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Availability...................................................................................................................................................................................................................................


The following table identifies the AMPS/PCS software releases in which the 1xEV-DOPerformance Monitoring Tools Enhancements feature and related features are available.


1xEV-DO Performance Monitoring ToolsEnhancements (FID 9253.1)


1xEV-DO Tool Interface between OMP-FX and1xEV-DO RNC (FID 9253.2)


AT Trace Enhancement for Customer Use (FID9253.3)


Market availability

The 1xEV-DO Performance Monitoring Tools Enhancements feature and relatedfeatures are available in the following markets:


1xEV-DO PerformanceMonitoring Tools Enhancements(FID 9253.1)


1xEV-DO Tool Interface betweenOMP-FX and 1xEV-DO RNC(FID 9253.2)


AT Trace Enhancement forCustomer Use (FID 9253.3)



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


12-5

Prerequisites...................................................................................................................................................................................................................................

Introduction

The 1xEV-DO Performance Monitoring Tools Enhancements feature and relatedfeatures have the following prerequisites.



The 1xEV-DO Performance Monitoring Tools Enhancements optional feature issupported in the following air-interface technologies:



The 1xEV-DO Tool Interface between OMP-FX and 1xEV-DO RNC feature issupported in the following air-interface technologies:



The AT Trace Enhancement for Customer Use optional feature is supported in thefollowing air-interface technologies:


HLR configuration


The 1xEV-DO Performance Monitoring Tools Enhancements feature independent onthe Home Location Register (HLR) configuration.


The 1xEV-DO Tool Interface between OMP-FX and 1xEV-DO RNC feature isindependent on the HLR configuration.


The AT Trace Enhancement for Customer Use feature is independent on the HLRconfiguration.



The 1xEV-DO Performance Monitoring Tools Enhancements feature requires ECPRelease 27.0 or later.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


The 1xEV-DO Tool Interface between OMP-FX and 1xEV-DO RNC feature requiresECP Release 28.0 or later. For OMC-RAN managed 1xEV-DO RNCs:

• The 1xEV-DO OMC-RANCORBA® Agent - Radio Network Controller(ORCA-RNC) (FID-12080.4) must be deployed. There is no feature dependency forOMP-FX EMS managed 1xEV-DO RNCs.

• Dependencies on 1xEV-DO Infrastructure for OMC-RANCORBA® Agent - RadioNetwork Controller (ORCA-RNC) (FIDs 12080.1) feature and the OMC-RANEV-DO Radio Network Controller (RNC) Maintenance (FID 8017.14) feature.


The AT Trace Enhancement for Customer Use feature requires Release 30.0 or later.The OMC-RAN must manage the 1xEV-DO RNC.



The 1xEV-DO Performance Monitoring Tools Enhancements feature requires thestandard hardware in a CDMA Network and the following additional hardware:

• OMP-FX v2


This 1xEV-DO Tool Interface between OMP-FX and 1xEV-DO RNC is supported onboth the OMP-FX and OMP-FX2.


The AT Trace Enhancement for Customer Use feature requires the standard hardware ina CDMA Network and the following additional hardware:

• OMP-FX

• OMP-FX v2


Prerequisites

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


12-7

Feature description: 1xEV-DO Performance Monitoring ToolsEnhancements (FID 9253.1)...................................................................................................................................................................................................................................

Introduction

The following information describes the functionality, benefits, and operation of the1xEV-DO Performance Monitoring Tools Enhancements (FID 9253.1) feature .

Functionality

The EV-DO Performance Monitoring Tools Enhancements feature introduces theenhancement, Special Engineering Studies (SES) which provides data in histogramform. It collects histogram metrics from cell sites supporting 1xEV carriers for capacityplanning purposes. The following data can be collected:

• Datalink Downlink Throughput

• Datalink Uplink Throughput

• Percent busy

• Short Term RSSI

• Long Term RSSI

Each histogram is an hourly histogram. It shows the number of times each value waspegged at the 10 second scan, not the distribution throughout the hour. To run a newEVDO SES study, the FAF must be active.

Benefits

The 1xEV-DO Performance Monitoring Tools Enhancements feature collects and storesuser-specified counts in the form of histograms used for further study. These counts arenot traditional SM counts; they are collected and saved only when the SES commandis executed to collect these counts.


The EVDO SES commands are executed on the OMP-FX II, which is required to runthis tool. These are not traditional TI commands and should not be confused as such.The commands to start, stop, and collect a SES study are in/omp/bin on the OMP.The studies are run directly on the OMP in either prompt mode or command linemode.

Commands can also be run directly from the EMS CLI. Examples of the commandsare:

• START:SES; RNC a [,DURATION b] [,HIST c] [,BTS d] - which means the datawill be collected for a given RNC and one BTS.

• START:SES; RNC a [,DURATION b] [,HIST c] - by default all the BTS’s.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Pegging begins when the user enters the following command at theUNIX® prompt:

• evstartses

Executing the above command causes all equipped RNCs to clear the data and startcollecting data. If a user attempts to start a new EVDO SES study before thecompletion of the study that is currently running, the program will not start. Thecurrent study needs to be stopped before a new SES study can start.

Specifying Duration of EVDO SES

The study runs for 1 hour by default and then automatically stops. The study can alsobe run for durations from 1 hour to 24 hours with 1 hour increments. This is done byadding a-t option, followed by the number of hours to run the study.

For example to run for 2 hours enter the following:

• evstartses -t 2

The SES counts are collected for two hours and then the study stops.

Specifying Data Collection

The study collects all data by default. This study can also collect a subset of data byadding a–d Hist_List option whereHist_List can be:

• 1 - Datalink DL throughput

• 2 - Datalink UL throughput

• 3 - Percent Busy

• 4 - Short Term RSSI

• 5 - Long Term RSSI

• 6 - all, which is default

User may choose multiple data collections separated by commas or with a Hyphen (forexample: 1,2,4,5 or 1-3), but a combination of 6 with another number (1 to 5) will bedenied.

For example to run Datalink DL throughput and Percent Busy enter the following:

• evstartses –d 1,3

To run Percent Busy, Short Term RSSI, and Long Term RSSI enter the following:

• evstartses –d 3-5

Specifying RNC/BTSs to Collect Data

The study collects data from all RNCs on the service node by default. This study canalso collect data from a subset of RNCs or BTSs by using the–r and–b options. Theoptions–r and–b are mutually exclusive, meaning that if a user chooses the–r optionto collect data from a subset of RNCs, data will be collected from all the BTSs onthose RNCs. If a user chooses the–b option to collect data for a particular BTS, datawill be collected only from that particular BTS.


Feature description: 1xEV-DO Performance MonitoringTools Enhancements (FID 9253.1)

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


12-9

For example, to run on RNCs 1, 2, and 3 on the service node enter the following:

• evstartses –r 1-3

To run on BTS xxx enter the following

• evstartses –bxxx

Specifying Prompt Mode

The user chooses the prompt mode option by entering:

• evstartses –P

The user will be prompted to enter data for command line options (-t, -d, -r, -b, and–o). The option–P can not be used in combination with other command line options.

Specifying the Output File

Data is saved in an output file in the directory,/omp_data/logs/ses/evdo_fileswith a default ofyyyyMMddhhmmss.ServiceNode, whereyyyyMMddhhmmssis thetime the data collection was started. A user can end the name of output file for thestudy (add suffix to the name) by adding–o option to theevstartses command.

For example, to addsesDatasuffix, run the following command:

• evstartses –o sesData

Then the output file appears asyyyyMMddhhmmss.sesData.

Specifying Usage Option

A user can get a “Help Message” for the usage of the command by adding–h option.

SES Man Pages

Refer to “Impacts on TI messages” section for manual pages forevstatusses andevstartses and for usage information onevstartses and the format of the outputfile.

Only one SES session is allowed to be run on a service node


Feature description: 1xEV-DO Performance MonitoringTools Enhancements (FID 9253.1)

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Feature description: 1xEV-DO Tool Interface between OMP-FXand 1xEV-DO RNC (FID 9253.2)...................................................................................................................................................................................................................................

Introduction

The following information describes the functionality, benefits, and operation of the1xEV-DO Tool Interface between OMP-FX and 1xEV-DO RNC feature.

Functionality

The 1xEV-DO Tool Interface between OMP-FX and 1xEV-DO RNC provides a newinterface between the OMP-FX and the ORCA-RNC for OMC-RAN managed RNCs.Additionally, the TA tool user interface changes from an EMS CLI based interface toan OMP-FXUNIX® command interface for OMC-RAN managed 1xEV-DO RNCs.This is supported on both the OMP-FX and OMP-FX v2 and is a standard feature.

Benefits

The 1xEV-DO Tool Interface between OMP-FX and 1xEV-DO RNC changes to ATTrace tool user interface from an EMS CLI based interface to a OMP-FXUNIX®

command interface for OMC-RAN managed 1xEV-DO RNCs. The interface changesimpact HOM and SES, with no noticeable difference to the subscriber.


Some 1xEV-DO tools can be run from the OMP-FX. The SNMP interface between theOMP-FX EMS and OMP-FX EMS managed 1xEV-DO RNCs is used forcommunicating commands and responses. When the 1xEV-DO RNC is managed by theOMC-RAN, the 1xEV-DO tools are still operated from the OMP-FX; however the1xEV-DO RNC SNMP agent on that RNC is disabled. The 1xEV-DO Tool Interfacebetween OMP-FX and 1xEV-DO RNC feature provides a new interface between theOMP-FX and the 1xEV-DO RNC so that the OMP-FX based 1xEV-DO tools willcontinue to operate for OMC-RAN managed RNCs. As expected, these tools continueto operate on the OMP-FX EMS managed 1xEV-DO RNCs also. The tools that usethis new interface are:

• 1xEV-DO Handoff Matrix (HOM)

• 1xEV-DO Special Engineering Studies (SES)

• Test Application (TA)

• AT Trace (Note that the AT Trace tool is available only to Technical Support)


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


12-11


The 1xEV-DO Tool Interface between OMP-FX and 1xEV-DO RNC feature provides anew interface between the OMP-FX and the ORCA-RNC for OMC-RAN managedRNCs, but does not reflect the user impact of the feature. The old interface is SNMPand this interface is not supported on OMC-RAN 1xEV-DOs. With this feature theHOM tool supports both the legacy SNMP interface for EMS managed 1xEV-DORNCs and a new prorietary interface for OMC-RAN managed 1xEV-DO RNCs.Without this feature the HOM tool could not be run against OMC-RAN managed1xEV-DO RNCs.


The 1xEV-DO Tool Interface between OMP-FX and 1xEV-DO RNC feature also hasthe following impacts:

• For OMC-RAN managed RNCs, the service provider must use an OMP-FXUNIX®

command to initiate/stop the Test Application (TA) tool instead of the EMS-CLI TAcommand

• For OMC-RAN managed RNCs, the service provider must use an OMP-FXUNIX®

command to initiate/stop the AT Trace tool instead of the EMS-CLI AT Tracecommand.

• AT Trace data is automatically pulled by the OMP-FX and the post-processing toolis available on the OMP-FX. Therefore Technical Support normally is not requiredto login to the RNC to analyze the trace data.

These changes are made so that the service provider can run the TA and AT Trace toolsand analyze the data from the OMP-FX without having to login to the OMC-RAN orthe DO RNC.


Feature description: 1xEV-DO Tool Interface betweenOMP-FX and 1xEV-DO RNC (FID 9253.2)

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Feature description: AT Trace Enhancement for Customer Use(FID 9253.3)...................................................................................................................................................................................................................................

Introduction

The following information describes the functionality, benefits, and operation of the ATTrace Enhancement for Customer Use feature.

Functionality

The AT Trace Enhancement for Customer Use feature provides the capablilty of tracingmultiple ATs across the RNC boundaries under the same Service Node (SN), and becapable of tracing an AT through A12/A13 interfaces in addition to the air interfaceand A11 interface.

Benefits

The AT Trace Enhancement for Customer Use feature enhances internal use in thefollow aspects:

• The logging and decoding of internal messages among major controlling functions,Overhead Manager (OHM), Selector Function Manager (SFM), and Packet ControlFunction (PFC)) in EV-DO RNC, which do not contain proprietary information.


The AT Trace Enhancement for Customer Use feature is driven by external customerswho have requested the access to the AT Trace tool. Customers indicated that currenttools readily available do not provide the level of detailed information and visibility onthe EV-DO device activity. This AT Trace data helps to diagnose possible deficienciesin protocol design and implementation and helps to understand the ever complicatedcall processing activities, which include but not limited to Inter-frequency Handoff(IFHO), RNC Grouping, and Radio Access Network (RAN) AuthenticationModifications.

By extending the infrastructure built under 1xEV-DO Tool Interface between OMP-FXand 1xEV-DO RNC (FID 9253.2) feature wherein the AT Trace commands areexecuted from the OMP-FX and the logged data is automatically pulled from APsevery 15 minutes, the enhanced AT Trace can trace target ATs across the whole ServiceNode (SN) and users can enter either Unicast Access Terminal Identifier (UATI) orHardware ID (HW ID) or International Mobile Station Identity (IMSI) to start tracingtarget ATs.

The AT Trace Enhancement for Customer Use feature provides AT Trace infrastructureat the OMP and DO RNC for customer use. There is only one set of AT Tracecommands entered at the OMP-FX.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


12-13

The AT Trace Enhancement for Customer Use feature is under FAF control andprovides the following capabilities:

• Tracing an AT across RNCs (within the Service Node) and in active/dormant/idlestates

• Tracing multiple ATs, with a maximum number of four

• Logging and decoding messages over the standard interfaces, such as HAI,A11/12/13, which are used by the EV-DO RAN to talk to external entities such asATs, PDSNs, the AN-AAA, and neighboring RNCs

• Enriching message headers to include rich ancillary information, such as (source),(destination), (interface_id), (hw_id), (imsi), (uati_num), (proc_name), (year),(month), (day), (hr), (min), (sec), (micro_sec), (time_zone), (AP/TP),(hdrsnId.fmsId.apOrTPId), (message_name), (msgBytes)

• There are 25 files allocated with size of 20MB each at an RNC to log the AT Tracedata.

• If one file is filled up, a second file is used. Both are identified with the sameATID but with different indices.

• If all of the 25 files are used up, the files are over-written in chronological order.

• Eachevsrattr command starts writing into a new file even if the ATID remainsthe same. The ATID and the time stamp are used to differentiate one file from theother.

Performance

The OMP-FX is the control point for starting and stopping the AT Trace. Therecurrently is NO post-processing or parser tool available for AT Trace.

The start and stop commands are sent to all RNCs under the control of the OMP-FXand the RNCs log the designated messages that pertain to the AT(s) based on the givenAT IDs. The logged messages are sent back from RNCs to the OMP-FX and stored atthe OMP-FX under the AT IDs to facilitate the data retrieving and post-processing.

The OMP-FX facilitates the access request for AT Trace data, either in raw or ASCIIformat for a GUI based postprocessing tool such as MTA.


Feature description: AT Trace Enhancement for CustomerUse (FID 9253.3)

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Introduction

The following feature interactions exist for these features.


The 1xEV-DO Performance Monitoring Tools Enhancements feature interacts with noother features.


The 1xEV-DO Tool Interface between OMP-FX and 1xEV-DO RNC feature interactswith no other features.


The AT Trace Enhancement for Customer Use feature is dependent on the followingfeatures:

• 1xEV-DO Trace Tool (FID 9253.0)

• 1xEV-DO Tool Interface between OMP-FX and 1xEV-DO RNC (FID 9253.2)

1xEV-DO Trace Tool (FID 9253.0)

This feature will allow tracing of all the network elements involved in a specific usersession including cell, RNC and PDSN.


The 1xEV-DO Tool Interface between OMP-FX and 1xEV-DO RNC feature provides anew interface between the OMP-FX and the ORCA-RNC for OMC-RAN managedRNCs.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


12-15


Introduction

For detailed information about the 1xEV-DO Performance Monitoring ToolsEnhancements feature service measurements, see CDMA2000® 1xEV-DO NetworkService Measurements,401-614-326.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Introduction

The following information describes the impact of the 1xEV-DO PerformanceMonitoring Tools Enhancements feature on input messages and output messages in theTechnician Interface (TI).

Collecting the EVDO SES Data. SES session status

Once theevstartses process starts a study, the data is ready to be collected after onehour of automatic completion of the study or stopping the study by a user. A user candetermine if a SES session is currently running by entering

• evstatusses

Specifying Stop Option

A user can stop a study gracefully by adding–s option to theevstartses command.The following command stops a study which has already been started:

• evstartses –s

The early stop command collects files from RNCs and aggregates them on an hourlybasis.

EVDO SES Output Format

The output file consists of header lines and records. The output file may have aWarning line if there is an error such as incomplete data. The header lines contain thefile content and version, the service node, the requested duration, start and end times,whether the session terminated normally or not, a list of requested histograms in thestudy, and a list of RNCs/BTSs that participated in the study. TheWarning line is usedto specify that an error occured during the collection of the data.

Files generated by the SES tool on the OMP are kept for no longer than 10 days andpurged if not otherwise removed. The user can prevent a file from being deleted bymoving it into a different directory or renaming the file.

Manual Page for evstatusses

ABSTRACT

evstatusses - A tool to query the status of an EVDO Special

Engineering Study (SES).

USAGE

evstatusses [ -h ] | [ -o File_name


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


12-17

DESCRIPTION

This program queries the status of an SES session throughout

all 1xEV RNCs in the service node. The result is displayed

at the user’s terminal or may be directed to a file using

standard UNIX directives.

The ″1xEV-DO Performance Monitoring Special Engineering Studies

Tool″ FAF takes no effect on the execution of this pro-

gram.

NOTE: The status query will execute even when there was no

evstartses process running on the OMP. In this case, a message

will be printed on the user’s terminal to indicate that no SES

session was running. evstatusses always queries the session status

on all 1xEV RNCs, even if they had never participated in the SES

session.

OPTIONS


-h displays the usage of the command.

NOTE: Option -h cannot be used together with

another option.

-o File_Name is used to specify the name of the status query report

file.

The file name is a string that could be up to

255 characters long. Valid values for charac-

ters are: A-Z, a-z, 0-9, .(dot), _(under-

score) and -(hyphen).

If an invalid character is used and an error

message will be printed indicating invalid

file name.

Valid file name examples: ″Genius″,

″EVses.status″, ″evses_011106.rpt″,

″temp.01-11-06″



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Invalid file name examples: ″evses 01-11-06″,

″evses-01/11/06″

NOTE: Option -o cannot be used together with another option.

EXAMPLES

evstatusses

Query the session status and print the

result to the user’s terminal.

evstatusses -o SESstatus

SESstatus Query the session status and store the status report in file

″/omp-data/logs/ses/evdo_files/SESstatus″.

FILES

/omp/bin/evstatusses

/omp-data/logs/ses/evdo_files: where status report file is

stored when -o option is given in command line.

DIAGNOSTICS

If the status query completes successfully on at least one

1xEV RNC, evstatusses exits with an exit code of zero. Otherwise

1 will be returned to indicate that the attempt of

status query failed.

The following table lists some of the possible error messages.

Exit Code Message

1 ERROR: Duplicated option -%c prohibited

1 ERROR: Invalid syntax

1 ERROR: Invalid option - -%c

1 ERROR: Option -%c requires an argument

1 ERROR: Invalid argument for option -o.

Refer to man page of evstatusses for the naming convention of a UNIX

file

1 ERROR: Option -%c cannot be duplicated,

or be used together with another option

1 Usage: evstatusses [-h] | [-o FILE_NAME] for example:



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


12-19

1. evstatusses

2. evstatusses -o evses.status

3. evstatusses -h

1 ERROR: Failed to query status of the session

Manual Page for evstartses

ABSTRACT

evstartses - A tool to start or stop an EVDO Special

Engineering Study (SES)

USAGE

evstartses [ [-t Time] [-d Hist_List] [ [-r RNC_List] | [-b

BTS_Num] ] [-o Suffix_Name] ] | [-h] | [-s] | [-P]

DESCRIPTION

This program starts an EVDO Special Engineering Study on

1xEV RNCs, which are either specified by the user or, as the

default, all RNCs that are configured in SMconfig.data file

User can also stop the current study prematurely by running

this program with -s option, study data generated by that

time on participating RNCs will be collected.

If a user attempts to start a new EVDO SES study before the

end of currently running study, the request will be refused.

The early stop to a living SES session is allowed only when

the SES study is running on RNCs. Under the condition that

session has not yet been started successfully on RNCs or has

changed to collection status, command evstartses -s exits

with error.

The ″1xEV-DO Performance Monitoring Special Engineering Studies

Tool″ FAF must be active to start EVDO SES study. When

the FAF is off, however, user can still run command

evstartses -s to stop a running SES study and start collection

immediately.



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

NOTE: Raw data files retrieved from all participating RNCs

will be aggregated into one study report file on hourly

basis on OMP. A hourly aggregated study report file may consume

maximum of 5.7 megabytes of disk space on the OMP-FX in

the directory /omp-data/logs/ses/evdo_files. The output

files will be removed after 10 days. As a result, if the

maximum configured EVDO RNC number is 6, there will be maximum

240 files if the user collects 24 hours every day for

10 days, and the total disk space occupied by SES aggrega-

tion files may be around 1.4GB. The ″disk_audit″ tool can be

used to ensure that space is available on the OMP.

OPTIONS


-t Time The Duration of study in hours (1 - 24). The

default is 1 hour.

-d Hist_List The histogram counts list separated by commas

or hyphen (e.g. 1,2,4,5 or 1-3). The list may

contain one or more of the following numbers:

1 - Datalink DL throughput

2 - Datalink UL throughput

3 - Percent busy

4 - Short Term RSSI

5 - Long Term RSSI

6 - all, which is the default

NOTE: Number 6 is mutually exclusive with

other numbers.

-r RNC_List The RNC number list separated by commas or

hyphen (e.g. 1,10,15 or 20-22,18). Value of

the number ranges from 1 to 28. No more than

6 RNCs can be included in the list.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


12-21

NOTE: This option is mutually exclusive with

option -b.

-b BTS_Num The BTS number. Value of the number ranges

from 1 to 600.

NOTE: This option is mutually exclusive with

option -r.

-o Suffix_Name Suffix name of SES study report file.

When suffix name is given in command line,

the aggregation file name is composed of this

suffix name together with time stamp prefix,

looking like: yyyyMMddhhmmss.suffix_name. The

file name is a string that could be up to 255

characters long. Valid values for characters

are: A-Z, a-z, 0-9, .(dot), _(underscore) and

-(hyphen).

If an invalid character is used an error

message will be printed indicating invalid

file name.

Valid suffix name examples: ″Genius″,

″EVses.dat″, ″evses_011106.rpt″, ″01-11-06″,

Invalid suffix name examples: ″evses 01-11-

06″, ″evses-01/11/06″

-h displays the usage of the command.

NOTE: Option -h cannot be used together with

other options.

-s Stop the SES study prematurely.

NOTE: Option -s cannot be used together with

NOTE: Option -

-P Retrieve arguments for option -t, -d, -r, -b

and -o in prompt mode.



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

NOTE: Option -P cannot be used together with

another options.

EXAMPLES

evstartses starts an EVDO SES study for 1 hour on

all configured RNCs and BTSs in the service node.

The study covers all histo-gram counts.

Final study report file is with name in format:

yyyyMMddhhmmss.ServiceNode.

evstartses -t 10 starts an EVDO SES study for 10 hours

evstartses -d 5,1-3 -r 1,10,15-17 -o omptech

starts an EVDO SES study for 1 hour on

RNC1, 10, 15, 16, 17. The study covers

all histogram counts except Short Term

RSSI. Report file has the name of

yyyyMMddhhmmss.omptech.

evstartses -h displays the usage message for the user

FILES

/omp/bin/evstartses

/omp-data/logs/ses/evdo_files: where aggregated files are

stored

/omp-data/logs/ses/log_files: where log files are stored

/omp-data/logs/ses/raw_files: where raw data files are

stored

/omp-data/logs/ses/temp_files: where temporary files are

stored

DIAGNOSTICS

If the session starts successfully on at least one 1xEV RNC,

evstartses exits with an exit code of zero. Otherwise 1 will

be returned to indicate that the attempt to start the session failed.

In both cases, a list of RNCs on which the study started and some



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


12-23

error messages are sent to the standard out.

The following table lists some of the possible error messages.

Exit Code Message

1 ERROR: Duplicated option -%c prohibited

1 ERROR: Invalid syntax

1 ERROR: Invalid option - -%c

1 ERROR: Option -%c requires an argument

1 ERROR: Option -%c and option -%c cannot be

used together

1 ERROR: Invalid value for option -t. Valid

range is from 1 to 24. Try again

1 ERROR: Invalid value for option -d. Valid

list can only include comma, hyphen and

number from 1 to 6. Try again

1 ERROR: Invalid value for option -r. Valid

list can only include comma, hyphen and

number from 1 to 28 and no more than total 6

1 ERROR: Invalid value for option -b. Valid

range is from 1 to 600. Try again

1 ERROR: Invalid argument for option -o. Refer

to man page of evstartses for the naming convention

of a UNIX file

1 ERROR: Option -%c cannot be used with other

options

1 ERROR: Failed on receiving valid argument of

option -%c for three times. evstartses exits

1 Usage: evstartses [ [-t Time] [-d Hist_List]

[-r RNC_List] [-b BTS_List] [-o file] ] | [-

h] | [-s] | [-P] for example:

1. evstartses



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

2. evstartses -t 10 -d 1,2 -r 1-5 -o Genius

3. evstartses -t 24 -d 6 -b 599

4. evstartses -h

5. evstartses -s

6. evstartses -P

1 ERROR: Failed to input argument for option

-%c for up to %d times, evstartses exits

1 ERROR: Failed to initiate evstartses process

1 ERROR: Feature activation access failure,

evstartses exits

1 ERROR: 1xEV SES feature is not active,

evstartses exits

1 ERROR: Another evstartses process exists.

Wait for it to stop before trying again or run

evstartses -s command to stop it prematurely

1 ERROR: Failed to start a new SES session,

evstartses exits

1 ERROR: Failed to stop the SES session,

evstartses exits

1 ERROR: Failed to retrieve raw data files on

RNCs, evstartses exits

1 ERROR: Failed to do aggregation on OMP for

the session, evstartses exits



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


12-25


Overview

To implement the 1xEV-DO Performance Monitoring Tools Enhancements features,perform the following procedure:

“Activating the feature: 1xEV-DO Performance Monitoring Tools Enhancements”(p. 12-27)

“Activating the feature: AT Trace Enhancement for Customer Use” (p. 12-28)


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Activating the feature: 1xEV-DO Performance MonitoringTools Enhancements...................................................................................................................................................................................................................................

Purpose

This procedure activates the 1xEV-DO Performance Monitoring Tools Enhancementsfeature in a 1xEV-DO Network.

Procedure


...................................................................................................................................................................................................


1xEV-DO Performance Monitoring Special Engineering Studies Tool

E N D O F S T E P S...................................................................................................................................................................................................


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


12-27

Activating the feature: AT Trace Enhancement for CustomerUse...................................................................................................................................................................................................................................

Purpose

This procedure activates the AT Trace Enhancement for Customer Use feature in a1xEV-DO Network.

Procedure


...................................................................................................................................................................................................


1xEV-DO AT Trace Enhancement

E N D O F S T E P S...................................................................................................................................................................................................


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Manual Pages: AT Trace Enhancement for Customer Use...................................................................................................................................................................................................................................

Manual Page for evstarttr

evompfx100> evstarttr -h

USAGE

/omp/bin/evstarttr <-u uati|-i imsi|-e esn|-m meid> [-d duration]

[-r RAN_Interface_List] [-l] [-o] [-v]} [-h]

WHERE

-u uati - UATI # as 8-digit hex number with 0x prefix

-i imsi - IMSI # as 15 digit decimal number

-e esn - ESN # as 8-digit hex number with 0x prefix

-m meid - MEID # as 14 digit hex number with 0x prefix

-d duration - ATTrace test duration, 1..60 (min), this parameter will

default to 15 mins if omitted

-r intf_list - RNC interface list to trace - HAI, A11, A12, A13.

Default is all of these

-l - Enable Raw Format Logging of messages. Default is to log all

messages, including the ancillary information in ASCII format

-o - Override the overload rejection. This option forces the execution

of AT Trace start command even though one or more APs and/or TPs in an

RNC report overload conditions. Default behaviour when overload is

detected is to stop the trace in case the ATID being traced in UATI.

-v - Enables verbose mode that prints additional details contained in

the AT Trace response.

-h - prints the above help message

Note: If evstarttr with the -o option is used, then later, the TP used

in the AT Trace reports overload conditions, AT Trace data collection

will stop at the TP (SFM) only.

Manual Page for evstoptr

evompfx100> evstoptr -h

USAGE

/omp/bin/evstoptr <-u uati| -i imsi | -e esn | -m meid> [-h] [-v]

WHERE


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


12-29

-u uati - UATI # as 8-digit hex number with 0x prefix

-i imsi - IMSI # as 15 digit decimal number

-e esn - ESN # as 8-digit hex number with 0x prefix

-m meid - MEID # as 14 digit hex number with 0x prefix

-v - Enables verbose mode that displays additional information

regarding the AT Trace RNC responses on the screen.

-h - display on-line help

Manual Page for evstatustr

evompfx100 root> evstatustr -h

USAGE

evstatustr [-x|-c] [-h]

WHERE

-x - prints details of the recently completed evstarttr commands (max

10)

-c - print details of currently running AT trace sessions

-h - prints this usage message

Default is to provide both the -x and -c outputs if no command line

arguments are present


Manual Pages: AT Trace Enhancement for Customer Use

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

13 13Intra-Radio Network Controller(RNC) Session ResourceBalancing in EVolution DataOptimized (1xEV-DO)

Overview...................................................................................................................................................................................................................................

Purpose

This document describes the Intra-Radio Network Controller (RNC) Session ResourceBalancing in EVolution Data Optimized (1xEV-DO) optional feature in theCDMA2000® 1xEV-DO network.

Feature summary

The Intra-RNC Session Resource Balancing in 1xEV-DO allows the system to transferthe control Overhead Manager (OHM) function from the Serving OHM, if the sessionloading of the Serving OHM exceeds a certain threshold, minimizing the chance ofdraining the session resource of a few Adjunct Processors (APs) while other APs stillhave ample capacity. The session resource balance function in Intra-RNC SessionResource Balancing in 1xEV-DO covers the intra-RNC case.


A unique Feature Identifier (FID) is assigned to each feature:

• Intra-RNC Session Resource Balancing in 1xEV-DO (FID12458.0)


The Intra-RNC Session Resource Balancing in 1xEV-DO affects the user interfaces thatare listed in the following table.


Feature Element Management System(EMS) or Operations and Maintenancecenter - Radio Access Network(OMC-RAN)

None

....................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


13-1




None


See“Impacts on TI messages” (p. 13-11)

Intended audience

This document is intended for technicians, engineers, and system administrators whoimplement or maintain the Intra-RNC Session Resource Balancing in 1xEV-DO(FID12458.0) feature in aCDMA2000® 1xEV-DO network.



Contents

Availability 13-3

Prerequisites 13-4






Intra-Radio Network Controller (RNC) Session ResourceBalancing in EVolution Data Optimized (1xEV-DO)

Overview

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Availability...................................................................................................................................................................................................................................


The Intra-RNC Session Resource Balancing in 1xEV-DO feature is available in ECPReleases 29.0 and later.

Market availability

The Intra-RNC Session Resource Balancing in 1xEV-DO feature is available in allmarkets.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


13-3

Prerequisites...................................................................................................................................................................................................................................

Introduction

The Intra-RNC Session Resource Balancing in 1xEV-DO feature has the followingprerequisites.


The Intra-RNC Session Resource Balancing in 1xEV-DO feature is supported in thefollowing air-interface technologies:

• 1xEV-DO

HLR configuration

The Intra-RNC Session Resource Balancing in 1xEV-DO feature does not use a HomeLocation Register (HLR) configuration.


The Intra-RNC Session Resource Balancing in 1xEV-DO feature requires ECP Release29.0 or later.


The Intra-RNC Session Resource Balancing in 1xEV-DO feature requires no hardwarebeyond the standard hardware in aCDMA2000® 1xEV-DO network.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Introduction

The following information describes the functionality, benefits, and operation of theIntra-RNC Session Resource Balancing in 1xEV-DO (FID12458.0) feature.

Functionality

The Intra-RNC Session Resource Balancing in 1xEV-DO feature replaces existingsession establishment/releases related per AP Service Measurement (SM) counts withper OHM SM counts, improving data correlation. It also balances sessions.

Benefits

The Intra-RNC Session Resource Balancing in 1xEV-DO improves the RNC to handleUATI session resource more efficiently, minimizing the chance of draining the sessionresource of a few APs while other APs in the system still have ample capacity to serveuser sessions. The Intra-RNC Session Resource Balancing in 1xEV-DO focuses mainlyon improving the UATI session resource loading distribution, processor loading andperformance impacts are also taken into consideration in the balancing algorithm.


The Intra-RNC Session Resource Balancing in 1xEV-DO provides greater flexibility inbalancing session use within each RNC. The Intra-RNC Session Resource Balancing in1xEV-DO implements an UATI session balancing scheme to mitigate the UATI sessionimbalance that may occur across OHMs due to an imbalance in cell traffic, andchanges in the session distribution due to AT mobility. Each OHM keeps track of itssession loading, which is the ratio of open UATI sessions to total UATI sessions anOHM can support. When a new session is requested, if the cell serving OHM’s sessionloading exceeds a threshold, it may choose to transfer the session to another lessloaded OHM in the RNC.

The Intra-RNC Session Resource Balancing in 1xEV-DO provides:

• a convenient mechanism for enabling, disabling, and configuring session balancing,accomplished via operator configured parameters.

• warnings and alarms when the session loading is reaching critical levels.

• mechanisms to observe real time session loading status, accomplished via new CLIcommands.

Important! These commands supplement the Service Measurements which providetools for trending.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


13-5

The Intra-RNC Session Resource Balancing in 1xEV-DO is an optional feature. A FAFentry is implemented along with a parameter that allows the operator to enable/disablethe feature on per RNC basis.

Each OHM is in three different session load states:

• Normal state session load is below Intra-RNC UATI session balance threshold

• Balance State session load is between Intra-RNC UATI session balance thresholdand UATI session overload threshold

• Session Overload State session load is above the UATI session overloadthreshold

The OHM considers a session balance only when it is inBalance State or in SessionOverload State . The OHM only transfers a session to another OHM that is in a lowersession load state. When the OHM is in 100% load, it will consider all availableOHMs that are not 100% loaded as an candidate for balancing.

The operator can also view the OHM session loading via two new CLI commands:

• OP:EVDORNC-SESSIONLOAD - provides an RNC wide UATI session loading report

• OP:AP-SESSIONLOAD - provides a UATI session loading report for the OHMassigned to the specified AP, and for the OHM assigned to the mate AP.

Alarms

The Intra-RNC Session Resource Balancing in 1xEV-DO feature introduces two newalrams:

• UATI session overload alarm threshold: If the OHM’s session loadingexceeds this threshold, the RNC generates a major alarm. It is recommended thatthe operator set this threshold above the UATI session overload threshold when thefeature is enabled.

• RNC UATI session overload alarm threshold: If the average aggregate UATIsession loading across all OHMS in the RNC exceeds this threshold, the RNCgenerates a critical alarm.


Feature description

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Introduction

The Intra-RNC Session Resource Balancing in 1xEV-DO feature interacts with noother features.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


13-7


Introduction

The Intra-RNC Session Resource Balancing in 1xEV-DO feature affects the followingcategories of services measurements:

• OHM counts

• HDRC SI counts

• HDRC counts

OHM counts

The Intra-RNC Session Resource Balancing in 1xEV-DO feature affects the 1xEV-DOservice measurements that are identified inTable 13-1, “1xEV-DO servicemeasurements - OHM Counts” (p. 13-8).

Table 13-1 1xEV-DO service measurements - OHM Counts


AVG_SESS_LOAD_OHM Average Session Loading

OHM_SESS_CAPACITY OHM_SESS_CAPACITY

SESS_BAL_REQ_INTRA_RNC_ORIG_OHM

Intra-RNC Session Balance Requests atOriginating OHM

SESS_BAL_UATI_COMPLETE_RCVD_ORIG_OHM

Intra-RNC Session Balance - UATIComplete Message Received

SESS_BAL_SUCCESS_INTRA_RNC_ORIG_OHM

Intra-RNC Successful Session Balances atOriginating OHM

HDRC counts

The Intra-RNC Session Resource Balancing in 1xEV-DO feature affects the 1xEV-DOservice measurement counts in that the OHM is performing the work of making thecount, peg be the Target OHM, instead of the Originating OHM. The affected countsare identified inTable 13-2, “1xEV-DO service measurements - SECT-CARR-HDRCCounts” (p. 13-8).

Table 13-2 1xEV-DO service measurements - SECT-CARR-HDRC Counts


INT_SUBNET_IDLE_TRFR_A13_SIR_RCVD_LATE

Inter-subnet idle transfer A13 sess info rspmsg rcvd late

INT_SUBNET_IDL_TRFR_ATTMPT 1xEV inter-subnet idle transfer attempt


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Table 13-2 1xEV-DO service measurements - SECT-CARR-HDRC Counts(continued)


INT_SUBNET_IDL_TRFR_FAIL_OTHER_REASON

Inter-Subnet Idle Transfer Failures Due toOther Reasons

ISBNT_IDL_TRFR_FAIL_NO_RSP_PRV_SBNET

Inter-Subnet Idle Transfer Failures Due toNo Response from Previous Subnet

ISBNT_IDL_TRFR_FAIL_ORG_PDSN_CANT_CONN

Inter-Subnet Idle Transfer FailuresBecause the Original PDSN CannotConnect

ISBNT_IDL_TRFR_FAIL_RJCT_MSG_RCVD

Inter-Subnet Idle Transfer Failure Becausea Reject Message is Received

ISBNT_IDL_TRFR_FAIL_SRC_IP_ADR_NT_FOUND

Inter-subnet idle transfer attempt fail-SrceIP addr not found


Inter-subnet idle transfer attempt fail-SrceIP addr not found





SESS_SETUP_UATI_ASSGNMT_MSG_SENT




HDRC SI counts

The Intra-RNC Session Resource Balancing in 1xEV-DO feature affects the 1xEV-DOservice measurement counts in that the OHM is performing the work of making thecount, peg be the Target OHM, instead of the Originating OHM. The affected countsare identified inTable 13-3, “1xEV-DO service measurements - SECT-CARR-HDRCCI Counts” (p. 13-9).

Table 13-3 1xEV-DO service measurements - SECT-CARR-HDRC CI Counts


SESS_SETUP_UATI_ASSGNMT_MSG_SENT_Q

Session Setup - UATI AssignmentMessage Sent



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


13-9

Table 13-3 1xEV-DO service measurements - SECT-CARR-HDRC CI Counts(continued)


SESS_SETUP_UATI_COMPLETE_MSG_RCVD_Q

Session Setup - UATI Complete MessageReceived

References

For detailed information about 1xEV-DO service measurements, see, CDMA2000®

1xEV-DO Service Measurements,401-614-326.



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Introduction

The following information describes the impact of the Intra-RNC Session ResourceBalancing in 1xEV-DO feature on input messages and output messages in theTechnician Interface (TI).

Input messages

The following input messages are new commands and support the Intra-RNC SessionResource Balancing in 1xEV-DO feature:

• OP:EVDORNC-SESSIONLOADThe 1xEV-DO RNC supports a command to retrieve the UATI Session Loadingstatus for the RNC.

• OP:AP-SESSIONLOADThe 1xEV-DO RNC supports a command to retrieve the UATI session loadingstatus for the OHM assigned to the AP and the OHM assigned to the AP’s mateAP.

Output messages

In response to theOP:EVDORNC-SESSIONLOAD command, if successful, the RNCprovides the following information in its output report.

Important! The following information is provided if the Intra-RNC SessionResource Balancing in 1xEV-DO (FID12458.0) feature is enabled RNC UATISession Loading (percentage; averaged across the RNC).

The following information is provided if the Intra-RNC UATI Session Status ReportingEnable isy:

• Intra-RNC UATI session balance threshold

• UATI session overload threshold

• Number of OHMs with session loading status = Normal

• Number of OHMs with session loading status = Balance

• Number of OHMs with session loading status = Overload

• Number of open (UATI) sessions - aggregated across the RNC

• Number of open (UATI) sessions without R-P sessions - aggregated across theRNC

• Number of active sessions - aggregated across the RNC

The following per-OHM information is provided regardless of whether the Intra-RNCSession Resource Balancing in 1xEV-DO (FID12458.0) feature is enabled andregardless of the Intra-RNC UATI Session Status Reporting Enable setting.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


13-11

For each active OHM that is assigned to an equipped AP, provide:

• OHM Number

• AP the OHM is active on

• Session loading status: Normal, Balance, Overload, or Unavailable

• Session load (shown as a percentage)

• Number of open (UATI) sessions

• Number of open (UATI) sessions without R-P sessions

Important! If the RNC cannot provide any of the above information, a report anerror message is run with an appropriate reason. If the RNC cannot provideinformation for one or more OHM or if an OHM is not responding, then that OHMis omitted.

In response to theOP:AP-SESSIONLOAD command, if successful, the RNC provides thefollowing information in its output report for the OHM assigned to the AP and theOHM assigned to the mate AP.

The following information is provided if the Intra-RNC UATI Session Status ReportingEnable isy:

• Intra-RNC UATI session balance threshold

• UATI session overload threshold

Per OHM information included in theOP:EVDORNC-SESSIONLOAD report is providedregardless of whether Intra-RNC Session Resource Balancing in 1xEV-DO(FID12458.0) isenabled and regardless of the Intra-RNC UATI Session StatusReporting Enable setting session reporting isenabled:

• List of other OHMs assigned to equipped APs in the RNC

• Session loading status for each OHM

If the OHM is in a pool, but not being used, include the reason why. Valid reasonsinclude:

• OHM session load is 100%

• AP is in overload Intra-RNC

• Session balance feature is disabled

If the RNC cannot provide the above information, it report an error message with anappropriate reason.

If an OHM is not responding, then that OHM is omitted.

References

For detailed descriptions of those input messages, see CDMA2000® Wireless NetworksInput Messages,401-610-055.



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

For detailed descriptions of those output messages, see CDMA2000® WirelessNetworks Output Messages,401-610-055.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


13-13


Overview

The Intra-RNC Session Resource Balancing in 1xEV-DO feature is FAFable.

An operator configurable parameter, Intra-RNC UATI Session Resource BalancingEnable, at the FMS Frame level, is used to enable/disable the feature when theIntra-RNC Session Resource Balancing in 1xEV-DO (FID 12458.0) FAF entry exists.Thresholds to configure the balance algorithm: UATI session load balance thresholdUATI session overload threshold Alarm thresholds: OHM UATI session overload alarmthreshold RNC UATI session overload alarm threshold

Important! While this feature is FAFable, it is also disabled as a default, and needsto be enabled at the FMS Frame level for implementation.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

14 14Inter-User Priority for BestEffort Data Applications(IUPBEDA)

Overview...................................................................................................................................................................................................................................

Purpose

This chapter describes Inter-User Priority for Best Effort Data Applications(IUPBEDA) feature in theCDMA2000® 1xEV-DO network.

Feature summary

The IUPBEDA feature provides levels of Best Effort (BE) data service on the ForwardLink based upon the Inter-User Priority attribute assigned to each user in theAccounting, Authentication, and Authorization (AAA) subscriber profiles. Serviceproviders can set the relative weights associated with each Inter-User Priority value.This feature is available on theCDMA2000®1xEV-DO network.


The Feature Identifier (FID) of the IUPBEDA feature is FID 12171.4.


Important! The OMC-RAN is the only recommended method for enabling the IUPand JP features.

The IUPBEDA feature affects the user interfaces that are listed in the following table:


Accounting,Authentication, andAuthorization(AAA)

See“Impacts on the AAA network element” (p. 14-15).

Automated MessageAccounting (AMA)

None

....................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


14-1


ElementManagement System(EMS)

None

Operations andMaintenance Center- Radio AccessNetwork(OMC-RAN)

See“Impacts on the OMC-RAN network element” (p. 14-17).

Servicemeasurements

See“Impacts on service measurements” (p. 14-23).


None

Intended audience

This document is intended for technicians, engineers, and system administrators whoimplement or maintain the Public Security feature and/or related features in aCDMA2000®1xEV-DO network.



Contents

Availability 14-4

Prerequisites 14-5



Sample call scenarios 14-10

Impacts on the AAA network element 14-15

Impacts on the OMC-RAN network element 14-17


Configuration and implementation considerations 14-26

Inter-User Priority for Best Effort Data Applications(IUPBEDA)

Overview

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008





Adjusting the IUP weight assignments for the Service Node 14-32

Adjusting the IUP weight assignments for a BTS 14-34

Setting Inter-User Priority attribute in AAA subscriber profile 14-36

Enabling the feature 14-37


Overview

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


14-3

Availability...................................................................................................................................................................................................................................


The IUPBEDA feature is available in EVDO Release 29.0 SU29-0002 and later.

Market availability

The IUPBEDA feature is only available for the North American Region (NAR) PublicSafety application.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Prerequisites...................................................................................................................................................................................................................................

Introduction

The IUPBEDA feature has the following prerequisites.


The IUPBEDA feature is supported in the following air-interface technology:

• 1xEV-DO


The IUPBEDA feature has the following software requirements:

• The Base Transceiver System (BTS) software release must be R29.1 or later

• The Radio Network Controller (RNC) software release must be R29.0 SU29-0002or later

• The Operations and Maintenance Center - Radio Access Network (OMC-RAN)software release must be R29.0 SU2 or later

• The 1xEV-DO Application based Quality of Service (QoS) support for High RatePacket Data Revision A (Rev. A) (HRPD Rev. A) (FID 12078.9) must be activated


The IUPBEDA feature requires no other hardware beyond the standard hardware in aCDMA2000® 1xEV-DO network.


The IUPBEDA feature has the following interface requirements:

• The AAA network element must be capable of supporting the Inter-User Priorityattribute in the Subscriber Profile.

• The Packet Data Packet Data Serving Node (PDSN) must be capable of supportingthe Inter-User Priority attribute in the Subscriber QoS Profile.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


14-5


Introduction

The following information describes the functionality, benefits, and operation of theIUPBEDA feature.

Functionality

The IUPBEDA feature provides different levels of Best Effort (BE) data service on theForward Link based upon the inter-user priority in a user’s AAA subscriber profile.The objective is to provide higher though-put for general purpose BE service categorydata traffic to certain users relative to other users (given similar Radio Frequency (RF)conditions).

A set of 8 different inter-user priorities (0 to 7) are supported. Service providers canassign a weight to each of these inter-user priority values and these weights are used toadjust scheduling of the transmission of data packets on the Forward Link (datadownloaded to a user’s terminal) of 1xEV-DO Best Effort data connections.

Benefits

The IUPBEDA feature allows service providers to assign priorities for individual usersand the network will take those priorities into consideration when transmitting packetson the Forward Link. In general, users with a high priority will have improved datathroughput versus users with lower priorities (given similar RF conditions) especiallyunder conditions where network usage is unusually high.


The IUPBEDA feature involves the following activities:

1. The RNC receives the Inter-User Priority value from the PDSN as part of thesubscriber profile from AAA. The Inter-User Priority value is saved for the user’ssession.

2. The RNC calculates the Inter-User Priority weight associated with each call leg bydoing the following:

a. Use the Inter-User Priority Weight value for the serving BTS if a weight valuehas been provisioned for the current Inter-User Priority value in the associatedCell Site table.

b. Otherwise, use the Inter-User Priority Weight value for the current Inter-UserPriority value for the Service Node (SN).


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

3. The RNC passes the Inter-User Priority Weight to each BTS that supports a dataconnection when the connection is established or when a new call leg is added.

4. The BTS accepts the Inter-User Priority Weight and uses this value whenscheduling data packet transmission on the Forward Link of Best Effort dataconnections. This weight is used in conjunction with other factors that affect datapacket transmission scheduling (signal strength).


The IUPBEDA feature allows subscribers with higher priority weights to receive higherdata throughput on the Forward Link of Best Effort data connections than othersubscribers with lower priority weights given the same RF conditions. Subscribers withthe same priority weights and equal signal strength will be given equal treatment bythe BTS when transmitting data packets.

These priority weights have an impact on data throughput only when subscribers withdifferent priority weights are served by the same BTS. Please note that the full impactof these priority weights is most evident when there is a high level of data traffic onthe Forward Link.


The IUPBEDA feature allows the service provider to give select subscribers higherpriority access to Best Effort data services.

Example of feature operation

To illustrate how this feature operates, please consider the following example.

1. A subscriber is assigned an Inter-User Priority of 6 for Best Effort Data in theAAA server.

2. The subscriber initiates a 1xEV-DO Rev A connection using an Access Terminal(AT).

3. The AT is served by BTS 1, BTS 2, and BTS 3, but the Forward Link (FL) is onlytransmitted by the serving (primary) BTS which can provide the AT with thestrongest signal.

Figure 14-1, “Example Application of the Inter-User Priority for Best Effort DataApplications feature” (p. 14-8)shows the AT with an active connection served by thethree BTSs and the associated priority-to-weight mappings. In this example, we shallobserve the effect of these priority-to-weight mappings when support of the ForwardLink switches from one BTS to another.


Feature description

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


14-7

In this example, the priority-to-weight mappings for BTS 1 yield an Inter-User PriorityWeight of 3. The mappings defined for BTS 2 yield a weight of 7.

Please note that BTS 3 has no priority-to-weight mappings defined. In this case, wemust use the system-wide mappings for the SN. Consequently, a weight of 6 will beused on BTS 3.

It should also be noted that in this example different priority weights are being sent toeach of the BTSs associated with the call. The priority weight associated with theserving BTS is the value that will affect scheduling for the FL. If another BTSbecomes the serving BTS, then the priority weight associated with the new servingBTS will then affect the FL scheduling.

Figure 14-1 Example Application of the Inter-User Priority for Best Effort DataApplications feature

Subscriber’s Inter-User Priority = 6

Inter-User Priority WeightInter-UserPriority BTS 1 BTS 2 BTS 3 SN

0 0.25 0.50 Blank 0.50

1 1 1 Blank 1

2 1 2 Blank 2

3 2 3 Blank 3

4 2 5 Blank 4

5 3 6 Blank 5

6 3 7 Blank 6

7 4 8 Blank 7

“unknown” 1 1 Blank 1

Table A: Inter-User Priority Weights

BTS 1

BTS 3

BTS 2

Resulting IUP weight on FL for Best Effort Flow *

• BTS 1 = 3,

• BTS 2 = 7,

• BTS 3 = 6

* = when BTS handles FL transmission


Feature description

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Introduction

The following information describes the interactions that may occur between theIUPBEDA feature and the following features:


• Jurisdictional Priority for Public Safety Users for Best Effort Data (FID 12171.5)

Application Based Quality of Service (QoS) Support for HRPD Rev. A (FID12078.9) feature

The IUPBEDA feature depends on FID 12078.9 for the basic Rev. A interfaces. Forexample, the Inter-User Priority attribute is part of the Subscriber QoS Profile passedby the PDSN and FID 12078.9 provides the support of the Subscriber QoS Profile inthe CDMA2000® 1xEV-DO network. However, there is no other feature interaction.The IUPBEDA feature has no impact on the operation of the Application BasedQuality of Service Support for HRPD Rev. A (FID 12078.9) feature.

Jurisdictional Priority for Public Safety Users for Best Effort Data (FID 12171.5)feature

Although the IUPBEDA feature does not depend on JPPSUBEDA FID 12171.5, theoperation of the IUPBEDA feature can be affected by FID 12171.5. The IUPBEDAfeature calculates the Inter-User Priority Weights to be used for calls (based on theInter-User Priority associated with a user) and handles the adjustment of data packettransmission scheduling in the BTS based on these priority weights. However,JPPSUBEDA FID 12171.5 may adjust the Inter-User Priority values associated withindividual users based upon the defined jurisdictional policies. The adjustment of theInter-User Priority values will, in turn, cause changes in the level of service varioususers will receive on the Forward Link of Best Effort data connections.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


14-9

Sample call scenarios...................................................................................................................................................................................................................................

Introduction

The following information describes call scenarios for the IUPBEDA feature.

Establishment of New Data Session

The call flow in Figure 14-2, “Establishment of New Data Session with Inter-UserPriority” (p. 14-11)describes the successful in initial establishment of a data session inwhich the Inter-User Priority attribute was included in the subscriber profile.

Note, that only the numbered messages are affected by the IUPBEDA feature.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

MessageLabel

Establishment of New Data Session with Inter-User Priority

[1] During the establishment of a data session, the PDSN sends a RADIUSRequest to the AAA server order to retrieve the subscriber profile of theuser.

[2] AAA responds to the RADIUS Request with a RADIUS Response. TheRADUIS Response includes the subscriber profile. The 3GPP2-Inter-User-Priority attribute is included in the subscriber profile.

Figure 14-2 Establishment of New Data Session with Inter-User Priority

PDSN

XonRequest

AT AAA

Session Configuration

RAN

Traffic Channel Establishment

XonResponse

A11 RRQ

A11 RRP

A11 RRQ

A11 RRP

PPP Configuration and Authentication

[1] RADIUSRequest

A11 SU ACK[4] Get QoS Profile

IP Address Assignment

[2] RADIUS Accept

(with Inter-User Priority)[3] A11 Session Update

(with Inter-User Priority)

AttributeUpdateRequest(ReservationKKQoSRequestFWD and Rev)

AttributeUpdateAccept

AttributeUpdateRequest(1 per each bidirectional reservation)

AttributeUpdateAcceptA11 RRQ

A11 RRP

Resv (Traffic Flow Template)

ResvConf


Sample call scenarios

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


14-11

MessageLabel

Establishment of New Data Session with Inter-User Priority

[3] The PDSN accepts the RADIUS Response and forwards the subscriberprofile information to the RAN in the A11 Session Update message. TheInter-User Priority attribute is included as part of the Subscriber QoSProfile attribute.

[4] The RAN (the RNC component of the RAN) receives the A11 SessionUpdate message and stores the Inter-User Priority with the user’s sessiondata.

Reactivation of Existing Data Session

The call flow in Figure 14-3, “Reactivation of existing data session with IUPBEDAenabled” (p. 14-13)describes the successful establishment of a new data connection inwhich an Inter-User Priority value has been specified for the user. In this case, the datasession was established previously, but the active connection was dropped when thedata session became dormant prior to this effort to re-establish the active connection



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

MessageLabel

Reactivation of Existing Data Session with IUPBEDA Enabled

[1] The AT sendsConnectionRequest, RouteUpdate, andReservationOnRequest messages to request the establishment of a BestEffort data connection.

[2] The BTS will then forward the receivedConnectionRequest,RouteUpdate, andReservationOnRequest messages on to the RNC.

[3] The RNC will calculate Inter-User Priority Weight to be sent to BTS1using the Inter-User Priority value in the user’s session data andpriority-to-weight mappings that have been defined for BTS1. If nopriority-to-weight mappings have been defined for BTS1, then thepriority-to-weight mappings for the SN will be used. The calculatedInter-User Priority Weight will be passed to the BTS within theAllocateTrafficChannelReq message.

Figure 14-3 Reactivation of existing data session with IUPBEDA enabled

[1] RU+CR+RoR

[3] AllocateTrafficChannelReq

AllocateTrafficChannelRsp

[2] ACPI (RU+CR+RoR)

SCCPC(TCA+RA)

BTS1AT BTS 2



TCA+ReservationAccept(on Control Channel)

TCC (on RTC)

RPI(TCC)

MobileAcquiredInd

SFPC(RTCAck)RTCAck SFPC(RTCAck)

(InterUserPriority1

&InterUserPriority Weight

1)

RNC

(InterUserPriority2

&

InterUserPriority Weight2)

MobileAcquiredInd

RTCAck

TCC (on RTC) RPI(TCC)



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


14-13

MessageLabel

Reactivation of Existing Data Session with IUPBEDA Enabled

[4] The RNC will calculate Inter-User Priority Weight to be sent to BTS2using the Inter-User Priority value in the user’s session data andpriority-to-weight mappings that have been defined for BTS2. If nopriority-to-weight mappings have been defined for BTS2, then thepriority-to-weight mappings for the SN will be used.

Note: that Inter-User Priority Weightassociated with BTS2 will bedifferent than Inter-User Priority Weight,associated with BTS1 ifdifferent priority-to-weight mappings are defined for BTS1 and BTS2.



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Impacts on the AAA network element...................................................................................................................................................................................................................................

Introduction

The following information describes the impact of the IUPBEDA feature on the AAAnetwork element.

AAA subscriber profile attribute

The IUPBEDA feature affects the AAA subscriber profile attribute that is listed inTable 14-1, “Related AAA subscriber profile attributes” (p. 14-15).

Table 14-1 Related AAA subscriber profile attributes

AAA subscriber profile attribute Impacted by

3GPP2-Inter-User-Priority IUPBEDA - FID 12171.4

JPPSUBEDA - FID 12171.5

3GPP2-Inter-User-Priority attribute

The IUPBEDA feature utilizes the 3GPP2-Inter-User-Priority attribute to hold theinter-user priority for BE data within a subscriber profile. Users that do not have thisattribute provisioned in their subscriber profile will be given the defined treatment forusers with an unknown inter-user priority.

SeeTable 14-2, “3GPP2-Inter-User-Priority attribute format” (p. 14-15)for the detailedformat of the 3GPP2-Inter-User-Priority attribute format. This attribute is defined by3GPP2 standards.

Table 14-2 3GPP2-Inter-User-Priority attribute format

Attribute Name: 3GPP2-Inter-User-Priority

Attribute Type: 26

Vendor ID: 5535

Vendor Type: 139

Vendor Length: 6

Vendor Value: 32 bit integer with low order 3 kilobits indicating inter-userpriority for BE


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


14-15

Important! Some Packet Data Serving Nodes (PDSNs) provide default values forattributes if the PDSN receives no attribute value in the subscriber profile from theAAA network element. In this case, the PDSN is configured to specify a defaultvalue for the Inter-User Priority attribute that is consistent with the serviceprovider’s needs. Please consult the PDSN documentation for more information.


Impacts on the AAA network element

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Impacts on the OMC-RAN network element...................................................................................................................................................................................................................................

Introduction

The following information describes the impact of the IUPBEDA feature on theOMC-RAN network element.

Provisioning for this feature must be through OMC-RAN. Provisioning for this featurecannot be done using ECPC RC/V or EMS.

Introduction

The IUPBEDA feature affects the following OMC-RAN forms:

• FxApx Details –EvDO RNC FAF tab

• FxApx Details –SN General tab

• Cell Site Table Details –Configuration tab

FxApx Details – EvDO RNC FAF tab

This feature adds a new read-only field to theEvDO RNC FAF tab of theFxApx Detailsview that displays the FAF activation status for the feature.

Important! The Enhanced Rev.A feature bundle on this screen must be enabled.

A more detailed description is shown inTable 14-3, “Related fields in EvDO RNCFAF form” (p. 14-17).

Table 14-3 Related fields in EvDO RNC FAF form

Field Name Description Allowed Values

Inter-user priority This read-only field displays the FAFactivation status of the feature.

Note that the Enhanced Rev A featurebundle on this screen must be enabled.

Yes,

No

SeeFigure 14-4, “Snapshot of portion of EvDO RNC FAF form” (p. 14-18)for anexample of the contents of theEvDO RNC FAF tab where the field related to this featureis located.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


14-17

FxApx Details – SN General tab

This feature adds new fields to theSN General tab of theFxApx Details view. Thenew fields added are the feature enable field for the feature and the SN wide weightsassociated with the various Inter-User Priority values. The new fields appear near thebottom of the form.




Enable Inter-user Priority This field is used to enable or disablethe feature.

Note that the QOS_REVA andIUPBEDA FAFs must be activatedbefore this feature can be enabled.

Yes,

No

BE service category flowweight for inter-userpriority: priorityunknown

This field indicates the BE inter-userpriority weight to be used for userswith no available inter-user priorityvalue.

0.25, 0.5, 1-8

BE service category flowweight for inter-userpriority: priority 0

This field indicates the BE inter-userpriority weight to be used for userswith an inter-user priority of 0.

0.25, 0.5, 1-8



0.25, 0.5, 1-8

Figure 14-4 Snapshot of portion of EvDO RNC FAF form


Impacts on the OMC-RAN network element

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Table 14-4 Related fields in EvDO RNC FAF form (continued)




0.25, 0.5, 1-8



0.25, 0.5, 1-8



0.25, 0.5, 1-8



0.25, 0.5, 1-8



0.25, 0.5, 1-8



0.25, 0.5, 1-8

Important! If the serving BTS does not have a priority-to-weight mapping defined(in the Cell Site Configuration Form) for a given Inter-User Priority then thepriority-to-weight mapping defined in theFxAPX SN General Form is used.

SeeFigure 14-5, “Snapshot of portion of SN General form” (p. 14-20)for an exampleof the contents of theSN General tab where the fields related to the feature arelocated.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


14-19

Cell Site Table Details – Configuration tab

This feature adds new fields to theConfiguration tab of theCell Site Table Detailsview. These fields provide a way to override the system-wide weights on a per BTSbasis. The new fields appear at the bottom of the form.

A more detailed description is shown inTable 14-5, “Related fields in Cell SiteConfiguration form” (p. 14-20).

Table 14-5 Related fields in Cell Site Configuration form


BE service category flowweight for inter-userpriority: priorityunknown

This field indicates the BE inter-userpriority weight to be used for userswith no available inter-user priorityvalue when they are served by this cell.

blank, 0.25,0.5, 1-8


This field indicates the BE inter-userpriority weight to be used for userswith an inter-user priority of 0 whenthey are served by this cell.

blank, 0.25,0.5, 1-8



blank, 0.25,0.5, 1-8



blank, 0.25,0.5, 1-8

Figure 14-5 Snapshot of portion of SN General form



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Table 14-5 Related fields in Cell Site Configuration form (continued)




blank, 0.25,0.5, 1-8



blank, 0.25,0.5, 1-8



blank, 0.25,0.5, 1-8



blank, 0.25,0.5, 1-8



blank, 0.25,0.5, 1-8

Important! Note: If the serving BTS has a priority-to-weight mapping defined (inthe Cell Site Configuration Form) for a given Inter-User Priority then thepriority-to-weight mapping defined in theCell Site Configuration Form is used.Otherwise the priority-to-weight mapping defined in theFxAPX SN General Formis used.

SeeFigure 14-6, “Snapshot of portion of Cell Site Configuration form” (p. 14-22).for an example of the contents of theCell Site Configuration Form where thefields associated with this feature are located.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


14-21

References

For more information about these forms and fields, see the followingCDMA2000®

1xEV-DO network documents:


• Alcatel-Lucent 9271 EV-DO Radio Network Controller,401-614-102

Figure 14-6 Snapshot of portion of Cell Site Configuration form



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Introduction

The IUPBEDA feature affects the following category of service measurements:

• HCS service measurements

The new service measurements are included in the HCS service measurement filesstored in the/omp-data/logs/HDR/sm_summary_filesdirectory on the OMP-FX.

The HCS service measurement file names have the format oftimestamp.HCSFMS-frameNum. For example, an HCS service measurement file named″200707271100CDT.HCSFMS026″ will hold counts for the hour following 11:00 AM(CDT) on July 27, 2007 for the HCSs supported by RNC frame number 26.

HCS service measurements

The IUPBEDA feature introduces the HCS service measurements that are identified inTable 14-6, “HCS service measurements” (p. 14-23). The FL_RLP_RATE_PRI countsare measured in kilobits per second.

Important! FL_RLP_RATE_PRI and NUM_PRI SM counts are pegged per sectorof BTS. There are 12 Active BTS in NCR and 36 instances ofFL_RLP_RATE_PRI_0 and same with NUM_PRI_0 per hourly SM file.

Table 14-6 HCS service measurements

Service measurement countlabel Description

FL_RLP_RATE_PRI_0 The average Best Effort service category data rateon the Forward Link for users with inter-userpriority 0.






...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


14-23

Table 14-6 HCS service measurements (continued)





FL_RLP_RATE_PRI_8 The average Best Effort service category data rateon the Forward Link for users with an unknowninter-user priority.

NUM_PRI_0 The number of times a Best Effort service categorydata channel was opened for users with inter-userpriority 0.










...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Table 14-6 HCS service measurements (continued)


NUM_PRI_8 The number of times a Best Effort service categorytraffic channel was opened for users with anunknown inter-user priority.

SeeFigure 14-7, “Sample HCS service measurement report” (p. 14-25)for samplecontents of an HCS service measurements file that includes the new counts that arerelated to this feature.

References


• CDMA2000® 1xEV-DO Service Measurements,401-614-325.

Figure 14-7 Sample HCS service measurement reportFL_BTS_DELAY_TOTAL_PKTS_BE, 70464FL_BTS_DELAY_TOTAL_PKTS_CS, 3070FL_BTS_DELAY_TOTAL_PKTS_CV, 1023FL_BTS_DELAY_TOTAL_PKTS_CPS, 0FL_BTS_DELAY_TOTAL_PKTS_LLMCS, 0FL_BTS_DELAY_TOTAL_PKTS_SMC, 618FL_BTS_DELAY_S_PEAK_BE, 236FL_BTS_DELAY_S_PEAK_CS, 27FL_BTS_DELAY_S_PEAK_CV, 20FL_BTS_DELAY_S_PEAK_CPS, 0FL_BTS_DELAY_S_PEAK_LLMCS, 0FL_BTS_DELAY_S_PEAK_SMC, 19EVM_PCNT_RAB_SET_TO_ONE, 0EVDO_SEC_CARR_HCS_CE_1, -336EVDO_SEC_CARR_HCS_CE_2, -336EVDO_SEC_CARR_HCS_CE_3, -336FL_RLP_RATE_PRI_0, 0FL_RLP_RATE_PRI_1, 88156FL_RLP_RATE_PRI_2, 0FL_RLP_RATE_PRI_3, 254860FL_RLP_RATE_PRI_4, 0FL_RLP_RATE_PRI_5, 0FL_RLP_RATE_PRI_6, 0FL_RLP_RATE_PRI_7, 0FL_RLP_RATE_PRI_8, 0NUM_PRI_0, 0NUM_PRI_1, 17NUM_PRI_2, 0NUM_PRI_3, 9NUM_PRI_4, 0NUM_PRI_5, 0NUM_PRI_6, 0NUM_PRI_7, 0NUM_PRI_8, 0



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


14-25

Configuration and implementation considerations...................................................................................................................................................................................................................................

Introduction

This section provides recommendations and guidelines to be considered prior toconfiguring and activating the IUPBEDA feature.

Define consistent meanings for Inter-User Priority values

It is recommended that each Inter-User Priority value be associated with a specificclass of user and these meanings for Inter-User Priority values should be usedconsistently across the wireless network. 3GPP2 standards define the Inter-UserPriority values 0 to 3 to be used for commercial service and reserve priorities 4 to 7for future use. However, the full range of priorities (0 to 7) can be used onnon-commerical wireless networks created for applications such as public safety.

For an example of assignments of Inter-User Priority values to specific user classes,seeTable 14-7, “Example assignment of Inter-User Priority values” (p. 14-26).

Table 14-7 Example assignment of Inter-User Priority values

Inter-User Priority Value User Type IUP Weight

0 Low priority commercial service 0.5

1 Standard commercial service 1

2 ″Gold″ level commercial service 2

3 ″Platinum″ level commercialservice

3

4 General public safety use 4

5 Police 5

6 Fire 6

7 Disaster response coordinator 7

Table 14-7, “Example assignment of Inter-User Priority values” (p. 14-26)also showsthe Inter-User Priority Weights that could be associated with each priority value. Thisapproach would cause the wireless network to give incrementally higher priority toBest Effort data connections for users as the Inter-User Priority value is increased.

Setting of IUP weight for ″unknown ″ IUP value

Although one can provision the system to assign an IUP weight less than 1 to the″unknown″ IUP value to give such users a″below normal″ priority, this should be doneonly after it has been determined that all expected users have the IUP attribute


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

provisioned in their subscriber profiles. The″unknown″ IUP value only indicates thatthe IUP attribute is not currently available for a user. It does not necessarily indicatethat the user should have below-normal priority.

Until the service provider has checked the AAA subscriber profiles for all expectedusers, it is recommended that the IUP weight for″unknown″ users should remain set to1.

Ensure consistent inter-user priority weight assignments

If service providers use the IUPBEDA feature and plan to provide service to roamersfrom other Service Nodes (SNs), it is recommended that the IUP weights be assignedconsistently across all SNs. This will ensure all SNs treat IUP values in a consistentmanner.

However, if another SN has assumed different meanings for the IUP values and hassignificantly different IUP weight assignments, one could use the jurisdictional policiesof the Jurisdictional Priority for Public Service Users for Best Effort Data(JPPSUBEDA) feature to account for this difference between the SNs.

Adjusting IUP weights to balance impact of priorities

The IUPBEDA feature allows service providers to adjust the weights associated withindividual Inter-User Priority values. Although the default weights can be used in manycircumstances, one may encounter situations where it is desirable to adjust the weightsthat are assigned to the various priority values.

One reason for adjusting the inter-user priority weight assignments is to reduce/increasethe difference between the top and bottom weights in order to balance the impact ofthe IUPBEDA feature on the overall user population. For example, if one wishes togive users with lower priorities a larger share of the data throughput capacity, then theweights for the higher priorities should be reduced. An example of how this can bedone is shown inTable 14-8, “Example of adjusting Inter-User Priority Weights toreduce impact of priorities” (p. 14-27).

Table 14-8 Example of adjusting Inter-User Priority Weights to reduce impactof priorities






2


Configuration and implementation considerations

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


14-27

Table 14-8 Example of adjusting Inter-User Priority Weights to reduce impactof priorities (continued)



5 Police 3

6 Fire 3


Please note that one can adjust the default weight assignments for the SN and/or adjustthe weight assignments for a specific BTS.

Adjusting IUP weights to give different treatment for user classes based on location

Another reason for adjusting the IUP weight assignments is to give different treatmentfor specific classes of users based on location (for a specific BTS or set of BTSs).

For an example of this type of adjustment of IUP weights, seeTable 14-9, “Exampleof adjusting Inter-User Priority Weights for specific user classes” (p. 14-28). In thisexample, users with priority5 are given better data service than users with priority6for this specific BTS.

Table 14-9 Example of adjusting Inter-User Priority Weights for specific userclasses






3


5 Police 6

6 Fire 5


Please note that one can adjust the default weight assignments for the SN and/or adjustthe weight assignments for a specific BTS.



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Introduction

The following information describes the procedures for implementing the IUPBEDAfeature on aCDMA2000® 1xEV-DO network.

Complete configuration and implementation requirements

Ensure that all configuration and implementation considerations have been reviewedbefore implementing the IUPBEDA feature. For more information, see“Configurationand implementation considerations” (p. 14-26).

Procedures

To implement the IUPBEDA feature, perform the following procedures in sequence:



“Adjusting the IUP weight assignments for the Service Node” (p. 14-32)

“Adjusting the IUP weight assignments for a BTS” (p. 14-34)

“Setting Inter-User Priority attribute in AAA subscriber profile” (p. 14-36)

“Enabling the feature” (p. 14-37)


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


14-29


Purpose

This procedure activates the IUPBEDA feature in aCDMA2000® 1xEV-DO RevisionA wireless network.

Execution of this procedure will activate the IUPBEDA feature so the other proceduresfor implementing this feature can be executed.

Important! The feature will not be enabled (call processing will not be affected)until the “Enabling the feature” (p. 14-37)is executed.

Procedure


...................................................................................................................................................................................................


IUPBEDA

...................................................................................................................................................................................................

2 Proceed to“Confirming feature activation” (p. 14-31)

E N D O F S T E P S...................................................................................................................................................................................................


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Purpose

This procedure activates the IUPBEDA feature in aCDMA2000® 1xEV-DO RevisionA wireless network.

Procedure


...................................................................................................................................................................................................

1 Go to theFxApx Details view from the OMC-RAN Network Manager. TheDetailsview can be accessed using either of the following techniques:

• Right click on theFxApx object and select theDetails item from the pop-upmenu.

• Double click on theFxApx object.

...................................................................................................................................................................................................

2 Left click on theEvDO RNC FAF tab of theFxApx Details view and verify the FAFentry has been activated. The IUPBEDA FAF status is displayed at the bottom of thepage as shown below:

E N D O F S T E P S...................................................................................................................................................................................................


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


14-31

Adjusting the IUP weight assignments for the Service Node...................................................................................................................................................................................................................................

Purpose

This procedure is used to adjust the IUP weight assignments used by the IUPBEDAfeature for the entire SN.

Note: These steps are performed using the OMC-RAN Network Manager.

Note: This is an optional step. In some cases, there will be no need to change the IUPweight assignments for a network. This procedure is provided in case there is a need tochange the weights.

Procedure


...................................................................................................................................................................................................

1 Go to theFxApx Details view for the network. TheDetails view can be accessedusing either of the following techniques:



...................................................................................................................................................................................................

2 Left click on theSN General tab of theFxApx Details view.

...................................................................................................................................................................................................

3 Left click on theModify button at the bottom of theSN General page as shownbelow:


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

...................................................................................................................................................................................................

4 Left click on the priority field to be changed and select the desired value from themenu.

...................................................................................................................................................................................................

5 RepeatStep 4as needed to update other IUP weight fields.

...................................................................................................................................................................................................

6 Left click on theOK button of theSN General page.

E N D O F S T E P S...................................................................................................................................................................................................


Adjusting the IUP weight assignments for the ServiceNode

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


14-33

Adjusting the IUP weight assignments for a BTS...................................................................................................................................................................................................................................

Purpose

This procedure is used to adjust the IUP weight assignments used by the Inter-UserPriority feature for a specific BTS. The IUP weights assignments set for a BTS willoverride the IUP weight assignments defined for the SN.


Note: This is an optional step. In many cases, there will be no need to change the IUPweight assignments on a BTS. This procedure is provided in case there is a need tochange the weights for a specific BTS

Procedure


...................................................................................................................................................................................................

1 Expand theORCA Group (if necessary) by performing a left click on the+ next to theORCA Group object.

...................................................................................................................................................................................................

2 Right click onORCA Group ’s do object and selectShowOnTree item from the pop-upmenu.

...................................................................................................................................................................................................

3 Expand theCell Site Table with a left click on the+ next to theCell Site Tableobject.

...................................................................................................................................................................................................

4 Go to theCell Site Table Details view of the selected BTS from the list of BTSsunder theCell Site Table . One can access theDetails view using either of thefollowing techniques:

• Right click on theCell Site Table object and select theDetails item from thepop-up menu.

• Double click on the selectedCell Site.

...................................................................................................................................................................................................

5 Left click on theConfiguration tab of theCell Site Details view.

...................................................................................................................................................................................................

6 Left click on theModify button at the bottom of theCell Site Configuration page asshown below:


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

...................................................................................................................................................................................................

7 Left click on the priority field to be changed and select the desired value from themenu.

Note: If the weight for a priority isblank, then the weight for the SN will be used forthis priority.

...................................................................................................................................................................................................

8 RepeatStep 7as needed to update other IUP weight fields.

...................................................................................................................................................................................................

9 Left click on theOK button at the bottom of theCell Site Configuration page.

E N D O F S T E P S...................................................................................................................................................................................................


Adjusting the IUP weight assignments for a BTS

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


14-35

123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789

Setting Inter-User Priority attribute in AAA subscriber profile...................................................................................................................................................................................................................................

Purpose

This procedure is used to include the Inter-User Priority attribute in AAA subscriberprofiles.

Important! The exact procedures will vary depending on the specific AAA systembeing used. Please refer to the documentation for your AAA system for moreinformation.

Procedure


...................................................................................................................................................................................................

1 Verify that the AAA dictionary includes the definition for the 3GPP2 vendor ID. Thedefinition for the 3GPP2 vendor ID will appear as follows on theVitalAAA® system:

<vendor name=”3GPP2” number=”5535” format=”RFC” />

...................................................................................................................................................................................................

2 Verify that the AAA dictionary includes the definition of the 3GPP2-Inter-User-Priorityattribute as a 3GPP2 Vendor Specific Attribute (VSA). The definition for this attributewill appear as follows on theVitalAAA® system:.

<avp name=”3GPP2-Inter-User-Priority” vendor=”3GPP2”>

...................................................................................................................................................................................................

3 Update subscriber profiles as needed to include the 3GPP2-Inter-User-Priority attribute.The following example shows a sample subscriber profile forVitalAAA® system:

CLIENT_IUP1 User-Password=PASSWORD1 Auth-Type=Local3GPP2-Inter-User-Priority=1Cisco-AVPair=″lcp:cdma-user-class=1″Cisco-AVPair=″ip:addr-pool=pdsn-pool″Callback-Id=01111131371476353GPP2-ESN=60302db4

E N D O F S T E P S...................................................................................................................................................................................................


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Enabling the feature...................................................................................................................................................................................................................................

Purpose

This procedure enables the Inter-User Priority for Best Effort Data Applications(IUPBEDA) feature in aCDMA2000® 1xEvDO network.

Execution of this procedure will cause the network to adjust the priority of datatransmission on the Forward Link for Best Effort service category data connectionsbased upon the Inter-User Priority value assigned to users.

Important! The “Activating the feature” (p. 14-30)procedure must be completedbefore this procedure can be executed.

Procedure


...................................................................................................................................................................................................




...................................................................................................................................................................................................


...................................................................................................................................................................................................



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


14-37

...................................................................................................................................................................................................

4 Left click on theEnable Inter-User Priority field and selectYes.

...................................................................................................................................................................................................

5 Left click on theOK button at the bottom of theSN General page.

E N D O F S T E P S...................................................................................................................................................................................................


Enabling the feature

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

15 15Jurisdictional Priority for PublicSafety Users of Best Effort DataApplications (JPPSUBEDA)

Overview...................................................................................................................................................................................................................................

Purpose

This chapter describes Jurisdictional Priority for Public Safety Users of Best EffortData Applications (JPPSUBEDA) feature in theCDMA2000® 1xEV-DO network.

Feature summary

The JPPSUBEDA feature allows service providers to divide theirCDMA2000®

1xEV-DO network into geographic jurisdictions and adjust the Inter-User Priority valueassociated with users from other jurisdictions based upon policies created for theserving jurisdiction. This feature works in conjunction with the Inter-User Priority forBest Effort Data Applications (IUPBEDA) feature. By adjusting the effective Inter-UserPriority values for users, the JPPSUBEDA feature affects each user’s priority for BestEffort (BE) data service on the Forward Link (as supported by the IUPBEDA feature).This feature is available on theCDMA2000® 1xEV-DO network supporting Revision Aof the 1xEV-DO standard.


The Feature Identifier (FID) of the JPPSUBEDA feature is FID 12171.5.


The JPPSUBEDA feature affects the user interfaces that are listed in the followingtable:


Accounting,Authentication, andAuthorization(AAA)

See“Impacts on the AAA network element” (p. 15-16).

....................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


15-1


Automated MessageAccounting (AMA)

None

ElementManagement System(EMS)

None

Operations andMaintenance Center- Radio AccessNetwork(OMC-RAN)

See“Impacts on the OMC-RAN network element” (p. 15-18).

Servicemeasurements

None


None

Intended audience

This document is intended for technicians, engineers, and system administrators whoimplement or maintain the Public Security feature and/or related features in aCDMA2000®1xEV-DO network.



Contents

Availability 15-4

Prerequisites 15-5



Sample call scenarios 15-11

Impacts on the AAA network element 15-16

Impacts on the OMC-RAN network element 15-18

Jurisdictional Priority for Public Safety Users of BestEffort Data Applications (JPPSUBEDA)

Overview

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Configuration and implementation considerations 15-27




Creating jurisdictions 15-37

Creating OMC-RAN user account restricted to jurisdiction 15-39

Creating jurisdictional policies 15-45

Updating jurisdictional policies 15-47

Making jurisdictional policy assignments 15-49

Making BTS assignments for a jurisdiction 15-56

Viewing BTS assignments for a jurisdiction 15-59

Setting Subscriber Home Area attribute in AAA 15-62

Enabling the feature 15-64

Deactivating the feature 15-66


Overview

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


15-3

Availability...................................................................................................................................................................................................................................


The JPPSUBEDA feature is available in EVDO Release 29.0 SU29-0002 and later.

Market availability

The JPPSUBEDA feature is available only in the North American Region (NAR)Public Safety application.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Prerequisites...................................................................................................................................................................................................................................

Introduction

The JPPSUBEDA feature has the following prerequisites.


The JPPSUBEDA features are supported in the following air-interface technology:

• 1xEV-DO


The JPPSUBEDA feature has the following software requirements:

• The BTS software release must be R29.1 or later

• The RNC software release must be R29.0 SU29-0002 or later

• The OMC-RAN software release must be R29.0 SU2 or later

• The 1xEV-DO Application based Quality of Service (QoS) support for High RatePacket Data Revision A (Rev. A) (HRPD Rev. A) (FID 12078.9) must be enabled

• The Inter-User Priority for Best Effort Data Applications (IUPBEDA) (FID12171.4) must be activated


The JPPSUBEDA feature requires no other hardware beyond the standard hardware ina CDMA2000® 1xEV-DO network.


The JPPSUBEDA feature has the following interface requirements:

• The AAA network element must be capable of supporting the Inter-User Priorityand Subscriber Home Area attributes in the Subscriber Profile.

• The Packet Data Serving Node (PDSN) must be capable of supporting theInter-User Priority and Subscriber Home Area attributes in the Subscriber QoSProfile.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


15-5


Introduction

The following information describes the functionality, benefits, and operation of theJPPSUBEDA feature.

Functionality

The JPPSUBEDA feature allows the network to be divided into geographicaljurisdictions and allows each jurisdiction to manage the jurisdiction assets (BTSequipment) and adjust the priority for visiting subscribers from other jurisdictions. Thisfeature works in conjunction with the IUPBEDA feature.

At high level, the feature can be divided into two areas:

• general support for management of jurisdiction equipment.

• support for different levels of BE data service depending on user’s homejurisdiction.

This feature allows each jurisdiction to define policies to be applied to visitingsubscribers from other jurisdictions. These policies indicate how the inter-user priorityfor visiting subscribers should be adjusted while being served in the visitedjurisdiction. The policies are defined per jurisdiction and will apply to all visitingsubscribers served by that jurisdiction.

Up to 18 jurisdictions are supported in a network. Each jurisdiction is defined as a setof cells. All jurisdictions in the network can share the RNC, PDSN, HA and AAA. TheOMC-RAN supports the creation of jurisdictions and jurisdictional policies and allowsonly authorized groups to manage the jurisdiction equipment and update dataassociated with the jurisdiction. The shared equipment is managed separately bynetwork-level administrators.

The management of the PDSN, HA, and AAA are outside the scope of this document.

Benefits

The JPPSUBEDA feature provides the ability to control priority given to users for BEdata service based upon jurisdictional policies. In addition, administrators for specificjurisdictions can be given access to administer only the equipment associated with theirjurisdiction. These capabilities are especially needed to support data networks to beused by Public Safety agencies.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


The JPPSUBEDA feature involves the following activities:

1. The RNC receives the Inter-User Priority and Subscriber Home Area values fromthe PDSN as part of the subscriber profile from AAA. These values are saved forthe user’s data session along with other subscriber profile attributes.

2. The RNC determines the jurisdiction of the BTS serving each call leg.

3. If the BTS is associated with a jurisdiction and the subscriber’s Home Area is notequal to the jurisdiction of the BTS, then the RNC will adjust the Inter-UserPriority value for the subscriber by applying the appropriate jurisdictional policy asdescribed below:

a. If an entry in the Roaming Policy Assignment table matches the subscriber’sHome Area, apply the policy that is specified by the Roaming PolicyAssignment entry.

b. Otherwise, apply the″Default″ policy for the jurisdiction associated with theBTS.

4. The adjusted Inter-User Priority value is then given the normal treatment by theIUPBEDA feature. The RNC calculates the Inter-User Priority Weight for theeffective Inter-User Priority value and the RNC passes the Inter-User PriorityWeight to each BTS that supports the data connection.

5. The BTS accepts the Inter-User Priority Weight and uses this value whenscheduling data packet transmission on the Forward Link of Best Effort dataconnections. This weight is used in conjunction with other factors that affect datapacket transmission scheduling such as signal strength


The JPPSUBEDA feature can adjust the priority level given to subscribers visitinganother jurisdiction. A subscriber that is″roaming″ (visiting another jursidition) may begiven a lower (or higher) priority than what they normally receive in their homejurisdiction. Otherwise, this feature is transparent to the subscriber.

Please note that this feature does not affect the priority level given to subscriberswithin their home jurisdictions. This feature also does not affect the priority level if theserving BTS is not associated with a jurisdiction.


The JPPSUBEDA feature allows the service provider to divide a wireless network intojurisdictions and define policies to adjust the priorities for subscribers that are visitingfrom other jurisdictions.


Feature description

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


15-7

Example of feature operation

To illustrate how this feature operates, please consider the following example

1. A subscriber is assigned an Inter-User Priority value of 6 for Best Effort Data inthe AAA server.

2. The Home Area for subscriber is defined to be jurisdiction 3.

3. The subscriber initiates a 1xEV-DO Rev A connection using an Access Terminal(AT).

4. The AT is served by BTS 1, BTS 2, and BTS 3. The Forward Link (FL) is onlytransmitted by the serving (primary) BTS.

Figure 15-1, “Example Application of the Jurisdictional Priority feature” (p. 15-9)shows the BTSs serving a user’s AT, the jurisdictional policies, the policy assignments,and the associated priority-to-weight mapping for this example.

In this example, the Serving Inter-User Priority for each serving BTS is determined asfollows:

1. Policy ″A″ of jurisdiction 1 is applied on BTS 1 and yields an adjusted priorityvalue of 6.

2. Policy ″C″ of jurisdiction 2 is applied on BTS 2 and yields an adjusted priorityvalue of 3.

3. No policy is applied on BTS 3 since BTS 3 is in the subscriber’s home jurisdiction.Consequently, the priority value remains unchanged (6).

The priority-to-weight mapping for priority 6 on BTS 1 yields a priority weight of 3.The mapping for BTS 2 yields a priority weight of 3 given a priority value of 3. SinceBTS 3 has no priority-to-weight mappings defined, we must use the system-widemappings for the SN. Consequently, a priority weight of 6 will be used on BTS 3.

To review the results, please consider the following:

• A priority weight of 3 will be used on BTS 1 due to the priority-to-weightmappings on that BTS. The user is visiting another jurisdiction when it is served byBTS 1. However, the policy applied (Policy″A″) didn’t change the user’sInter-User Priority value.

• A priority weight of 3 will also be used on BTS 2, but for very different reasons.In this case, the jurisdictional policy applied (Policy “C”) changed the Inter-UserPriority from 6 to 3.

• A priority weight of 6 will be used on BTS 3 because BTS 3 is the user’s homejurisdiction. Consequently, no policy will be applied and the Inter-User Priority willnot be changed.


Feature description

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Figure 15-1 Example Application of the Jurisdictional Priority feature

BTS 1

(J1)

BTS 3

(J3)

BTS 2(J2)

Resulting IUP weights on FL for Best Effort Flow *

• BTS 1 = 3,

• BTS 2 = 3,

• BTS 3 = 6

* = when BTS handles FL transmission

Subscriber’s Inter-User Priority = 6

Subscriber’s Home Area = J3

ServingJurisdiction

Roamer HomeJurisdiction

Roamer Policy

J1 J2 “A”

J1 J3 “A”

J2 J1 “B”

J2 J3 “C”

Table B1: Jurisdictional Roamer Policy Assignment

Serving Inter-User PriorityHomeInter-User

PriorityJ1 Policy

“A”J2 Policy

“B”J2 Policy

“C”

0 0 0 0

1 1 1 1

2 2 2 1

3 3 3 2

4 4 4 2

5 5 5 3

6 6 5 3

7 7 5 4

Table B2: Jurisdictional Roamer Policy

Inter-User Priority WeightInter-UserPriority BTS 1 BTS 2 BTS 3 SN

0 0.25 0.50 Blank 0.50

1 1 1 Blank 1

2 1 2 Blank 2

3 2 3 Blank 3

4 2 5 Blank 4

5 3 6 Blank 5

6 3 7 Blank 6

7 4 8 Blank 7

“unknown” 1 1 Blank 1

Table B3: Inter-User Priority Weights


Feature description

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


15-9


Introduction

The following information describes the interactions that may occur between theJPPSUBEDA feature and the following features:


• Inter-User Priority for Best Effort Data Applications (IUPBEDA) (FID 12171.4)

Application Based Quality of Service (QoS) Support for HRPD Rev. A (FID12078.9) feature

The IUPBEDA feature depends on FID 12078.9 for the basic Rev. A interfaces. Forexample, the Inter-User Priority attribute is part of the Subscriber QoS Profile passedby the PDSN and FID 12078.9 provides the support of the Subscriber QoS Profile inthe CDMA2000® 1xEV-DO network. However, there is no other feature interaction.The IUPBEDA feature has no impact on the operation of the Application BasedQuality of Service Support for HRPD Rev. A (FID 12078.9) feature.

Inter-User Priority for Best Effort Data Applications (IUPBEDA) (FID 12171.4)feature

The JPPSUBEDA feature depends on IUPBEDA (FID 12171.4) for support of differentpriority access on the Forward Link for Best Effort data connections. TheJPPSUBEDA feature adjusts the Inter-User Priority value associated with individualusers, but the calculation of the Inter-User Priority Weights and the adjustment of thescheduling of data packet transmission in the BTS is based on these priority weightsthat are supported by the IUPBEDA (FID 12171.4).


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Sample call scenarios...................................................................................................................................................................................................................................

Introduction

The following information describes call scenarios for the JPPSUBEDA feature.

Establishment of New Data Session

The call flow in Figure 15-2, “Establishment of New Data Session with Home AreaAttribute” (p. 15-12)describes the successful initial establishment of a data session inwhich the Inter-User Priority and Home Area attributes are included in the subscriberprofile.

Note: Only the numbered messages are affected by the JPPSUBEDA feature.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


15-11

MessageLabel

Establishment of New Data Session with Home Area Attribute

[1] During the establishment of a data session, the PDSN sends a RADIUSRequest to the AAA server order to retrieve the subscriber profile of theuser.

Figure 15-2 Establishment of New Data Session with Home Area Attribute

PDSN

XonRequest

AT AAA

Session Configuration

RAN

Traffic Channel Establishment

XonResponse

A11 RRQ

A11 RRP

A11 RRQ

A11 RRP

PPP Configuration and Authentication

[1] RADIUSRequest

A11 SU ACK[4] Get QoS Profile

IP Address Assignment

[2] RADIUS Accept

(with Inter-User Priority& Home Area)

[3] A11 Session Update

(with Inter-User Priority

& Home Area)

AttributeUpdateRequest(ReservationKKQoSRequestFWD and Rev)

AttributeUpdateAccept

AttributeUpdateRequest(1 per each bidirectional reservation)

AttributeUpdateAcceptA11 RRQ

A11 RRP

Resv (Traffic Flow Template)

ResvConf



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

MessageLabel

Establishment of New Data Session with Home Area Attribute

[2] An AAA responds to the RADIUS Request with a RADIUS Response.The RADUIS Response includes the subscriber profile. The3GPP2-Inter-User-Priority and Lucent-Vendor ID (VID)-Subscriber-HomeArea attributes are included in the subscriber profile.

[3] The PDSN accepts the RADIUS Response and forwards the subscriberprofile information to the RAN in the A11 Session Update message. TheInter-User Priority and Home Area attributes are included as part of theSubscriber QoS Profile attribute.

[4] The RAN (the RNC component of the RAN) receives the A11 SessionUpdate message and stores the Inter-User Priority and Home Areaattributes with the user’s session data.

Reactivation of Existing Data Session

The call flow in Figure 15-3, “Reactivation of existing data session with JPPSUBEDAenabled” (p. 15-14)describes the successful establishment of a new data connection inwhich the JPPSUBEDA feature has adjusted the Inter-User Priority value for the user.In this case, the data session was established previously, but the active connection wasdropped when the data session became dormant prior to this effort to re-establish theactive connection.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


15-13

MessageLabel

Reactivation of Existing Data Session with JPPSUBEDA Enabled

[1] The AT sendsConnectionRequest, RouteUpdate, andReservationOnRequest messages to request the establishment of a BestEffort data connection.

[2] The BTS will then forward the receivedConnectionRequest,RouteUpdate, andReservationOnRequest messages on to the RNC.

[3] The RNC will apply the appropriate jurisdictional policy given the user’sHome Area. It will also calculate Inter-User Priority Weight to be sent toBTS1 using the adjusted Inter-User Priority value and priority-to-weightmappings that have been defined for BTS1. If no priority-to-weightmappings have been defined for BTS1, then the priority-to-weightmappings for the SN will be used.

Figure 15-3 Reactivation of existing data session with JPPSUBEDA enabled

[1] RU+CR+RoR



[2] ACPI (RU+CR+RoR)

SCCPC(TCA+RA)

BTS1AT BTS 2



TCA+ReservationAccept(on Control Channel)

TCC (on RTC)

RPI(TCC)

MobileAcquiredInd

SFPC(RTCAck)RTCAck SFPC(RTCAck)

(InterUserPriority1

&InterUserPriority Weight

1)

RNC

(InterUserPriority2

&

InterUserPriority Weight2)

MobileAcquiredInd

RTCAck

TCC (on RTC) RPI(TCC)



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

MessageLabel

Reactivation of Existing Data Session with JPPSUBEDA Enabled

[4] The RNC will apply the appropriate jurisdictional policy given the user’sHome Area. It will also calculate Inter-User Priority Weight to be sent toBTS2 using the adjusted Inter-User Priority value and priority-to-weightmappings that have been defined for BTS2. If no priority-to-weightmappings have been defined for BTS2, then the priority-to-weightmappings for the SN will be used.

Inter-User Priority (2) can be different than Inter-User Priority (1) ifBTS1 and BTS2 are in different jurisdictions and would consequently beaffected by different policies.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


15-15

Impacts on the AAA network element...................................................................................................................................................................................................................................

Introduction

The following information describes the impact of the JPPSUBEDA feature on theAAA network element.

AAA subscriber profile attribute

The JPPSUBEDA feature affects the AAA subscriber profile attribute that is listed inTable 15-1, “Related AAA subscriber profile attributes” (p. 15-16).

Table 15-1 Related AAA subscriber profile attributes

AAA subscriber profile attribute Impacted by

3GPP2-Inter-User-Priority IUPBEDA - FID 12171.4

JPPSUBEDA - FID 12171.5

Lucent-VID-Home-Area JPPSUBEDA - FID 12171.5

3GPP2-Inter-User-Priority attribute

The IUPBEDA and JPPSUBEDA features use the 3GPP2-Inter-User-Priority attributeto hold the inter-user priority for BE data within an AAA subscriber profile. Users thatdo not have this attribute provisioned in their subscriber profile will be given thedefined treatment for users with an unknown inter-user priority.

SeeTable 15-2, “3GPP2-Inter-User-Priority attribute format” (p. 15-16)for the detailedformat of the 3GPP2-Inter-User-Priority attribute format. This attribute is defined by3GPP2 standards.

Table 15-2 3GPP2-Inter-User-Priority attribute format

Attribute Name: 3GPP2-Inter-User-Priority

Attribute Type: 26

Vendor ID: 5535

Vendor Type: 139

Vendor Length: 6

Vendor Value: 32 bit integer with low order 3 bits indicating inter-userpriority for BE


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Important! Some Packet Data Serving Nodes (PDSNs) provide default values forattributes if the PDSN receives no attribute value in the subscriber profile from theAAA network element. In this case, the PDSN is configured to specify a defaultvalue for the Inter-User Priority attribute that is consistent with the serviceprovider’s needs. Please consult the PDSN documentation for more information.

Lucent-VID-Home-Area attribute

The JPPSUBEDA feature utilizes the Lucent-VID-Home-Area attribute to hold thejurisdiction ID of the subscriber’s home area.

SeeTable 15-3, “Lucent-VID-Home-Area attribute format″” (p. 15-17) for the detailedformat of the Lucent-VID-Home-Area attribute. This attribute is a vendor-specificattribute.

Table 15-3 Lucent-VID-Home-Area attribute format ″

Attribute Name: Lucent-VID-Home-Area

Attribute Type: 26

Vendor ID: 3729

Vendor Type: 11

Vendor Length: 4

Vendor Value: 16 bit integer identifying subscriber home jurisdiction


Impacts on the AAA network element

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


15-17

Impacts on the OMC-RAN network element...................................................................................................................................................................................................................................

Introduction

The following information describes the impact of the JPPSUBEDA feature on theOMC-RAN network element. Please note that more detailed information is alsoavailable in the 401-380-835R29 (OA&M) and 401-380-092R29 (OMC-RAN CLI)documents.

Provisioning for this feature must be through OMC-RAN. Provisioning for this featurecannot be done using ECPC RC/V or EMS.

Introduction

The IUPBEDA feature affects the following OMC-RAN forms:

• FxApx Details –EvDO RNC FAF tab

• FxApx Details –SN General tab

• Jurisdiction Group – Serving Jurisdiction Details –Main tab

• Jurisdiction Group – Serving Jurisdiction Details –BTS Allocation tab

• Jurisdiction Group – Serving Jurisdiction Subtree – BERoamPolTable Details

• Jurisdiction Group – Serving Jurisdiction Subtree – RoamPolAssgn Details

• User & Session Manager -User Profile screen

FxApx Details – EvDO RNC FAF tab

This feature adds a new read-only field to theEvDO RNC FAF tab of theFxApx Detailsview that displays the FAF activation status for the feature.




Jurisdictional Priority forPublic Safety Users

This read-only field displays the FAFactivation status of the feature.

Yes,

No

SeeFigure 15-4, “Snapshot of portion of EvDO RNC FAF form” (p. 15-19)for anexample of the contents of theEvDO RNC FAF tab where the fields related toIUPBEDA and JPPSUBEDA are located.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

FxApx Details – SN General tab

This feature adds new fields to theSN General tab of theFxApx Details view. Afeature enable field is added for this feature. The new field appears near the bottom ofthe form.

A more detailed description is shown inTable 15-5, “Related fields in SN Generalform” (p. 15-19).

Table 15-5 Related fields in SN General form


Enable JurisdictionalPriority for Public SafetyUsers

This field is used to enable or disablethe feature.

Note: The QOS_REVA, IUPBEDA, andJPPSUBEDA FAFs must be activatedbefore this feature can be enabled.

Yes,

No

SeeFigure 15-5, “Snapshot of portion of SN General form” (p. 15-20)for an exampleof the contents of theSN General tab where the fields related to the feature arelocated.

Figure 15-4 Snapshot of portion of EvDO RNC FAF form



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


15-19

Serving Jurisdiction Details – Main tab

The JPPSUBEDA feature introduces the Jurisdiction Group and allows up to 18Serving Jurisdictions to be created under the Jurisdiction Group. TheMain tab of theServing Jurisdiction Details view includes only read-only fields since these fields canonly be set when a Serving Jurisdiction is created.

A Serving Jurisdiction instance can be created via the Create – Serving Jurisdictionoperation which is available at the Jurisdiction Group level.

A more detailed description is shown inTable 15-6, “Related fields in ServingJurisdiction Main Details form” (p. 15-20).

Table 15-6 Related fields in Serving Jurisdiction Main Details form


Jurisdiction Id This read-only field is used to displaythe numeric Jurisdiction ID associatedwith the selected Serving Jurisdiction.

1-65535

Jurisdiction name This read-only field is used to displaythe name of the selected ServingJurisdiction.

string up to25characters

SeeFigure 15-6, “Snapshot of Serving Jurisdiction Main Details form” (p. 15-21).foran example of the contents of theMain tab of theServing Jurisdiction Details form.

Figure 15-5 Snapshot of portion of SN General form



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Serving Jurisdiction Details – BTS Allocation tab

The JPPSUBEDA feature allows one or more BTS to be associated with each ServingJurisdiction. TheBTS Allocation tab of theServing Jurisdiction Details view liststhe BTSs that have been assigned to the selected Serving Jurisdiction. This viewincludes only read-only fields since these fields can only be set using the BTSAllocation operation which is available at the Serving Jurisdiction instance level.

A more detailed description is shown inTable 15-7, “Related fields in ServingJurisdiction BTS Allocation Details form” (p. 15-21).

Table 15-7 Related fields in Serving Jurisdiction BTS Allocation Details form


Assigned BTS List This read-only field is used to displaythe list of BTSs that are assigned to theselected Serving Jurisdiction

List of strings

SeeFigure 15-6, “Snapshot of Serving Jurisdiction Main Details form” (p. 15-21)foran example of the contents of the BTS Allocation tab of the Serving JurisdictionDetails form.

Figure 15-6 Snapshot of Serving Jurisdiction Main Details form



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


15-21

Serving Jurisdiction subtree

The JPPSUBEDA feature allows the jurisdictional policies and policy assignments tobe managed using the Serving Jurisdiction subtree. From the subtree view, policies canbe viewed, created, changed and deleted and the policies can be assigned to specificJurisdiction IDs.

The Serving Jurisdiction subtree can be accessed by invoking theShowOnTreeoperation on a Serving Jurisdiction instance under the Jurisdiction Group object.

A more detailed description is shown inTable 15-8, “Objects in Serving Jurisdictionsubtree” (p. 15-22).

Table 15-8 Objects in Serving Jurisdiction subtree

Object Name Description

BERoamPolTable This object holds a list of BERoamPolTable instances.

BERoamPolTableinstances

Each policy defined for this Serving Jurisdiction isrepresented by an instance in the BERoamPolTable subtree.Each of these instances is identified by its assigned PolicyName.

RoamPolAssgn This object holds the set of Roamer Policy Assignments forthis Serving Jurisdiction.

Figure 15-7 Snapshot of Serving Jurisdiction BTS Allocation Details form



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

SeeFigure 15-8, “Snapshot of of Serving Jurisdiction subtree” (p. 15-23)for anexample of a Serving Jurisdiction subtree used to provision data related to theJPPSUBEDA feature. In the example shown below, the Serving Jurisdiction named″J1″ has two policies named″A″ and″B″.

Serving Jurisdiction BERoamPolTable Instance Details

The JPPSUBEDA feature allows one or more BE Roaming Policies to be associatedwith each Serving Jurisdiction. TheBERoamPolTable Details view displays themappings of inter-user priority values that make up the selected policy.

A BE Roaming Policy instance can be created by invoking the Create – BE RoamingPolicy operation on a Serving Jurisdiction object. BE Roaming Policy instances mayalso be changed.

A more detailed description is shown inTable 15-9, “Related fields in theBERoamPolTable Instance Details form” (p. 15-23).

Table 15-9 Related fields in the BERoamPolTable Instance Details form


Name This field is the name of a BE Roamer Policy ofthe current Serving Jurisdiction. The name is setwhen policy is created.


Figure 15-8 Snapshot of of Serving Jurisdiction subtree



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


15-23

Table 15-9 Related fields in the BERoamPolTable Instance Details form(continued)


HomeInter-userPriority (9rows intable)

These read-only fields identify the originalinter-user priority that is being adjusted.

0-7, unknown

ServingInter-userPriority (9rows intable)

These fields indicate the inter-user priority thatwill result when this policy is applied for theassociated home inter-user priority for the currentServing Jurisdiction.

0-7

SeeFigure 15-9, “Snapshot of of Serving Jurisdiction BERoamPolTable Details form”(p. 15-24)for an example of the contents of theServing Jurisdiction BERoamPol-Table Details form. In this example, the″Default″ policy maps all Inter-User Priorityvalues to 1.

Figure 15-9 Snapshot of of Serving Jurisdiction BERoamPolTable Details form



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Serving Jurisdiction RoamPolAssgn Details

The JPPSUBEDA feature allows a BE Roaming Policy to be assigned for subscribersfrom other jurisdictions. If a subscriber’s Home Area matches the Roaming JurisdictionID field of an entry in this table, then the associated policy will be applied. TheRoamPolAssgn Details view displays the set of policy assignments that have beendefined for a specific Serving Jurisdiction.

Roaming Policy Assignment (RoamPolAssgn) instances can be created via theAddbuttons of the form. RoamPolAssgn instances may also be changed or deleted.

A more detailed description is shown inTable 15-10, “Related fields in ServingJurisdiction RoamPolAssgn Details form” (p. 15-25).

Table 15-10 Related fields in Serving Jurisdiction RoamPolAssgn Details form


RoamingJurisdictionId (17 rowsin table)

These fields identify a jurisdiction to which theassociated policy should be assigned.

1-65535

Policy name(17 rows intable)

These fields indicate the policy that will beapplied to subscribers with a Home Area thatmatches the associated Jurisdiction Id.


SeeFigure 15-10, “Snapshot of Serving Jurisdiction RoamPolAssgn Details form”(p. 15-26)for an example of the contents of theServing Jurisdiction RoamPolAssgnDetails form. In this simple example, Policy″A″ will be applied to all users visitingfrom jurisdictions 2 and 3.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


15-25

References

For more information about these forms and fields, see the followingCDMA2000®

1xEV-DO network documents:


• Alcatel-Lucent 9271 EV-DO Radio Network Controller,401-614-102

Figure 15-10 Snapshot of Serving Jurisdiction RoamPolAssgn Details form



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Configuration and implementation considerations...................................................................................................................................................................................................................................

Introduction

This section provides recommendations and guidelines to be considered prior toconfiguring and activating the JPPSUBEDA feature.

Dividing network into jurisdictions

It is recommended that the process of provisioning the JPPSUBEDA feature begin withplanning how the wireless network will be divided into jurisdictions. Since ajurisdiction must be defined (created via OMC-RAN) before it can be referenced byanother jurisdiction, it is recommended that the complete set of jurisdictions be createdbefore proceeding with creation of jurisdictional policies and policy assignments..

When determining the number of jurisdictions required and the exact boundaries of thejurisdictions, the following factors should be considered:

• ownership or funding source of BTS equipment,

• state, county, and city boundaries,

• location of major facilities (for example, airports, sports stadiums),

• terrain and other factors that affect RF propagation.

When planning how a network will be divided into jurisdictions, it is important toconsider that the geographical territory of a jurisdiction is defined by the set of BTSsassigned to it. One also needs to consider the geographical area in which each BTSwill be providing the strongest RF signal. Since the Forward Link for each dataconnection is generally transmitted by the BTS that provides the strongest signal, thegeographical area where the policies of a jurisdiction are in effect is the cumulativefootprint where the associated BTSs are providing the strongest signal for the users.

Addressing jurisdiction border issues

In some cases, the availability of suitable sites for cellular towers and otherconsiderations related to RF engineering may cause the desired geographic boundaryfor a jurisdiction to not fall cleanly on the border of one or more BTSs. The intendedgeographic border may split the service area of multiple BTSs. An example of thissituation is illustrated byFigure 15-11, “Example of geographic border splitting BTSservice areas” (p. 15-28).


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


15-27

In this example, it is planned to create separate jurisdictions for the towns of EastCenterville and West Centerville. However, in order to get proper RF coverage, thecellular towers had to be positioned so that the border between these two towns crossesthe primary service area of multiple BTSs.

One method for resolving jurisdiction border issues is the creation of an additionaljurisdiction for the set of BTSs that lie on the border. A separate set of jurisdictionalpolicies can be created and assigned for this″border″ jurisdiction that treats users fromeither of the adjoining jurisdictions as if they were in their home jurisdiction. Pleasenote that these″border″ jurisdictions would not generally be assigned as the HomeArea for subscribers.

If this technique was applied to the example, the assignment of BTSs to jurisdictionswould be as shown inFigure 15-12, “Example use of border jurisdiction” (p. 15-29).

Figure 15-11 Example of geographic border splitting BTS service areas

East Centerville

West Centerville



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

In this example, jurisdiction 1 is for East Centerville territory, jurisdiction 3 is createdfor the West Centerville territory, and jurisdiction 3 is created for the border areabetween these two towns. Subscribers from these two towns would be assigned aHome Area of either J1 or J3. No users would be given a Home Area of J2.

Ensure unique Jurisdiction IDs across all linked wireless networks

If service providers use the JPPSUBEDA feature and plan to provide service toroamers from other Service Nodes (SNs), it is critical to ensure that Jurisdiction IDsare assigned uniquely across all SNs. If more than one SN uses a Jurisdiction Id, thesystem will assume this jurisdiction spans the associated SNs.

If a user has a Home Area value that matches the Jurisdiction Id of the serving BTS,they are treated as a home subscriber and no jurisdictional policy is applied. If multipleSNs use the same Jurisdiction Id, then a user will be treated as a home subscriber inany of those locations where that Jurisdiction Id is used.

It is recommended that the high order digits of the Jurisdiction Id be used to indicatethe region of the jurisdiction (for example city, county, etc.). For example, one regioncould use Jurisdiction IDs 101 to 118 and another region could use 201 to 218. Sincethe maximum Jurisdiction Id value is 65,535, a total of 655 jurisdiction regions couldbe supported using this simple convention.

Figure 15-12 Example use of border jurisdiction

East Centerville

West Centerville

J1

J1

J1

J1

J1

J1

J1

J1

J3

J3

J3

J3

J3

J3

J3

J3

J2

J2

J2

J2

J2

J2



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


15-29

Determining the set of jurisdictional policies required

After the complete set of jurisdictions has been defined for the network, the set ofjurisdictional policies that will be required to deal with users visiting from otherjurisdictions should be determined.

Each jurisdiction can create up to four policies that can be assigned for roamers fromspecific jurisdictions. In addition, a default policy exists to address the following typesof visiting users:

• users without a Home Area specified in their AAA subscriber profile,

• users visiting from a jurisdiction for which a policy has not been assigned.

In order to get started defining jurisdiction policies, it is recommended to first dividethe set of jurisdictions into groups based upon the treatment to be given to visitorsfrom those jurisdictions. Jurisdictional policies to provide the desired treatment foreach of these jurisdiction groups can then be created.

The following are examples of jurisdictional policies that could be created:

• TreatAsLocal – for roamers to be treated as if they were local users

• AdjustedService – for roamers that should receive better than standard priorityservice

• StandardService – for roamers that should only receive standard priority service

• BasicService – for roamers that should only receive lowest priority service

The adjustments of the IUP values for the sampleTreatAsLocal policy are shown inTable 15-11, “Sample Jurisdictional Policy – TreatAsLocal” (p. 15-30).

Note: This policy gives the visiting users their original Inter-User Priority values (aslong as the priority is known).

Table 15-11 Sample Jurisdictional Policy – TreatAsLocal

Subscriber’s Home Inter-UserPriority

Inter-User Priority given by ServingJurisdiction

0 0

1 1

2 2

3 3

4 4

5 5

6 6

7 7

unknown 1



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

The adjustments of the IUP values for the sampleAdjustedService policy are shownin Table 15-12, “Sample Jurisdictional Policy – AdjustedService” (p. 15-31).

Note: This policy gives visiting users lower Inter-User Priority values than local users.

Table 15-12 Sample Jurisdictional Policy – AdjustedService



0 0

1 0

2 1

3 1

4 2

5 2

6 3

7 3

unknown 0

The adjustments of the IUP values for the sampleStandardService policy are shownin Table 15-13, “Sample Jurisdictional Policy – StandardService” (p. 15-31).

Note: This policy gives visiting users an Inter-User Priority value of 1 (standardpriority service).

Table 15-13 Sample Jurisdictional Policy – StandardService



0 1

1 1

2 1

3 1

4 1

5 1

6 1

7 1

unknown 1



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


15-31

The adjustments of the IUP values for the sampleBasicService policy are shown inTable 15-14, “Sample Jurisdictional Policy – BasicService” (p. 15-32).

Note: This policy gives visiting users an Inter-User Priority value of 0 (lowest priorityservice).

Table 15-14 Sample Jurisdictional Policy – BasicService



0 0

1 0

2 0

3 0

4 0

5 0

6 0

7 0

unknown 0

In some cases, service providers may wish to configure the Default policy like theBasicService policy shown above. The Default policy will cover all visiting usersthat don’t have a defined Home Area and visiting users with a Home Area that is notlisted in the Policy Assignment table. However, it is strongly recommended that serviceproviders verify that the Home Area attribute has been included in the subscriberprofiles for all expected users before such changes are made to the Default policy.

Creating OMC-RAN user accounts restricted to specific jurisdictions

The JPPSUBEDA feature allows the System Administrator to create additionalOMC-RAN user accounts that are restricted to operate within a specific jurisdiction.Administrators using these restricted accounts will be able to manage the jurisdictionalpolicies for their own jurisdiction, but they will not be able to change or view thejurisdictional policy information for any other jurisdiction.

Important! The creation of these restricted OMC-RAN user accounts is optional.Any user account withSystem Administrator permissions is able to manage datafor all jurisdictions.



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

The tasks allowed for these two types of OMC-RAN user accounts is presented inTable 15-15, “Tasks permitted for OMC-RAN user account types” (p. 15-33).

Table 15-15 Tasks permitted for OMC-RAN user account types

Procedure Allowed forSystemAdministratoraccounts?

Allowed forJurisdictionUser Groupaccounts?

Activating the feature +

Confirming feature activation X

Creating jurisdictions X

Creating OMC-RAN user account restricted tojurisdiction

X

Creating jurisdictional policies X X

Updating jurisdictional policies (if necessary) X X

Making jurisdictional policy assignments X X

Making BTS assignments for a jurisdiction X

Viewing BTS assignments for a jurisdiction X X

Setting Subscriber Home Area attribute in AAAsubscriber profiles

N/A N/A

Enabling the feature X

Deactivating the feature X

Perform maintenance operations on BTSs(″pokes″)

X *

+ = Service provider must contact their Alcatel-Lucent account representative toactivate the feature.

*= User account can only perform maintenace operations for BTSs assigned tojurisdiction.

N/A = Not applicable to OMC-RAN. Task is performed on AAA system.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


15-33


Introduction

The following information describes the procedures for implementing the JPPSUBEDA(FID 12171.5) on an existing Rev. A network with the Per Application QoS feature(FID 12078.9) and the IUPBEDA (FID 12171.4) enabled.

Complete configuration and implementation requirements

Ensure that all configuration and implementation considerations have been reviewedbefore implementing the JPPSUBEDA feature. For more information, see“Configuration and implementation considerations” (p. 15-27).

Procedures

To implement the JPPSUBEDA feature, perform the following procedures in sequence:



“Creating jurisdictions” (p. 15-37)

“Creating OMC-RAN user account restricted to jurisdiction” (p. 15-39)

“Creating jurisdictional policies” (p. 15-45)

“Updating jurisdictional policies” (p. 15-47)

“Making jurisdictional policy assignments” (p. 15-49)

“Making BTS assignments for a jurisdiction” (p. 15-56)

“Viewing BTS assignments for a jurisdiction” (p. 15-59)

“Setting Subscriber Home Area attribute in AAA” (p. 15-62)

“Enabling the feature” (p. 15-64)

“Deactivating the feature” (p. 15-66)

Important! When implementing the JPPSUBEDA feature it is recommended thatjurisdictions, jurisdictional policies, policy assignments and BTS assignments arecreated before the JPPSUBEDA feature is enabled. These provisioning steps can beperformed if the JPPSUBEDA FAF entry is active. This approach allowsprovisioning to be completed and verified before the feature is enabled.

Jurisdictions (and related data) can be added to the system after the JPPSUBEDAfeature is enabled.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Purpose

This procedure activates the JPPSUBEDA feature in aCDMA2000® 1xEV-DOnetwork.

Execution of this procedure will activate the JPPSUBEDA feature so the otherprocedures for implementing this feature can be executed.

Important! The feature will not be enabled (call processing will not be affected)until the “Enabling the feature” (p. 15-64)is executed.

Procedure


...................................................................................................................................................................................................


JPPSUPBEDA

...................................................................................................................................................................................................

2 Proceed to“Confirming feature activation” (p. 15-36)

E N D O F S T E P S...................................................................................................................................................................................................


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


15-35


Purpose

This procedure activates the JPPSUBEDA feature in aCDMA2000® 1xEV-DOnetwork.

Procedure


...................................................................................................................................................................................................




...................................................................................................................................................................................................

2 Left click on theEvDO RNC FAF tab of theFxApx Details view and verify the FAFentry has been activated. The feature’s FAF status is displayed at the bottom of thepage as shown below

E N D O F S T E P S...................................................................................................................................................................................................


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Creating jurisdictions...................................................................................................................................................................................................................................

Purpose

This procedure creates jurisdictions that are related to the JPPSUBEDA feature. Ajurisdiction must be created before any jurisdictional policies and policy assignmentscan be added.

Procedure


...................................................................................................................................................................................................

1 If the Jurisdiction Group does not exist for the current network, create it by performinga right click on thenetwork object and select theCreate then select theJurisdiction Group item from the pop-up menu.

...................................................................................................................................................................................................

2 Right click theJurisdiction Group object and select theCreate then select theServing Jurisdictionitem from the pop-up menu.

...................................................................................................................................................................................................

3 Enter the desiredJurisdiction ID andJurisdiction Name in the pop-up form.Then left click theOK button as shown below:


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


15-37

...................................................................................................................................................................................................

4 Left click on the+ next to theJurisdiction Group object. This will expand the listof Serving Jurisdictions under theJurisdiction Group.

...................................................................................................................................................................................................

5 Repeat stepsStep 2throughStep 3to create the otherServing Jurisdictions foryour network.

Important! Up to 18 Serving Jurisdictions can be created.

E N D O F S T E P S...................................................................................................................................................................................................


Creating jurisdictions

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Creating OMC-RAN user account restricted to jurisdiction...................................................................................................................................................................................................................................

Purpose

This procedure creates an OMC-RAN user account with access restricted to a specificjurisdiction. Administrators using this type of user account will be able to performtasks such as creating jurisdictional policies and perform policy assignments, but theywill not be able to perform tasks that affect data beyond the scope of the jurisdiction.

Important! These steps are performed using the OMC-RAN User & SessionManager.

Important! This is an optional step. Any task can be performed with the existing″System Administration″ user accounts.

Procedure


...................................................................................................................................................................................................

1 Open theUser & Session Manager by performing a left click on theSystem item ofthe menu bar of the OMC-RAN Desktop and selecting theUser & Session Manageritem from the pop-up menu as shown below:

...................................................................................................................................................................................................

2 Left click on theActions item on the menu bar of theUser & Session Manager andselect theCreate then select theUser item from the pop-up menu as shown below:


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


15-39

...................................................................................................................................................................................................

3 Populate fields of the user profile on theCreate User form. Then left click theNextbutton as shown below:


Creating OMC-RAN user account restricted to jurisdiction

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

...................................................................................................................................................................................................

4 Left click on aJurisdictionUserGroup in the Not Assigned column as shownbelow.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


15-41

Important! The first number afterJurisdictionUserGroup_ is the SN Id and thesecond number is the jurisdiction Id. TheJurisdictionUserGroup is created when thejurisdiction is created.

...................................................................................................................................................................................................

5 Left click on right arrow button as shown below:



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Result: The selectedJurisdictionUserGroup is moved from theNot Assignedcolumn to theAssigned column as shown in the example below:



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


15-43

...................................................................................................................................................................................................

6 Left click on theFinish button of theCreate user form

E N D O F S T E P S...................................................................................................................................................................................................



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Creating jurisdictional policies...................................................................................................................................................................................................................................

Purpose

This procedure creates jurisdictional policies that are used by the JPPSUBEDA feature.

Important! These steps are performed using the OMC-RAN Network Manager.

Procedure


...................................................................................................................................................................................................

1 Select the jurisdiction for which the policy will be created by performing a right clickon theServing Jurisdiction object and select theShowOnTree item from the pop-upmenu.

Result: The jurisdiction subtree is displayed as shown in the following example.

...................................................................................................................................................................................................

2 Right click on the jurisdiction name at top of the subtree (shown highlighted above)and select theCreate then select theBE Roaming Policy item from the pop-up menu.

...................................................................................................................................................................................................

3 Enter the Policy Name and the adjusted Inter-User Priority values on the pop-up form.Then left click theOK button as shown below:


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


15-45

...................................................................................................................................................................................................

4 Repeat stepsStep 1throughStep 3to create the other jurisdictional policies for yournetwork.

Important! Up to 4 policies can be created per Serving Jurisdiction (in addition to″Default″).

E N D O F S T E P S...................................................................................................................................................................................................


Creating jurisdictional policies

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Updating jurisdictional policies...................................................................................................................................................................................................................................

Purpose

This procedure updates jurisdictional policies that are used by the JPPSUBEDAfeature.


Procedure


...................................................................................................................................................................................................

1 Select the jurisdiction for which the policy will be created by performing a right clickon theServing Jurisdiction object and select theShowOnTree item from the pop-upmenu.


...................................................................................................................................................................................................

2 Right click on the policy to be updated and select theDetails item from the pop-upmenu

...................................................................................................................................................................................................

3 Left click the Modify button of theDetails form. In this example shown below, we areupdating theDefault policy.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


15-47

...................................................................................................................................................................................................

4 Update the Inter-User Priority values on the form. Then left click theOK button.

E N D O F S T E P S...................................................................................................................................................................................................


Updating jurisdictional policies

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Making jurisdictional policy assignments...................................................................................................................................................................................................................................

Purpose

This procedure makes jurisdictional policy assignments that control the behavior of theJPPSUBEDA feature.


Procedure


...................................................................................................................................................................................................

1 Select the jurisdiction for which the policy will be updated by performing a right clickon theServing Jurisdiction object and select theShowOnTree item from the pop-upmenu.


...................................................................................................................................................................................................

2 Right click onRoamPolAssgn and select theDetails item from the pop-up menu.

...................................................................................................................................................................................................

3 Left click the Modify button of theRoaming Policy Assignment form.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


15-49

...................................................................................................................................................................................................

4 Left click the Add button of theRoaming Policy Assignment form.


Making jurisdictional policy assignments

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

...................................................................................................................................................................................................

5 Left click on the fields of theRoaming Policy Assignments pop-up form and selectthe desired values. Then left click theAdd button to add this entry to theRoamingPolicy Assignment table as shown below:



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


15-51

Result: The entry is added to theRoaming Policy Assignment table as shown below:



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

...................................................................................................................................................................................................

6 Repeat stepStep 5until all required policy assignment entries have been added.

...................................................................................................................................................................................................

7 Left click the Cancel button to close theRoaming Policy Assignments pop-up form.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


15-53

...................................................................................................................................................................................................

8 Left click the OK button on the mainRoaming Policy Assignment form to close theform.



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

E N D O F S T E P S...................................................................................................................................................................................................



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


15-55

Making BTS assignments for a jurisdiction...................................................................................................................................................................................................................................

Purpose

This procedure assigns BTSs to a jurisdiction.


Important! The policies associated with a jurisdiction will be enabled to affectcalls as soon as a BTS has been assigned (assuming the JPPSUBEDA feature isalso enabled). It is recommended that policies and policy assignments be reviewedbefore any BTSs are assigned.

Procedure


...................................................................................................................................................................................................

1 Right click on theServing Jurisdiction object to which BTSs are to be assigned andselect theBTS Allocation item from the pop-up menu as shown below:

Result: The BTS Manager is displayed as shown in the following example.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

...................................................................................................................................................................................................

2 Select the BTS to be assigned and left click theAdd button as shown below.

...................................................................................................................................................................................................

3 Result: The selected BTS is moved from theAvailable BTSs column to the AssignedBTSs column as shown in the example below: button as shown below.


Making BTS assignments for a jurisdiction

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


15-57

...................................................................................................................................................................................................

4 Repeat stepStep 2as needed to assign all required BTSs to the currently selectedjurisdiction.

...................................................................................................................................................................................................

5 Left click the OK button on theBTS Allocation Manager .

E N D O F S T E P S...................................................................................................................................................................................................


Making BTS assignments for a jurisdiction

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Viewing BTS assignments for a jurisdiction...................................................................................................................................................................................................................................

Purpose

This procedure allows the user to view the set of BTSs that are currently assigned to ajurisdiction.


Note: This is an optional step. This procedure is provided in case there is a need toview the list of BTSs that are assigned to a jurisdiction.

Procedure


...................................................................................................................................................................................................

1 Go to theJurisdiction Details view from theOMC-RAN Network Manager . TheDetails view for a specific jurisdiction can be accessed using either of the followingtechniques:

• Right click on theJurisdiction object and select theDetails item from the pop-upmenu.

• Double click on the Jurisdiction object.

Result: The Jurisdiction Details view is displayed as shown in the following example.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


15-59

...................................................................................................................................................................................................

2 Left click on theBTS Allocation tab of theJurisdiction Details view.

Result: The BTS Allocation information is displayed as shown in the followingexample.


Viewing BTS assignments for a jurisdiction

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

...................................................................................................................................................................................................

3 Left click on theOK button of theJurisdiction Details page.

E N D O F S T E P S...................................................................................................................................................................................................


Viewing BTS assignments for a jurisdiction

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


15-61

Setting Subscriber Home Area attribute in AAA...................................................................................................................................................................................................................................

Purpose

This procedure is used to include the Subscriber Home Area attribute in AAAsubscriber profiles. This attribute is used by the JPPSUBEDA feature.

Important! The exact procedures will vary depending on the specific AAA systembeing used. Please refer to the documentation for your AAA system for moreinformation.

Important! This a vendor-specific attribute. Please contact your PDSN vendor toverify that your PDSN supports this attribute.

Procedure


...................................................................................................................................................................................................

1 Verify that the AAA dictionary includes the definition for the Lucent-VID. Thedefinition for the Lucent-VID will appear as follows on theVitalAAA® system:

<vendor name=”Lucent-VID” number=”3729” format=”rfc”/>

...................................................................................................................................................................................................

2 Verify that the AAA dictionary includes the Lucent-VID-Home-Area definition as aVendor Specific Attribute (VSA) with the Lucent-VID. This attribute definition willappear as follows on theVitalAAA® system:.

<avp name=”Lucent-VID-Home-Area” vendor=”Lucent-VID” code=″11″ type=″short″/>

</avp>

...................................................................................................................................................................................................

3 Update subscriber profiles as needed to include the Lucent-VID-Home-Area attribute.The following example shows a sample subscriber profile forVitalAAA® system:


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789123456789012345678901234567890121234567890123456789012345678912345678901234567890123456789012123456789012345678901234567891234567890123456789012345678901212345678901234567890123456789

CLIENT_IUP1_J3 User-Password=PASSWORD1 Auth-Type=LocalLucent-VID-Home-Area=3

3GPP2-Inter-User-Priority=1Cisco-AVPair=″lcp:cdma-user-class=1″Cisco-AVPair=″ip:addr-pool=pdsn-pool″Callback-Id=0111113137147635

E N D O F S T E P S...................................................................................................................................................................................................


Setting Subscriber Home Area attribute in AAA

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


15-63

Enabling the feature...................................................................................................................................................................................................................................

Purpose

This procedure enables the Jurisdictional Priority for Public Safety Users of Best EffortData Applications (JPPSUBEDA) (FID 12171.5) feature in aCDMA2000® 1xEvDOnetwork.

Execution of this procedure will cause the network to adjust the Inter-User Priority ofusers visting from other jurisdictions based upon the defined jurisdictional policies.This adjustment of Inter-User Priority values for visiting users will affect their priorityof data transmission on the Forward Link for Best Effort service category dataconnections.

Important! The “Activating the feature” (p. 15-35)procedure must be completedbefore this procedure can be executed.

Important! Jurisdictional Priority and Inter-User Priority must be turned on onlyfrom the OMC-RAN.

Procedure


...................................................................................................................................................................................................

1 Go to theFxApx Details view from theOMC-RAN Network Manager . TheDetailsview can be accessed using either of the following techniques:



...................................................................................................................................................................................................


...................................................................................................................................................................................................



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

...................................................................................................................................................................................................

4 Left click on theEnable Jurisdictional Priority for Public Safety Usersfield and selectYes the menu.

...................................................................................................................................................................................................

5 Left click on theOK button at the bottom of theSN General page.

E N D O F S T E P S...................................................................................................................................................................................................


Enabling the feature

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


15-65

Deactivating the feature...................................................................................................................................................................................................................................

Purpose

This procedure deactivates the JPPSUBEDA feature in aCDMA2000® 1xEV-DOnetwork.

Important! The order of these steps is important. The provisioned jurisdictionaldata must be removed before the FAF is deactivated.

Procedure


...................................................................................................................................................................................................

1 Change theEnable Jurisdictional Priority for Public Safety Users field to no.

...................................................................................................................................................................................................

2 Delete theJurisdiction Group object and all jurisdiction data under it.

...................................................................................................................................................................................................

3 Ask your Alcatel-Lucent account executive to deactivate the following entry in yourFeature Activation File (FAF):

JPPSUPBEDA

E N D O F S T E P S...................................................................................................................................................................................................


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

16 16Universal Traffic Processor(UTP) Protocol Acceleration inHardware

Overview...................................................................................................................................................................................................................................

Purpose

This chapter describes the Universal Traffic Processor (UTP) Protocol Acceleration inHardware feature inCDMA2000® 1xEV-DO networks.

Feature summary

The UTP Protocol Acceleration in Hardware feature supports hardware acceleration forRevision A (Rev. A) Forward Link bearer processing to Signaling Bus-1xEV-DOModem (SB-EVM).


A unique Feature Identifier (FID) is assigned to each feature. The FID of the UTPProtocol Acceleration in Hardware feature is FID 12780.3.


The UTP Protocol Acceleration in Hardware affects the user interfaces that are listed inthe following table.


Configuration management: ElementManagement System (EMS) andOperations and Maintenance Center -Radio Access Network (OMC-RAN)

See“Configuration management” (p. 16-7)

Service measurements See“Impacts on service measurements”(p. 16-8)


None

....................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


16-1



None

Intended audience

This document is intended for technicians, engineers, and system administrators whoimplement or maintain the UTP Protocol Acceleration in Hardware feature in aCDMA2000® 1xEV-DO network.



Contents

Availability 16-3

Prerequisites 16-4



Configuration management 16-7



Universal Traffic Processor (UTP) Protocol Acceleration inHardware

Overview

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Availability...................................................................................................................................................................................................................................


The UTP Protocol Acceleration in Hardware feature is available in Releases 30.0 andlater.

Market availability

The UTP Protocol Acceleration in Hardware feature is available in the North AmericanRegion (NAR) market only.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


16-3

Prerequisites...................................................................................................................................................................................................................................

Introduction

The UTP Protocol Acceleration in Hardware feature has the following prerequisites.


The UTP Protocol Acceleration in Hardware feature is supported in the followingair-interface technologies:

• CDMA cellular

• CDMA PCS


The UTP Protocol Acceleration in Hardware feature requires Release 30.0 or later.


The UTP Protocol Acceleration in Hardware feature requires that the Node CardResource Monitor (NCRM) must be enabled before any UTPs are installed in theframe. There are no new hardware upgrades needed for currently installed UTPs fromRelease 29.0 to Release 30.0.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Introduction

The following information describes the functionality, benefits, and operation of theUTP Protocol Acceleration in Hardware feature.

Functionality

The Universal Traffic Processor (UTP) is a next generation traffic processor. Theprimary difference in capability is the addition of a new Fast Protocol Processor (FPP)that performs much of the protocol processing in hardware rather than in software.


The UTP Protocol Acceleration in Hardware feature capability is defined as deliveringadditional hardware acceleration by extending the Release 29.0 Forward Link Rev. 0bearer processing to all types of Rev. A Forward Link bearer processing includingMultiflow Packet Application (MFPA) and Default Packet Application (DPA)capabilities. The Rev. A processing supports some additional capabilities that are notpresent in Rev. 0 such as optional per flow RMI header compression, Quality ofService (QoS), and multiple flows per connection. The UTP hardware accelerationcapabilities are identical whether the UTP is deployed in a R1SR frame or UniversalNetwork Cabinet (UNC) frame. The inter-connectivity advantages of the UNC allowsthe UTP to operate at a much higher performance level but no additional″acceleration″is performed in the UNC.


The UTP hardware accelerated traffic processing is being delivered in phases. The firstset of functionality was defined in feature, UTP Protocol Acceleration in HardwareRequirements- Phase 1 (12780.0) and was completed in feature, UTP ProtocolAcceleration in Hardware Delivery- Phase 1 (12780.1). The second set of functionalityis defined in feature, UTP Protocol Acceleration in Hardware Requirements - Phase 2(12780.2) and delivered in this feature, UTP Protocol Acceleration in Hardware(12780.3).


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


16-5


Introduction

The UTP Protocol Acceleration in Hardware feature is dependent on the followingphase features:

• UTP Protocol Acceleration in Hardware Requirements - Phase 1 (12780.0)

• UTP Protocol Acceleration in Hardware - Phase 1 (12780.1)

• UTP Protocol Acceleration in Hardware - Phase 2 (12780.2)

UTP Protocol Acceleration in Hardware Requirements- Phase 1 (12780.0)

The UTP Protocol Acceleration in Hardware Requirements - Phase 1 feature integratesthe new UTP board into the R1SR frame of the 1xEV-DO RNC. This includesOperations, Administration and Maintenance (OA&M) support for the UTP, as well asmoving the Revision 0 (Rev. 0) forward bearer call processing from the host processorto the Functional Programmable Gate Array (FPGA) to be″hardware accelerated″.

UTP Protocol Acceleration in Hardware Delivery- Phase 1 (12780.1)

The UTP Protocol Acceleration in Hardware Delivery - Phase 1 feature delivers Phase1 of the 1xEV-DO UTP in the R1SR frame. The protocol stack processing in and outis performed by the hardware as well as the application forward link processing forRev. 0 calls.

UTP Protocol Acceleration in Hardware Requirements - Phase 2 (12780.2)

The UTP Protocol Acceleration in Hardware Requirements - Phase 2 feature continuesthe second set of requirements for hardware acceleration capabilities of Phase 1 whichincludes:

• Forward Link Rev A Processing with Default Packet Application (DPA)

• Forward Link Rev A Processing with Multiflow Packet Application (MFPA) andQuality of Service (QoS) applications

• Forward Link RMI compression for Rev. A only capabilities on-demand (optionalper flow)


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Configuration management...................................................................................................................................................................................................................................

Element Management System (EMS) configuration management

Important! Element Management System (EMS) does not support UTP. Thecustomer must have an OMC-RAN if they want a UTP.









...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


16-7


Introduction

The Release 30.0 UTP Protocol Acceleration in Hardware is backwards compatiblewith the Release 29.0 capable UTPs for existing service measurements.

References

For detailed information about 1xEV-DO service measurements, see CDMA2000®

1xEV-DO Service Measurements,, 401-614-326.


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Purpose

This UTP Protocol Acceleration in Hardware feature uses no licensing and no FAF. Ifthe Release 30 software is purchased and UTPs are already on the system, then theUTP Protocol Acceleration in Hardware feature is included. The UTP provisioningprocedure is similar to the TP-752i hardware provisioning procedure and is found inCDMA2000® 1xEV-DO Radio Network Controller,401-614-102.

The Release 30.0 UTP Protocol Acceleration in Hardware feature is backwardscompatible with the Release 29.0 capable UTPs for existing operations, administration,maintenance and provisioning functions.

For details on the Application Licensing Process procedures, see CDMA2000®

1xEV-DO Radio Access System Planning and Implementation Guide,401-614-101.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


16-9

17 17Backhaul Enhancement inSupport of Small Packets on theReverse and Forward Links in1xEV-DO

Overview...................................................................................................................................................................................................................................

Purpose

This document describes the following optional features inCDMA2000® 1xEV-DOnetworks.

• Backhaul Enhancement in Support of Small Packets on the Reverse Link in1xEV-DO (Phase 1a) (FID 12102.5)

• Backhaul Enhancement in Support of Small Packets on the Forward Link in1xEV-DO (Phase 1b) (FID 12102.14)

Feature summary


Backhaul Enhancement in Support of Small Packets on the Reverse Link in1xEV-DO (Phase 1a) (FID 12102.5)

The Backhaul Enhancement in Support of Small Packets on the Reverse Link in1xEV-DO (Phase 1a) (FID 12102.5) feature improves the backhaul utilization on thereverse link of a CDMA 3G-1x Evolution Data Optimized (1x EVDO) Revision A(Rev. A) network for applications that are characterized by small packets sizes such asVoice Over IP (VOIP), and Push To Talk (PTT).

The current EV DO Backhaul design is not appropriate for carrying small packets suchas VOIP, and PTT applications where the voice frames are much smaller than the IPpackets of a data application. Moreover, the majority of the current Rev. A, andRevision 0 (Rev. 0) BE traffic on the reverse link contains Positive Acknowledge/NotAcknowledged (ACK/NAK) frames that are even smaller in size than a voice frame.

Therefore, for the EV DO Rev. A network to carry the small bearer traffic efficientlythe backhaul overhead must be reduced. As Phase 1a, this feature provides headercompression of the reverse link backhaul bearer traffic processing messages betweenthe Base Transceiver Station (BTS), and the Radio Network Controller (RNC).

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


17-1

This header compression is transparent to the edge router, since it is application layerfunctionality.

Backhaul Enhancement in Support of Small Packets on the Forward Link in1xEV-DO (Phase 1b) (FID 12102.14)

The Backhaul Enhancement in Support of Small Packets on the Forward Link in1xEV-DO (Phase 1b) (FID 12102.14) feature improves the backhaul utilization on theforward link of a 1x EVDO Rev. A network for applications that are characterized bysmall packets sizes such as VOIP, and PTT.

The current EV DO Backhaul design is not appropriate for carrying small packets suchas VOIP, and PTT applications where the voice frames are much smaller than the IPpackets of a data application.

Therefore, for the EV DO Rev. A network to carry the small bearer traffic efficientlythe backhaul overhead must be reduced.

As Phase 1b, this feature provides selective header compression of the PTT forwardlink backhaul bearer traffic processing messages between the RNC, and the BTS. Thisfunctionality is extendable to include the VOIP application when it becomes availablein later releases. This header compression is transparent to the edge router, since it isapplication layer functionality.


The features that are described in this document impact the following user interfaces:


Backhaul Enhancement inSupport of Small Packetson the Reverse Link in1xEV-DO (Phase 1a) (FID12102.5)

Element ManagementSystem (EMS)configuration managementand the Operations andMaintenance Center -Radio Access Network(OMC-RAN).

See“Implementing thefeatures” (p. 17-14).



None


None

Backhaul Enhancement in Support of Small Packets onthe Reverse and Forward Links in 1xEV-DO

Overview

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008


Backhaul Enhancement inSupport of Small Packetson the Forward Link in1xEV-DO (Phase 1b) (FID12102.14)

Element ManagementSystem (EMS)configuration managementand the OMC-RAN.

See“Implementing thefeatures” (p. 17-14).



None


None

Intended audience

This document is intended for technicians, engineers, and system administrators whoimplement or maintain the Backhaul Enhancement in Support of Small Packets on theReverse and Forward Links in 1xEV-DO feature and/or related features in aCDMA2000® 1xEV-DO network.



Contents

Availability 17-5

Prerequisites 17-7

Feature description: Backhaul Enhancement in Support of Small Packetson the Reverse Link in 1xEV-DO (Phase 1a) (FID 12102.5)

17-9

Feature description: Backhaul Enhancement in Support of Small Packetson the Forward Link in 1xEV-DO (Phase 1b) (FID 12102.14)

17-10

Feature interactions: Backhaul Enhancement in Support of Small Packetson the Reverse and Forward Links in 1xEV-DO features

17-11


Activating the Backhaul Enhancement in Support of Small Packets onthe Reverse and Forward Links in 1xEV-DO features via EMS

17-15


Overview

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


17-3


Deactivating the Backhaul Enhancement in Support of Small Packets onthe Reverse and Forward Links in 1xEV-DO feature via EMS

17-17

Activating the Backhaul Enhancement in Support of Small Packets onthe Reverse and Forward Links in 1xEV-DO features via OMC-RAN

17-18

Deactivating the Backhaul Enhancement in Support of Small Packets onthe Reverse and Forward Links in 1xEV-DO features via OMC-RAN

17-20


Overview

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Availability...................................................................................................................................................................................................................................


The following table identifies the Advanced Mobile Phone Service/PersonalCommunications Services (AMPS/PCS) software releases in which the BackhaulEnhancement in Support of Small Packets on the Reverse and Forward Links in1xEV-DO and related features are available.


Backhaul Enhancement in Support of SmallPackets on the Reverse Link in 1xEV-DO(Phase 1a)


Backhaul Enhancement in Support of SmallPackets on the Forward Link in 1xEV-DO(Phase 1b) (FID 12102.14)


Market availability

The Backhaul Enhancement in Support of Small Packets on the Reverse and ForwardLinks in 1xEV-DO and related features are available in the following markets:


Backhaul Enhancement inSupport of Small Packets on theReverse Link in 1xEV-DO (Phase1a)

North American Region (NAR) markets

Backhaul Enhancement inSupport of Small Packets on theForward Link in 1xEV-DO(Phase 1b)

North American Region (NAR) markets

Restricted Availability

The features that this document describes have Restricted Availability (RA).RestrictedAvailability means that a feature has been developed for specific customers only.Restricted Availability features have been tested in specific environments for thoseselect customers and have not been designated as Generally Available (GA). Thesefeatures may be made available to other customers, but additional development may be


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


17-5

needed. Please contact your customer team to determine whether additionaldevelopment is necessary to activate these features and arrange for testing of thesefeatures in your network.


Availability

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Prerequisites...................................................................................................................................................................................................................................

Introduction

The Backhaul Enhancement in Support of Small Packets on the Reverse and ForwardLinks in 1xEV-DO and related features have the following prerequisites.


The Backhaul Enhancement in Support of Small Packets on the Reverse and ForwardLinks in 1xEV-DO and related features are supported in the following air-interfacetechnology:

• 1xEV-DO




The Backhaul Enhancement in Support of Small Packets on the Reverse Link in1xEV-DO (Phase 1a) feature requires Release 29.0 or later. The activation of theBackhaul Enhancement in Support of Small Packets on the Reverse Link in 1xEV-DO(Phase 1a) feature is dependent on the 1xEV-DO Basic Rev. A Feature Bundle, thismeans the 1xEV-DO Basic Rev. A Feature Bundle needs to be activated before theactivation of any of these features.


The Backhaul Enhancement in Support of Small Packets on the Forward Link in1xEV-DO (Phase 1b) feature requires Release 29.0 or late. The activation of theBackhaul Enhancement in Support of Small Packets on the Forward Link in 1xEV-DO(Phase 1b) feature is dependent on the 1xEV-DO Basic Rev. A Feature Bundle, thismeans the 1xEV-DO Basic Rev. A Feature Bundle needs to be activated before theactivation of any of these features.




The Backhaul Enhancement in Support of Small Packets on the Reverse Link in1xEV-DO (Phase 1a) feature is restricted to SBEVM boards.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


17-7


The Backhaul Enhancement in Support of Small Packets on the Forward Link in1xEV-DO (Phase 1b) feature is restricted to SBEVM boards.


Prerequisites

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Feature description: Backhaul Enhancement in Support ofSmall Packets on the Reverse Link in 1xEV-DO (Phase 1a)(FID 12102.5)...................................................................................................................................................................................................................................

Introduction

The following information describes the functionality, benefits, and operation of theBackhaul Enhancement in Support of Small Packets on the Reverse Link in 1xEV-DO(Phase 1a) feature.

Functionality

The Backhaul Enhancement in Support of Small Packets on the Reverse Link in1xEV-DO (Phase 1a) feature provides header compression of the reverse link backhaulbearer traffic processing messages between the BTS, and the RNC. This headercompression is transparent to the edge router, since it is application layer functionality.

Benefits

Although the initial intent of Backhaul Enhancement in Support of Small Packets onthe Reverse Link in 1xEV-DO (Phase 1a) feature was to improve the backhaulutilization in the reverse direction for the applications that are characterized by smallpacket sizes, for example, VOIP and PTT, it applies to all reverse link flows, includingRev. A BE and Rev. 0 flows in an 1xEV-DO Rev. A network.

Important! This feature is restricted to SBEVM boards.


Once the FAF is activated, the Backhaul Enhancement in Support of Small Packets onthe Forward Link in 1xEV-DO (Phase 1b) feature is enabled or disabled via either theEMS or the OMC-RAN. Please refer to“Implementing the features” (p. 17-14)formore details.



...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


17-9

Feature description: Backhaul Enhancement in Support ofSmall Packets on the Forward Link in 1xEV-DO (Phase 1b)(FID 12102.14)...................................................................................................................................................................................................................................

Introduction

The following information describes the functionality, benefits, and operation of theBackhaul Enhancement in Support of Small Packets on the Forward Link in 1xEV-DO(Phase 1b) feature.

Functionality

The Backhaul Enhancement in Support of Small Packets on the Forward Link in1xEV-DO (Phase 1b) feature provides selective header compression of the PTTforward link backhaul bearer traffic processing messages between the RNC, and theBTS. This functionality is extendable to include the VOIP application when it becomesavailable in later releases. This header compression is transparent to the edge router,since it is application layer functionality.

Benefits

This feature improves the backhaul utilization in the forward direction for two specificapplications that are characterized by small packet sizes, namely VOIP, and PTT.



Once the FAF is activated, the Backhaul Enhancement in Support of Small Packets onthe Forward Link in 1xEV-DO (Phase 1b) feature is enabled or disabled via either theEMS or the OMC-RAN. Please refer to“Implementing the features” (p. 17-14)formore details.



...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Feature interactions: Backhaul Enhancement in Support ofSmall Packets on the Reverse and Forward Links in 1xEV-DOfeatures...................................................................................................................................................................................................................................

Introduction

Backhaul Enhancement in Support of Small Packets on the Reverse and Forward Linksin 1xEV-DO features are dependent on the 1xEV-DO Basic Rev. A Feature Bundle andthe 1xEV-DO Enhanced DOrA Feature Bundle. This means that the 1xEV-DO BasicRev. A Feature Bundle and the 1xEV-DO Enhanced DOrA Feature Bundle need to beactivated before the activation of any of these features:

• 1xEV-DO Basic Rev. A Feature Bundle consists of FIDs 12078.2, 12078.3,12078.4, 12078.5 and 12078.7

1xEV-DO Basic Rev. A Feature Bundle

The 1xEV-DO Basic Rev. A Feature Bundle consists of FIDs 12078.2, 12078.3,12078.4, 12078.5 and 12078.7.


This feature is part of the Rev. A Basic package of features, also referred to as BasicRev. A Feature Bundle. This feature introduces the support of the full Rev. A PhysicalLayer with the complete set of Rev. A enhanced Medium Access Control (MAC)protocols that is the following MAC protocols are supported:





This feature is supported on all ModCell BTS types using the new HRPD Rev. Amodem board, the SB-EVM for ModCell 4.0 and variants or the SB-EVMm forModCell 1-3. This feature is supported only by the Rev. A capable RNC.


This feature is part of the Rev. A Basic package of features. This feature allowsconfiguration attribute changes without costly session configuration protocol exchangeand without releasing the connection. It allows the AT and the AN to use the GAUP toupdate values of the session parameter attributes belonging to different lower andhigher layer protocols and applications.


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


17-11

HRPD Rev. A Support on ModCell 1-3 BTS Platforms using SB-EVMm (FID12078.4)

This feature is part of the Rev. A Basic package of features and provides the necessaryhardware and software for the ModCell 1-3 products to make use of any other Rev. Afeature. This feature supports HRPD Rev. A technology on all ModCell 1-3. Thisfeature includes Software, OA&M and Service Measurements support related to HRPDRev. A for the ModCell 1-3 BTS platforms.

The following ModCell 1.0/2.0/3.0 BTS products will be supported:

• ModCell 3.0

• ModCell 2.0

• ModCell 1.0

The term ModCell 1-3 is used in this chapter to include the variants listed above.

HRPD Rev. A Support on ModCell 4.0 BTS Platforms using SB-EVM (FID 12078.5)

This feature is part of the Rev. A Basic package of features and provides the necessaryhardware and software for the ModCell 4.0 products to make use of any other Rev. Afeature. This feature supports HRPD Rev. A technology on all ModCell 4.0 Platforms.This feature includes Software, OA&M and Service Measurements support related toHRPD Rev. A for the ModCell 4.0 platforms.

The following ModCell 4.0 products will be supported:

• ModCell 4.0

• ModCell 4.0 B

• Compact 4.0

• Compact 4.0 B

• HD 4.0

• HD 4.0 B

• Digital Host 4.0

• Digital Host 4.0 B

The term ModCell 4.0 is used in this chapter to include the variants listed above.


This feature is part of the Rev. A Basic package of features. The purpose of this featureis to support, in both Rel 0 systems and in mixed Rel 0/Rev. A systems:




Feature interactions: Backhaul Enhancement in Supportof Small Packets on the Reverse and Forward Links in

1xEV-DO features

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

This feature does not include active handoff from Rel 0 to Rev. A systems.


Feature interactions: Backhaul Enhancement in Supportof Small Packets on the Reverse and Forward Links in

1xEV-DO features

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


17-13


Process

To implement the Backhaul Enhancement in Support of Small Packets on the Reverseand Forward Links in 1xEV-DO features, go to the following section:

“Activating the Backhaul Enhancement in Support of Small Packets on the Reverse andForward Links in 1xEV-DO features via EMS” (p. 17-15)

“Deactivating the Backhaul Enhancement in Support of Small Packets on the Reverseand Forward Links in 1xEV-DO feature via EMS” (p. 17-17)

“Activating the Backhaul Enhancement in Support of Small Packets on the Reverse andForward Links in 1xEV-DO features via OMC-RAN” (p. 17-18)

“Deactivating the Backhaul Enhancement in Support of Small Packets on the Reverseand Forward Links in 1xEV-DO features via OMC-RAN” (p. 17-20)


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Activating the Backhaul Enhancement in Support of SmallPackets on the Reverse and Forward Links in 1xEV-DOfeatures via EMS...................................................................................................................................................................................................................................

Purpose

This section explains the activation of the Backhaul Enhancement in Support of SmallPackets on the Reverse and Forward Links in 1xEV-DO features in aCDMA2000®

1xEV-DO network.

Procedure

The FAF for the feature must be installed or activated on the OMP before the featurecould be enabled.

...................................................................................................................................................................................................

1 From theService Node screen go toGeneral Section 3 screen.

...................................................................................................................................................................................................

2 To enable the Backhaul Enhancement in Support of Small Packets on the Reverse Linkin 1xEV-DO (Phase 1a) feature, select theYes radio button forRMI HC Feature RLEnable field. Refer to Figure 17-1, “EMS SN General Screen” (p. 17-16).

To enable the Backhaul Enhancement in Support of Small Packets on the ForwardLink in 1xEV-DO (Phase 1b) feature, select theYes radio button forRMI HC FeatureFL Enable field. Refer to Figure 17-1, “EMS SN General Screen” (p. 17-16).


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


17-15

E N D O F S T E P S...................................................................................................................................................................................................

Figure 17-1 EMS SN General Screen


Activating the Backhaul Enhancement in Support of SmallPackets on the Reverse and Forward Links in 1xEV-DO

features via EMS

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Deactivating the Backhaul Enhancement in Support of SmallPackets on the Reverse and Forward Links in 1xEV-DO featurevia EMS...................................................................................................................................................................................................................................

Purpose

This section explains the deactivation of the Backhaul Enhancement in Support ofSmall Packets on the Reverse and Forward Links in 1xEV-DO features in aCDMA2000® 1xEV-DO network.

Procedure

If the FAF for the feature is not installed or activated on the OMP, the feature is bydefault deactivated or disabled. Otherwise:

...................................................................................................................................................................................................

1 The FAF for the feature must be installed or activated on the OMP before the featurecould be enabled.

...................................................................................................................................................................................................

2 From theService Node screen go toGeneral Section 3 screen.

...................................................................................................................................................................................................

3 To disable the Backhaul Enhancement in Support of Small Packets on the ReverseLink in 1xEV-DO (Phase 1a) feature, select theNo radio button forRMI HC FeatureRL Enable field. Refer to Figure 17-1, “EMS SN General Screen” (p. 17-16).

To disable the Backhaul Enhancement in Support of Small Packets on the ForwardLink in 1xEV-DO (Phase 1b) feature, select theNo radio button forRMI HC FeatureFL Enable field. Refer to Figure 17-1, “EMS SN General Screen” (p. 17-16).

E N D O F S T E P S...................................................................................................................................................................................................


...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


17-17

Activating the Backhaul Enhancement in Support of SmallPackets on the Reverse and Forward Links in 1xEV-DOfeatures via OMC-RAN...................................................................................................................................................................................................................................

Purpose


1xEV-DO network.

Procedure

The FAF for the feature must be installed or activated on the OMP before the featurecould be enabled.

...................................................................................................................................................................................................

1 Once the OMC-RAN is open, click onGlobal Config DO

...................................................................................................................................................................................................

2 Click on SN General , and scroll down toGeneral Section 4 section.

...................................................................................................................................................................................................

3 To enable the Backhaul Enhancement in Support of Small Packets on the Reverse Linkin 1xEV-DO (Phase 1a) feature, select theYes from the drop down option menuRMIHC Feature RL Enable field. Refer to Figure 17-2, “OMC General Screen” (p. 17-19).

To enable the Backhaul Enhancement in Support of Small Packets on the ForwardLink in 1xEV-DO (Phase 1b) feature, select theYes from the drop down option menuRMI HC Feature FL Enable field. Refer toFigure 17-2, “OMC General Screen”(p. 17-19).


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

E N D O F S T E P S...................................................................................................................................................................................................

Figure 17-2 OMC General Screen


Activating the Backhaul Enhancement in Support of SmallPackets on the Reverse and Forward Links in 1xEV-DO

features via OMC-RAN

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


17-19

Deactivating the Backhaul Enhancement in Support of SmallPackets on the Reverse and Forward Links in 1xEV-DOfeatures via OMC-RAN...................................................................................................................................................................................................................................

Purpose


1xEV-DO network.

Procedure

If the FAF for the feature is not installed or activated on the OMP, the feature is bydefault deactivated or disabled. Otherwise:

...................................................................................................................................................................................................

1 Once the OMC-RAN is open, click onGlobal Config DO

...................................................................................................................................................................................................

2 Click on SN General , and scroll down toGeneral Section 4 section.

...................................................................................................................................................................................................

3 To disable the Backhaul Enhancement in Support of Small Packets on the ReverseLink in 1xEV-DO (Phase 1a) feature, select theNo from the drop down option menuRMI HC Feature RL Enable field. Refer toFigure 17-2, “OMC General Screen”(p. 17-19).

To disable the Backhaul Enhancement in Support of Small Packets on the ForwardLink in 1xEV-DO (Phase 1b) feature, select theNo from the drop down option menuRMI HC Feature FL Enable field. Refer toFigure 17-2, “OMC General Screen”(p. 17-19).

E N D O F S T E P S...................................................................................................................................................................................................


...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

Glossary

....................................................................................................................................................................................................................................

Numerics

1xEV-DOCDMA 3G-1x EVolution Data Optimized1x evolution, data only (CDMA2000®) has been recognized as a 3G IMT-2000 standard.

3G1X3rd Generation CDMA

....................................................................................................................................................................................................................................

A AAAAccounting, Authentication and Authorization

ACKPositive Acknowledge

AMAAutomatic Message Accounting

AMPSAdvanced Mobilel Phone Service

AMPS/PCSAdvanced Mobile Phone Service/Personal Communication Services

ANAccess Network

APApplication Processor

ASCIIAccess and Cross Connect System II

....................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


GL-1

ATAccess Terminal

....................................................................................................................................................................................................................................

B BCMCSBroadcast/Multicast Service

BEBest Effort

BPBulk Provisioning

BSNBroadcast Serving Node

BTSBase Transceiver SystemBTS is the industry standard for base station. It is the physical equipment that providesthe air interface to subscriber access terminals. It is the box that contains the digital andRF equipment. It does not included the antennas or cabling to them. The EMS GUI usesBTS to mean Base Transceiver System.

....................................................................................................................................................................................................................................

C CARRCarrier

CCUChannel Control Unit

CDMCDMA Digital Module

CDMACode Division Multiple Access

CFCall Forwarding

CFCConnection Final Class

CFCQConnection Final Class Qualifier

cHDLCCisco HDLC

Glossary

...................................................................................................................................................................................................................................

GL-2 Alcatel-Lucent - ProprietarySee notice on first page

401-614-413Issue 5, May 2008

CLICommand Line Interface

CLIPCalling Line Identification Presentation

CLIRCalling Line Identification Restriction

CNCellular Networking

CPCall Processing

CSConversational Speech

CTACustomer Technical Advocate

CTSLucent Customer Technical Support

CVConversational Video

CWCall Waiting

....................................................................................................................................................................................................................................

D DHCP (Dynamic Host Configuration Protocol)An Internet protocol for automating the configuration of computers on a network thatuses TCP/IP.

DOData Only

DOrAData Only Revision A (Rev. A)

DoSData Over Signal

DPADefault Packet Application

Glossary

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


GL-3

DRCData Rate Control

....................................................................................................................................................................................................................................

E ECPExecutive Cellular Processor

EINEEthernet Interface Node

EMSElement Management SystemThe EMS is used for configuration of managed objects and to enter commands from theEMS Graphical User Interface (EMS-GUI) or Command Line Interface (CLI).

EMS GUIElement Management System Graphical User Interface

EQUEquivalent QoS Unit

ESNElectronic Serial Number

EV-DOEVolution Data Optimized

EV-DO Rev. AEVolution Data Optimized Rev. A (2 Mbps Peak using 1.25 Mhz, packet voice)

EVM1xEV-DO Modem

EVT/EVRExternal Voice Terminal Assembly/Vacuum Regulator

....................................................................................................................................................................................................................................

F FAFFeature Activation File

FIDFeature Identifier

FLForward Link

FMSFlexent Mobility Server

Glossary

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

FMSFile Transfer Protocol

FPGAFunctional Programmable Gate Array

FPPFast Protocol Processor

FSCFlexible Scheduler Choice

....................................................................................................................................................................................................................................

G GAUPGeneric Attribute Update Protocol

GMTGreenwich Mean Time

GUIGraphical User Interface

GZIPGNU Zip

....................................................................................................................................................................................................................................

H HAIHDR Air Interfaces

HLRHome Location Register

HOMHandoff Matrix

HRPDHigh Rate Packet DataCommonly known as 1xEV-DO, HRPD stands for″high rate packet data″. It is ahigh-speed CDMA-based wireless data technology developed by Qualcomm. It was alsoknown as HDR (high data rate) at one point. IS-856 is the official international standarddesignation.

HRPD RANHigh Rate Packet Data Radio Access Network

HRPD-AHigh Rate Packet Data Revision A (Rev. A)

Glossary

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


GL-5

HSCHardware System Commands

HW IDHardware ID

....................................................................................................................................................................................................................................

I IFHOInter-frequency Handoff

IMSIP Multimedia Subsystem

IMS TASIP Multimedia Subsystem Telephony Application Server

IMSIInternational Mobile Station Identity

IOSInteroperability Specification

IPInternet Protocol

IP/UDP/RTPInternal Protocol/Universal Datagram Protocol/Rate Time Protocol

IPBHInternet Protocol Backhaul

ISPInternet Service Provider

ISUPIntegrated Services User Part

IUPInter-User Priority

....................................................................................................................................................................................................................................

L LCPLink Control Procotol

LITLicense Installation Tool

Glossary

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

LL-MCSLow Latency Media Control Signaling

LLMLicense Limit Manager

....................................................................................................................................................................................................................................

M MACMedium Access Control

MCMulti Carrier

MCSMedia Control Signaling

MDCRMeasurement Data in Call Record

MEIDMobile Equipment Identifier

MFPAMulti-flow Packet Application

MIMManagement Information Model

MINMobile Identification Number

MLGMulti-Link Group

MLPPPMutli Link Point-to-Point Protocol

MM-APMobility Manager Application Processor

MN-IDMobile Node Identifier

MR-APSMulti-Router Automatic Protection Switching

MSCMobile Switching Center

Glossary

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


GL-7

MSIDMobile Station Identification

MTMRMaximum Sector Throughput after meeting Minimum User Rate Target

....................................................................................................................................................................................................................................

N NAKNot Acknowledged

NARNorth American Region

NCRMNode Card Resource Monitor

....................................................................................................................................................................................................................................

O OA&MOperations, Administration and MaintenanceGeneric name given to functions such as diagnostics, service measurements, and statusreports.

OFDMOrthogonal Frequency Division Multiplexing

OHMOverhead Manager

OHM-SFMOverhead Management-Selected Function Main

OHMATOverhead Manager Access Terminal

OLCSOnline Customer Support

OMC-RANOperations and Maintenance Center - Radio Access Network

OMC-RAN CORBAOperations and Maintenance Center - Radio Access Network CORBA AgentOMC-RAN CORBA Agent (ORCA is an agent process that provides a bridge betweenlegacy OA&M infrastructure and OMC-RAN. This is called mediation. It mediatesUX_messages into Management Information Model (MIM), receives events, alarms, andstatus information from cells/base stations, switches, trunk groups/members,reports/delivers alarm, status, and command responses to the OMC-RAN.

Glossary

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

OMPOperations and Maintenance Platform

OMP-FXOperations and Maintenance Platform for FlexentThis component provides a centralized point of access for wireless systems operationand maintenance. The OMP-FX provides a dedicated processor from which systemoperators can perform multiple operations, administration, and maintenance (OA&M)tasks simultaneously.

OMP-FX v.2Flexent Operations and Management Platform

ORCA-RNCOMC-RAN CORBA Agent - Radio Network Controller

OTAFOver-the-Air Activation Function

....................................................................................................................................................................................................................................

P PAFPhysical Antenna Face

PCFPacket Control Function

PCMDPer Call Measurement Data

PCSPersonal Communication Services

PDSNPacket Data Serving Node

PDSN-AAAPacket Data Serving Node-Accounting, Authentication and Authorization

PFProportional Fair

PFMRProportional Fair after meeting Minimum User Rate Target

PHYPHYsical

Glossary

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


GL-9

PPPPoint-to-Point Protocol

PSMMPilot Strength Measurement Message

PTTPush-to-Talk

....................................................................................................................................................................................................................................

Q QFAFQualified Feature Activation File

QoSQuality of Service

....................................................................................................................................................................................................................................

R RABReverse Activity Bit

RANRadio Access Network

RC/VRecent Change and VerifyUsed by CDMA users to access and update their database.

Rev. 0Revision 0

Rev. A(EVolution Data Optimized) Revision A (2 Mbps Peak using 1.25 Mhz, packet voice)

RFRadio Frequency

RNCRadio Network Controller

ROHCRobust Header Compression

ROPRead-Only-Printer

RoRReservation On Request

Glossary

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

RRLRestricted Root Login

RSSIReceived Signal Strength Indication

RTMRate Transition Matrix

RTPRate Transition Protocol

RTURight To Use

RUMRoute Update Message

....................................................................................................................................................................................................................................

S SB-EVMSingle Board-1xEV-DO Modem

SCService Class

SESSpecial Engineering Studies

SFMSelector Function Manager

SHLRStand-alone Home Location Register

SIPSession Initiation Protocol

SMService Measurements

SMSShort Message Service

SNService Node

SNIDService Node Identification

Glossary

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


GL-11

SSIRSession Status Information Record

SUSoftware Update

....................................................................................................................................................................................................................................

T TATest Application

TASFS5000 Telephony Application Server

TCSITraffic Channel Supervision Interval

TITechnician Interface

TPTraffic Processor

....................................................................................................................................................................................................................................

U UATIUnicast Access Terminal Identifier

UDPUniversal Database Protocol

UNCUniversal Network Cabinet

UNIXRegistered Trademark for theUNIX® Operating SystemAn interactive time-sharing operating system.

URCUniversal Radio Controller

UTPUniversal Traffic Processor

....................................................................................................................................................................................................................................

V VoIPVoice Over IP

Glossary

...................................................................................................................................................................................................................................


401-614-413Issue 5, May 2008

VTVideo Telephony

VT/VoIPVideo Telephony and Voice over IP

....................................................................................................................................................................................................................................

W WSPWireless Service Provider

Glossary

...................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


GL-13

Index

Symbols

/etc/inetd.conf file,5-14

/etc/services file,5-13

.............................................................

Numerics

401-662-102, OMP-FXOperation, Administration, &Maintenance Guide,5-68

.............................................................

A availability of the feature,4-5

Availability of the feature,6-3

availability of the feature,8-6

Availability of the feature,9-4,10-5, 11-3, 12-5, 13-3

availability of the feature,14-4,15-4

Availability of the feature,16-3

availability of the feature,17-5

.............................................................

B B-Server,5-11

.............................................................

C Caveats and issues,5-10

CFC Qualifier field,5-21

circuit data and packet dataapplications,5-7

command line

options,5-70

Comments, to submit,1-1, 2-2,3-2, 4-3, 6-2, 7-4, 8-5, 9-2,10-3, 11-2, 12-3, 13-2

comments, to submit,14-2,15-2

Comments, to submit,16-2

comments, to submit,17-3

Configured OMP ports,5-13

.............................................................

D Data delivery path diagram forOMP, 5-11

delimited ASCII version,5-13

Documentation, to order,1-1,2-2, 3-2, 4-3, 6-2, 7-4, 8-5,9-2, 10-3, 11-2, 12-3, 13-2

documentation, to order,14-2,15-2

Documentation, to order,16-2

documentation, to order,17-3

.............................................................

E EINE, 5-11

Ethernet Interface Node(EINE), 5-11

Example 1, post-processingtool, 5-15



.............................................................

H hardware requirements,1-4,2-4, 4-8, 5-13

Hardware requirements,6-4

hardware requirements,8-7

Hardware requirements,9-5,10-6, 11-4, 12-7, 13-4

hardware requirements,14-5,15-5

Hardware requirements,16-4

hardware requirements,17-7

human readable format,5-13

.............................................................

I Issues and caveats,5-10

.............................................................

M MDCR data record,5-27, 5-27,5-27, 5-27, 5-27, 5-27, 5-27,5-27, 5-36

MDCR Version,5-27

Move a 1xEV-DO cell(inter-RNC), 3-44

Move and Rename a cell(inter-RNC), 3-108

....................................................................................................................................................................................................................................401-614-413Issue 5, May 2008


IN-1

.............................................................

P packet data applications,5-7

pcmdviewer command,5-70

Port 5050 is,5-13

Port 5051 is,5-13

.............................................................

R Raw data example,5-47

raw format,5-13

requirements of the feature

hardware,1-4, 2-4, 4-8

Requirements of the feature

hardware,6-4


hardware,8-7


hardware,9-5, 10-6, 11-4,12-7, 13-4


hardware,14-5, 15-5


hardware,16-4


hardware,17-7


software,6-4, 9-5, 10-6,11-4, 12-6, 13-4, 16-4

.............................................................

S Serial number,5-27

Software requirements,6-4,9-5, 10-6, 11-4, 12-6, 13-4,16-4

stop the mdcrviewer tool,5-68

Storage of one hour of data,5-12

Support, to obtain technical,1-1, 2-2, 3-2, 4-3, 6-2, 7-4,8-5, 9-2, 10-3, 11-2, 12-3,13-2

support, to obtain technical,14-2, 15-2

Support, to obtain technical,16-2

support, to obtain technical,17-3

.............................................................

T Technical support, to obtain,1-1, 2-2, 3-2, 4-3, 6-2, 7-4,8-5, 9-2, 10-3, 11-2, 12-3,13-2

technical support, to obtain,14-2, 15-2

Technical support, to obtain,16-2

technical support, to obtain,17-3

Training, to order or registerfor, 1-1, 2-2, 3-2, 4-3, 6-2,7-4, 8-5, 9-2, 10-3, 11-2,12-3, 13-2

training, to order or registerfor, 14-2, 15-2

Training, to order or registerfor, 16-2

training, to order or registerfor, 17-3

.............................................................

V Verbose data example,5-48

verbose format,5-13

Verify that servicemeasurements are reported onnew RNC,3-132

Index

...................................................................................................................................................................................................................................

IN-2 Alcatel-Lucent - ProprietarySee notice on first page

401-614-413Issue 5, May 2008

Documents

401-614-413(EVDO PCMD)