1xev-do rf engineering

568
Title page Alcatel-Lucent Wireless Networks | Release 33.0 RF Engineering Guideline for 1xEV-DO Systems 401-614-323 ISSUE 16 OCTOBER 2009

Upload: cavin-wang

Post on 04-Mar-2015

354 views

Category:

Documents


2 download

TRANSCRIPT

Page 1: 1xev-Do Rf Engineering

Title page

Alcatel-Lucent Wireless Networks | Release 33.0RF Engineering Guideline for 1xEV-DO Systems

401-614-323

ISSUE 16

OCTOBER 2009

Page 2: 1xev-Do Rf Engineering

Legal notice

Legal notice

Alcatel, Lucent, Alcatel-Lucent and the Alcatel-Lucent logo are trademarks of Alcatel-Lucent. All other trademarks are the property of their respective

owners.

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

Copyright © 2009 Alcatel-Lucent. All rights reserved.

Interference information: Part 15 of FCC rules

This equipment has been tested and found to comply within the limits.

Limited warranty

Alcatel-Lucent provides a limited warranty to this product.

Page 3: 1xev-Do Rf Engineering

Contents

About this document

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

Reason for revision ................................................................................................................................................................... xxvxxv

Intended audience ................................................................................................................................................................. xxviiixxviii

Related documentation ........................................................................................................................................................ xxviiixxviii

Related training ........................................................................................................................................................................ xxixxxix

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

How to comment ...................................................................................................................................................................... xxixxxix

1 Introduction

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

Wireless Evolution to Third Generation (3G) Technology

Overview ....................................................................................................................................................................................... 1-41-4

ITU 3G Vision ............................................................................................................................................................................. 1-51-5

Radio environments .................................................................................................................................................................. 1-61-6

Standards ....................................................................................................................................................................................... 1-81-8

Technologies ............................................................................................................................................................................. 1-101-10

1xEV-DO .................................................................................................................................................................................... 1-121-12

Evolution from IS-95 to 3G-1X

Overview .................................................................................................................................................................................... 1-151-15

CDMA2000 ............................................................................................................................................................................... 1-161-16

Turbo Coder ............................................................................................................................................................................... 1-171-17

Power control ............................................................................................................................................................................ 1-191-19

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

401-614-323Issue 16 October 2009

iii

Page 4: 1xev-Do Rf Engineering

Introduction to 1xEV-DO

Overview .................................................................................................................................................................................... 1-201-20

Description of 1xEV-DO ...................................................................................................................................................... 1-211-21

Elimination of Voice Transmissions ................................................................................................................................. 1-221-22

1xEV-DO compatibility with voice .................................................................................................................................. 1-241-24

Forward Link Data Traffic Channel ................................................................................................................................. 1-261-26

Scheduling Algorithm ............................................................................................................................................................ 1-281-28

Reverse Link Data Traffic Channel .................................................................................................................................. 1-301-30

Changes and �ew Features Introduced in Rev A.

Overview .................................................................................................................................................................................... 1-311-31

Rev A Physical Layer subtypes .......................................................................................................................................... 1-321-32

Enhanced MAC Layer protocol ......................................................................................................................................... 1-331-33

Rev A features and schedule ................................................................................................................................................ 1-351-35

Basic Rev A Feature Bundle ................................................................................................................................................ 1-371-37

Enhanced Rev A Feature Bundle ....................................................................................................................................... 1-391-39

RA�Application Related Features ................................................................................................................................... 1-411-41

Latency issues resolved in Rev A ...................................................................................................................................... 1-441-44

Rev A enhancements (MAC and Physical Layers) ..................................................................................................... 1-451-45

Upper layer changes ............................................................................................................................................................... 1-471-47

2 Radio Access Network (RAN) Architecture

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

�etwork Data Flow

Overview ....................................................................................................................................................................................... 2-32-3

Radio Access System (RAS) ................................................................................................................................................ 2-42-4

IPAddress Assignment ............................................................................................................................................................ 2-72-7

Contents

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

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

iv 401-614-323Issue 16 October 2009

Page 5: 1xev-Do Rf Engineering

RA� �etwork Security

Overview ....................................................................................................................................................................................... 2-92-9

Release R21.0, Phase 1 ......................................................................................................................................................... 2-102-10

Release R22.0, Phase 2 .......................................................................................................................................................... 2-112-11

Release R23.0, Phase 3 ......................................................................................................................................................... 2-142-14

Data Interface Protocols

Overview .................................................................................................................................................................................... 2-152-15

Reference models .................................................................................................................................................................... 2-162-16

Protocol stack and data transfer ......................................................................................................................................... 2-182-18

Layers .......................................................................................................................................................................................... 2-202-20

Host-to-�etwork Interface ................................................................................................................................................... 2-232-23

1xEV-DO Rev 0 default architecture layers .................................................................................................................. 2-262-26

Rev A Enhanced Architecture Layers .............................................................................................................................. 2-292-29

Protocols ..................................................................................................................................................................................... 2-302-30

Simple IP and Mobile IP Internet Access

Overview .................................................................................................................................................................................... 2-332-33

RA� Protocol Interface ........................................................................................................................................................ 2-342-34

Simple IP connection ............................................................................................................................................................. 2-372-37

Simple IP Connection with Private �etwork ................................................................................................................ 2-382-38

Mobile IP Connection ............................................................................................................................................................ 2-412-41

Basic functionalities for VoIP ............................................................................................................................................. 2-442-44

Support for Evolved High Rate Packet Data (eHRPD) ............................................................................................. 2-452-45

Support for multi-carrier RevB .......................................................................................................................................... 2-472-47

Rev A�etwork Challenges

Overview .................................................................................................................................................................................... 2-522-52

IMS Core .................................................................................................................................................................................... 2-532-53

Contents

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

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

401-614-323Issue 16 October 2009

v

Page 6: 1xev-Do Rf Engineering

Header compression ............................................................................................................................................................... 2-562-56

End-to-End ................................................................................................................................................................................. 2-592-59

Delay budget ............................................................................................................................................................................. 2-622-62

Session Transfer Between 1xEV-DO and 3G-1X Systems

Overview .................................................................................................................................................................................... 2-662-66

Hybrid Access Terminal (AT) ............................................................................................................................................. 2-672-67

3G-1X Priority Over 1xEV-DO System ......................................................................................................................... 2-692-69

Access State ............................................................................................................................................................................... 2-702-70

Maintenance of PPP Sessions ............................................................................................................................................. 2-712-71

Location Update Protocol ..................................................................................................................................................... 2-722-72

Mobile IPAssignment ........................................................................................................................................................... 2-732-73

PPP Reconfiguration Trigger .............................................................................................................................................. 2-742-74

Location Tracking Value ....................................................................................................................................................... 2-752-75

Location Update Protocol Procedure ............................................................................................................................... 2-762-76

Location Update Feature (FID 10696.1) ......................................................................................................................... 2-772-77

Handoffs ..................................................................................................................................................................................... 2-792-79

Location Update Service Measurement .......................................................................................................................... 2-822-82

3 Air Interface

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

Introduction to 1xEV-DOAir Interface

Overview ....................................................................................................................................................................................... 3-43-4

Peak Data Rates .......................................................................................................................................................................... 3-53-5

1xEV-DO Channel Structure ................................................................................................................................................. 3-63-6

Forward Link Channels

Overview ....................................................................................................................................................................................... 3-73-7

Time-Share Sub-Channels ...................................................................................................................................................... 3-83-8

Contents

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

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

vi 401-614-323Issue 16 October 2009

Page 7: 1xev-Do Rf Engineering

Transmit Power ........................................................................................................................................................................... 3-93-9

1xEV-DO Frame and Time Slot Structure ..................................................................................................................... 3-103-10

Forward Traffic Channel

Overview .................................................................................................................................................................................... 3-123-12

Rev 0 Transmission Formats ............................................................................................................................................... 3-133-13

Rev Amultiple transmission format ................................................................................................................................. 3-153-15

Modulation and code rate ..................................................................................................................................................... 3-193-19

Modulation Type ...................................................................................................................................................................... 3-213-21

Bits Per Packet .......................................................................................................................................................................... 3-243-24

Multi_User packets ................................................................................................................................................................. 3-273-27

Single User MAC Layer packets ....................................................................................................................................... 3-293-29

Multiple User MAC Layer packets ................................................................................................................................... 3-323-32

MAC index ................................................................................................................................................................................ 3-333-33

Preamble Data ........................................................................................................................................................................... 3-343-34

Control and Pilot channels

Overview .................................................................................................................................................................................... 3-363-36

Control Channel ....................................................................................................................................................................... 3-373-37

Pilot Channel ............................................................................................................................................................................. 3-393-39

MediumAccess Control (MAC) Channel ...................................................................................................................... 3-403-40

Data transmission factors

Overview .................................................................................................................................................................................... 3-443-44

Incremental Redundancy ...................................................................................................................................................... 3-453-45

Packet Transmission termination ....................................................................................................................................... 3-473-47

Dynamic Rate Control ........................................................................................................................................................... 3-493-49

Rev AData Source Control (DSC) Channel .................................................................................................................. 3-513-51

Virtual Soft Handoff ............................................................................................................................................................... 3-543-54

Contents

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

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

401-614-323Issue 16 October 2009

vii

Page 8: 1xev-Do Rf Engineering

Rev-0 Scheduling

Overview .................................................................................................................................................................................... 3-563-56

Rev 0 Scheduling Algorithm ............................................................................................................................................... 3-573-57

Flexible Scheduler (FID 8948.0) Feature ....................................................................................................................... 3-583-58

Minimum and Maximum Throughput Target Service Measurements ................................................................. 3-613-61

G-Fair and RandomActivity Factor ................................................................................................................................. 3-633-63

Rev A Scheduler Algorithm

Overview .................................................................................................................................................................................... 3-643-64

Quality of service .................................................................................................................................................................... 3-653-65

Flows ............................................................................................................................................................................................ 3-663-66

Multi-user packet ..................................................................................................................................................................... 3-683-68

Reverse Link Traffic Channel

Overview .................................................................................................................................................................................... 3-703-70

Introduction ............................................................................................................................................................................... 3-713-71

Rev 0 Reverse Link Channel ............................................................................................................................................... 3-723-72

Reverse Traffic Channel ....................................................................................................................................................... 3-743-74

Pilot/RRI and Ack channels ................................................................................................................................................. 3-763-76

Data channel .............................................................................................................................................................................. 3-773-77

Packet size and interleaver ................................................................................................................................................... 3-793-79

Spreading .................................................................................................................................................................................... 3-803-80

Reverse Link - Rev 0 limitations ....................................................................................................................................... 3-813-81

Changes introduced in Rev A

Overview .................................................................................................................................................................................... 3-833-83

Sub-frames ................................................................................................................................................................................. 3-843-84

Reverse link incremental redundancy .............................................................................................................................. 3-873-87

Maximum 4 sub-frame duration ........................................................................................................................................ 3-893-89

Contents

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

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

viii 401-614-323Issue 16 October 2009

Page 9: 1xev-Do Rf Engineering

Reverse link payload size and modulation ..................................................................................................................... 3-903-90

Reverse link data rate selection .......................................................................................................................................... 3-923-92

T2P Target Level Request and Grant ............................................................................................................................... 3-933-93

Reverse data rate selection ................................................................................................................................................... 3-953-95

MAC subtype 3 ........................................................................................................................................................................ 3-963-96

Low-latency power boost transmission ........................................................................................................................... 3-973-97

Auxiliary Pilot channel .......................................................................................................................................................... 3-983-98

Rev 0 Access and Data channels ........................................................................................................................................ 3-993-99

Rev A Enhanced Access Channel .................................................................................................................................... 3-1013-101

Data rates and pilot channel .............................................................................................................................................. 3-1033-103

Test Application Feature

Overview .................................................................................................................................................................................. 3-1053-105

Introduction ............................................................................................................................................................................. 3-1063-106

Issuing commands ................................................................................................................................................................ 3-1073-107

Commands ............................................................................................................................................................................... 3-1083-108

4 Hardware Components

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

1xEV-DO Radio Access �etwork (RA�) ......................................................................................................................... 4-34-3

Flexent CDMABase Station Cabinet ................................................................................................................................ 4-44-4

CDMADigital Module (CDM) for IS-95 and 1X-3G ................................................................................................. 4-64-6

CDMADigital Module (CDM) for 1xEV-DO ................................................................................................................ 4-84-8

9218 Macro OneBTS Cabinet ............................................................................................................................................ 4-104-10

Multiple-Carrier Feature (FID-8219.1) ........................................................................................................................... 4-144-14

Support for five 1xEV-DO carriers (FID-8219.21) ..................................................................................................... 4-164-16

Support for six 1xEV-DO carriers (FID-8219.16) ..................................................................................................... 4-184-18

Support for Three 1xEV-DO Carriers with two URCIIs ........................................................................................... 4-214-21

Contents

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

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

401-614-323Issue 16 October 2009

ix

Page 10: 1xev-Do Rf Engineering

Support for Three 1xEV-DO Carriers .............................................................................................................................. 4-224-22

URC-II improvement supporting 3 DO carriers (FID-12078.44) ......................................................................... 4-234-23

Support For Multiple 1xEV-DO Carriers In Single EVM For The Single Sector Configuration .............. 4-244-24

Circuit Pack Location ............................................................................................................................................................ 4-274-27

Adding 1xEV-DO To AUTOPLEX® Cells ..................................................................................................................... 4-294-29

FMS andAP .............................................................................................................................................................................. 4-324-32

MFFU, RCC and Router ....................................................................................................................................................... 4-364-36

IP �etwork Elements ............................................................................................................................................................. 4-374-37

Deployment Scenarios ........................................................................................................................................................... 4-384-38

5 RF Coverage and Capacity

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

Reverse Link Budget Analysis

Overview ....................................................................................................................................................................................... 5-35-3

Reverse link description .......................................................................................................................................................... 5-45-4

Maximum Path Loss ................................................................................................................................................................. 5-65-6

Reverse Link Budget ................................................................................................................................................................ 5-95-9

Radiated power, antenna gain and losses ........................................................................................................................ 5-145-14

Total Effective �oise plus Interference Density .......................................................................................................... 5-155-15

Receiver Sensitivity ................................................................................................................................................................ 5-195-19

Required Eb/�t, Item l .......................................................................................................................................................... 5-215-21

Soft Handoff Gain ................................................................................................................................................................... 5-245-24

Path loss ...................................................................................................................................................................................... 5-255-25

Forward Link Budget Analysis

Overview .................................................................................................................................................................................... 5-285-28

Forward link description ....................................................................................................................................................... 5-295-29

Forward Link factors .............................................................................................................................................................. 5-315-31

Contents

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

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

x 401-614-323Issue 16 October 2009

Page 11: 1xev-Do Rf Engineering

Link Budget Calculation ....................................................................................................................................................... 5-345-34

Forward Link Budge Spreadsheet ..................................................................................................................................... 5-365-36

Transmit Power Calculation ................................................................................................................................................ 5-425-42

Total Interference ..................................................................................................................................................................... 5-445-44

Capacity Overview

Overview .................................................................................................................................................................................... 5-485-48

Rev A and Rev 0 Sector capacity ....................................................................................................................................... 5-495-49

Capacity/Coverage Trade-off .............................................................................................................................................. 5-505-50

Pole Capacity ............................................................................................................................................................................ 5-525-52

Reverse Link Capacity

Overview .................................................................................................................................................................................... 5-545-54

Spectral �oise Density .......................................................................................................................................................... 5-555-55

Pole Capacity Calculation .................................................................................................................................................... 5-575-57

Channel Gain ............................................................................................................................................................................ 5-595-59

Interference ratio and channel activity ............................................................................................................................ 5-625-62

Increased capacity in the reverse link .............................................................................................................................. 5-645-64

Traffic Model ............................................................................................................................................................................ 5-655-65

RevA performance ................................................................................................................................................................. 5-675-67

Pole Point Based Capacity Calculation ........................................................................................................................... 5-695-69

Capacity Objectives ................................................................................................................................................................ 5-715-71

Data Traffic Load in Erlangs ............................................................................................................................................... 5-725-72

Determining Average �umber of Reverse Link Channels Required .................................................................... 5-755-75

Forward Link Capacity

Overview .................................................................................................................................................................................... 5-785-78

Geometry .................................................................................................................................................................................... 5-795-79

Sector Throughput ................................................................................................................................................................... 5-805-80

Contents

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

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

401-614-323Issue 16 October 2009

xi

Page 12: 1xev-Do Rf Engineering

6 Frequency Assignment

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

Deployment .................................................................................................................................................................................. 6-26-2

FrequencyAssignment ............................................................................................................................................................. 6-36-3

Cellular Band ............................................................................................................................................................................... 6-56-5

PCS Band ................................................................................................................................................................................... 6-106-10

Guard Band ................................................................................................................................................................................ 6-116-11

Carrier Spacing ......................................................................................................................................................................... 6-136-13

Dual Band Carriers ................................................................................................................................................................. 6-156-15

7 Call Processing

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

Initiating a call

Overview ....................................................................................................................................................................................... 7-47-4

1xEV-DO Call Processing Overview ................................................................................................................................. 7-57-5

Air Link Management Protocol ............................................................................................................................................ 7-77-7

Access Probe Structure .......................................................................................................................................................... 7-107-10

Initialization State ................................................................................................................................................................... 7-137-13

Idle State ..................................................................................................................................................................................... 7-157-15

Authentication .......................................................................................................................................................................... 7-187-18

Idle Mode Sub-States ............................................................................................................................................................. 7-207-20

Monitor Sub-State ................................................................................................................................................................... 7-227-22

Default Sleep Sub-State ........................................................................................................................................................ 7-247-24

Rev A Enhanced Idle State Protocol ................................................................................................................................. 7-267-26

Page mask .................................................................................................................................................................................. 7-287-28

Idle State Pilot Channel Supervision ................................................................................................................................ 7-307-30

Connection setup ..................................................................................................................................................................... 7-347-34

Contents

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

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

xii 401-614-323Issue 16 October 2009

Page 13: 1xev-Do Rf Engineering

Fast Connect Setup ................................................................................................................................................................. 7-377-37

Configuration �egotiation to Open a Session .............................................................................................................. 7-397-39

Configuration �egotiation Procedure .............................................................................................................................. 7-417-41

PPP Connection ........................................................................................................................................................................ 7-437-43

Session Maintenance .............................................................................................................................................................. 7-457-45

Messages during inactivity .................................................................................................................................................. 7-477-47

Paging

Overview .................................................................................................................................................................................... 7-497-49

Paging types .............................................................................................................................................................................. 7-507-50

Terms used with paging ........................................................................................................................................................ 7-517-51

EVDO paging considerations ............................................................................................................................................. 7-537-53

Default paging with neither QoS or DOS ....................................................................................................................... 7-557-55

QoS paging for Profile IDs .................................................................................................................................................. 7-567-56

1xEV-DO Basic PTT using 1xEV-DO Rev A�etworks .......................................................................................... 7-587-58

1xEV-DO PTT Paging Enhancements ............................................................................................................................. 7-607-60

Parameters .................................................................................................................................................................................. 7-627-62

Paging controls example ....................................................................................................................................................... 7-637-63

Distance based paging operation ....................................................................................................................................... 7-657-65

Deriving Route Update Message distance ..................................................................................................................... 7-667-66

QoS paging with DOS ........................................................................................................................................................... 7-687-68

Resource allocation

Overview .................................................................................................................................................................................... 7-707-70

Traffic Channel Resource Allocation ............................................................................................................................... 7-717-71

RTC Parameters ....................................................................................................................................................................... 7-727-72

Indices and P� offset ............................................................................................................................................................. 7-737-73

RAB Offset/RAB Length ..................................................................................................................................................... 7-747-74

Handoff introduction .............................................................................................................................................................. 7-767-76

Contents

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

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

401-614-323Issue 16 October 2009

xiii

Page 14: 1xev-Do Rf Engineering

Pilot Sets ..................................................................................................................................................................................... 7-777-77

Pilot Drop Timer Maintenance ........................................................................................................................................... 7-787-78

Active Set Management ........................................................................................................................................................ 7-817-81

Candidate Set Management ................................................................................................................................................. 7-857-85

�eighbor Set Management .................................................................................................................................................. 7-867-86

Virtual Soft Handoff ............................................................................................................................................................... 7-897-89

Support for Multiple 1xEV-DO Carriers - IFHO, FID 8219.11 ............................................................................. 7-917-91

Other handoffs .......................................................................................................................................................................... 7-977-97

1xEV-DO Distance Based Handoff (FID 13579.0) .................................................................................................... 7-997-99

BroadCast and MultiCast Service (BCMCS) ............................................................................................................. 7-1027-102

Power control

Overview .................................................................................................................................................................................. 7-1077-107

Rev 0 Power control ............................................................................................................................................................ 7-1087-108

Rev 0 Overload control ....................................................................................................................................................... 7-1117-111

Rev A power and overload control ................................................................................................................................. 7-1147-114

Leaky bucket control mechanism .................................................................................................................................... 7-1177-117

RAB bit load control and RoT ......................................................................................................................................... 7-1207-120

Glossary

Index

Contents

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

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

xiv 401-614-323Issue 16 October 2009

Page 15: 1xev-Do Rf Engineering

List of tables

1-1 Fundamental Differences between 3G-1X and 1xEV-DO ....................................................................... 1-121-12

3-1 Rev 0 Transmission Formats ............................................................................................................................... 3-133-13

3-2 Rev A transmission formats ................................................................................................................................. 3-163-16

3-3 Transmission Format Code Rate and Transmission Type ........................................................................ 3-193-19

3-4 Forward Channel data rate - bit size vs slot duration ................................................................................. 3-283-28

3-5 Max Index .................................................................................................................................................................. 3-333-33

3-6 Reverse Link Data Rates for Traffic Data and Access Channels ........................................................... 3-723-72

3-7 Relationship Between Physical Layer Packet Bit Size and Code Symbol Bit Size at Different Data

Rates ......................................................................................................................................................................... 3-773-77

3-8 Reverse link payload size and modulation ..................................................................................................... 3-903-90

3-9 Modulation code ...................................................................................................................................................... 3-913-91

3-10 DRCRATE Values ................................................................................................................................................ 3-1083-108

3-11 Test Duration Code .............................................................................................................................................. 3-1093-109

5-1 MaximumAT Transmit Power .............................................................................................................................. 5-75-7

5-2 PCS Reverse Link Budget Spreadsheet ............................................................................................................. 5-95-9

5-3 PCS 1xEV-DO Rev A reverse link budget (first 6 lower data rates) .................................................... 5-115-11

5-4 PCS 1xEV-DO Rev A reverse link budget (last 6 upper data rates) ..................................................... 5-125-12

5-5 Reverse Link Required Eb/�t Values .............................................................................................................. 5-215-21

5-6 Probability Of Edge Coverage vs. Fade Margin .......................................................................................... 5-265-26

5-7 Required Traffic Channel Forward Link Eb/�o Value .............................................................................. 5-315-31

5-8 Forward Link Budget Spreadsheet for PCS Band ....................................................................................... 5-365-36

5-9 Rev A Forward link budget (4.8 kbps through 76.8 kbps) ....................................................................... 5-385-38

5-10 Rev A Forward link budget (153.6 kbps through 1228.8 kbps) ............................................................. 5-395-39

5-11 Rev A Forward link budget (1536.0 kbps through 3072.0 kbps) ........................................................... 5-405-40

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

401-614-323Issue 16 October 2009

xv

Page 16: 1xev-Do Rf Engineering

5-12 Edge Coverage For Interference Limited Case ............................................................................................ 5-465-46

5-13 Rev 0/Rev A per-sector capacity ....................................................................................................................... 5-495-49

5-14 Required Pilot Channel Ec/�t (δ ) ...................................................................................................................... 5-595-59

5-15 Traffic Channel Gain ............................................................................................................................................. 5-605-60

5-16 DRC Gain .................................................................................................................................................................. 5-605-60

5-17 Interference Ratio β ................................................................................................................................................ 5-625-62

5-18 Reverse Link �et Throughput ............................................................................................................................ 5-635-63

5-19 Power level required to achieve termination target .................................................................................... 5-645-64

5-20 HTTP Traffic Model Parameters ....................................................................................................................... 5-655-65

5-21 MaximumActive Data Sessions at 72% Loading for Full Buffer Traffic Model ............................ 5-695-69

5-22 MaximumActive Data Sessions at 72% Loading for Web Browsing Traffic Model .................... 5-705-70

5-23 Erlang capacity (Delay Ratio = 0.2, α = 1) .................................................................................................... 5-755-75

5-24 Erlang Capacity (Delay Ratio = 0.2, α = VAF1) .......................................................................................... 5-765-76

6-1 AMPS and CDMAChannel �umbers and Corresponding Frequencies For Band Class 0 ........... 6-76-7

6-2 Recommended A-Band CDMACenter Frequency Assignments ............................................................. 6-86-8

6-3 Recommended B-Band CDMACenter Frequency Assignments ............................................................. 6-96-9

6-4 1xEV-DO Channel Allocation Availability For Band Class 1 ................................................................ 6-116-11

6-5 Preferred CDMAChannels For Band Class 1 .............................................................................................. 6-136-13

7-1 Access Probe Related Translation Parameters ................................................................................................ 7-87-8

7-2 Power savings achieved by early termination ............................................................................................ 7-1147-114

List of tables

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

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

xvi 401-614-323Issue 16 October 2009

Page 17: 1xev-Do Rf Engineering

List of figures

1-1 ITU'S IMT-2000 Vision Minimum Data Rates ............................................................................................... 1-61-6

1-2 Interpretability of Standard IMT-2000 Services ............................................................................................. 1-91-9

1-3 Global Wireless Standards Evolution .............................................................................................................. 1-111-11

1-4 �ew Data Rates ....................................................................................................................................................... 1-141-14

1-5 Turbo Coder .............................................................................................................................................................. 1-181-18

1-6 MAC Layer Subtype .............................................................................................................................................. 1-331-33

1-7 Modem Upgrades Prior R27 ............................................................................................................................... 1-361-36

1-8 Basic Rev A Feature Bundle ............................................................................................................................... 1-371-37

1-9 Enhanced Rev A Feature Bundle ....................................................................................................................... 1-391-39

1-10 RA�Application Related Features .................................................................................................................. 1-411-41

2-1 Radio Access System (RAS) ................................................................................................................................. 2-42-4

2-2 R1SR R�C �etwork ............................................................................................................................................ 2-122-12

2-3 OSI to TCP/IP Reference ModelMap ............................................................................................................. 2-162-16

2-4 AT Protocol Stacks Interface .............................................................................................................................. 2-182-18

2-5 1xEV-DO Protocol Architecture IA-856A ..................................................................................................... 2-242-24

2-6 Enhanced 1xEV-DO Protocol Architecture IA-856A-A ........................................................................... 2-292-29

2-7 RA� Protocol Interface ........................................................................................................................................ 2-342-34

2-8 RA� to VP� Connectivity via the Internet ................................................................................................... 2-392-39

2-9 Simple IP Connection with Private �etwork, Protocol Stack ................................................................ 2-402-40

2-10 Mobile IP Internet Access .................................................................................................................................... 2-422-42

2-11 Mobile IP Internet Access, Protocol Stack ..................................................................................................... 2-432-43

2-12 RA� Interface with an IMS Core ..................................................................................................................... 2-542-54

2-13 VoIP Transmission Without Header Compression ...................................................................................... 2-572-57

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

401-614-323Issue 16 October 2009

xvii

Page 18: 1xev-Do Rf Engineering

2-14 RObust Header Compression (ROHC) ........................................................................................................... 2-58

2-15 End-to-End Protocol Stack for VoIP ................................................................................................................ 2-59

2-16 Signaling using SIP ................................................................................................................................................ 2-60

2-17 End-to-End Delay Guideline for VoIP ............................................................................................................. 2-61

2-18 Mobile to Wireline End-to-End Delay Budget ............................................................................................. 2-63

2-19 Landline to Mobile End-to-End Delay Budget ............................................................................................ 2-64

2-20 Mobile to Mobile End-to-End Delay Budget ................................................................................................ 2-65

2-21 Hybrid AT State Diagram ..................................................................................................................................... 2-68

2-22 Inter-System Handoff ............................................................................................................................................ 2-79

3-1 1xEV-DO Channel Structure ................................................................................................................................. 3-6

3-2 Comparison of 3G-1X and 1xEV-DO base station Transmit Power Sharing ...................................... 3-9

3-3 1xEV-DO Frame and Time Slot Structure ..................................................................................................... 3-10

3-4 Idle Time Slot ........................................................................................................................................................... 3-11

3-5 Quadrature Phase Shift Keying (QPSK) Constellation ............................................................................. 3-21

3-6 8 Phase Shift Keying (8PSK) Constellation .................................................................................................. 3-22

3-7 16 Quadrature Amplitude Modulation (16QAM) Constellation ............................................................ 3-23

3-8 Traffic Data Channel Physical Layer Packet Bit Size ............................................................................... 3-25

3-9 Single User MAC Layer packets ....................................................................................................................... 3-30

3-10 Multiple User MAC Layer packets .................................................................................................................. 3-32

3-11 Preamble Bits Insertion for data rates of 38.4 kbps and 76.8 kbps ....................................................... 3-35

3-12 Control Channel Timing ....................................................................................................................................... 3-37

3-13 Control Channel Structure Physical Layer Packet Bit Size ..................................................................... 3-38

3-14 Pilot Pulse Burst Timing ....................................................................................................................................... 3-39

3-15 Generation of the MAC Channel ....................................................................................................................... 3-41

3-16 MAC Channel Multiplexing ............................................................................................................................... 3-43

3-17 Multi-Slot Data Interlacing with �ormal Termination .............................................................................. 3-46

3-18 Multi-Slot Data Interlacing with Early Termination .................................................................................. 3-48

List of figures

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

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

xviii 401-614-323Issue 16 October 2009

Page 19: 1xev-Do Rf Engineering

3-19 DRC Offset lookup table ...................................................................................................................................... 3-50

3-20 DSC Timing .............................................................................................................................................................. 3-52

3-21 DSC Selection .......................................................................................................................................................... 3-53

3-22 Virtual Soft Handoff ............................................................................................................................................... 3-54

3-23 Reverse Channel Structure .................................................................................................................................. 3-72

3-24 Generation of Reverse Traffic Channel ........................................................................................................... 3-74

3-25 Reverse Traffic Sub-Channels ............................................................................................................................ 3-75

3-26 Reverse Traffic Data Channel Physical Layer Packet Bit Size .............................................................. 3-79

3-27 Sub-frame structure ................................................................................................................................................ 3-85

3-28 Reverse link channel coding – I-Phase ........................................................................................................... 3-86

3-29 Reverse link incremental redundancy .............................................................................................................. 3-87

3-30 Maximum four sub-frame duration .................................................................................................................. 3-89

3-31 T2P Target Level Request and Grant ............................................................................................................... 3-93

3-32 Low-latency power boost transmission ........................................................................................................... 3-97

3-33 Auxiliary Pilot channel ......................................................................................................................................... 3-98

3-34 Reverse Access Channel Physical Layer Packet Bit Size ........................................................................ 3-99

3-35 Access Probe .......................................................................................................................................................... 3-100

3-36 Generation of Reverse Access Channel ........................................................................................................ 3-102

3-37 Enhanced Access Channel MAC .................................................................................................................... 3-104

4-1 Flexent® CDMABase Station Cabinet Structure .......................................................................................... 4-5

4-2 CDMADigital Module (CDM) for IS-95 and 3G-1X ................................................................................. 4-7

4-3 CDMADigital Module (CDM) for 1xEV-DO ................................................................................................ 4-9

4-4 9218 Macro Cabinet ............................................................................................................................................... 4-10

4-5 Digital Shelf Signal Flow ..................................................................................................................................... 4-12

4-6 9218 Macro Digital Shelf Card Location ....................................................................................................... 4-27

4-7 Collocation of 1xEV-DO Base Station with PCS CDMAMinicell ...................................................... 4-30

4-8 Collocation of 1xEV-DO Base Station with CDMA AUTOPLEX® Series II DDGF Cells ......... 4-31

List of figures

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

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

401-614-323Issue 16 October 2009

xix

Page 20: 1xev-Do Rf Engineering

4-9 1xEV-DO Flexent®Mobility Server (FMS) Cabinet ................................................................................. 4-33

4-10 1xEV-DOApplication Processor (400S Server) .......................................................................................... 4-35

5-1 Components of �et Path Loss fromAT to Base Station ............................................................................. 5-6

5-2 Equation 1 .................................................................................................................................................................... 5-7

5-3 Equation 2 .................................................................................................................................................................... 5-7

5-4 Path Loss Slope ........................................................................................................................................................ 5-16

5-5 Determining Receiver Interference Margin ................................................................................................... 5-18

5-6 Equation 3 .................................................................................................................................................................. 5-19

5-7 Equation 4 .................................................................................................................................................................. 5-19

5-8 Relationship Between Vehicle Speed and Eb/�t Value ............................................................................. 5-22

5-9 Propagation Loss ..................................................................................................................................................... 5-26

5-10 Percentage of Area Covered Vs. Data Rate ................................................................................................... 5-29

5-11 Equation 5 .................................................................................................................................................................. 5-34

5-12 Equation 6 .................................................................................................................................................................. 5-34

5-13 Equation 7 .................................................................................................................................................................. 5-35

5-14 Equation 8 .................................................................................................................................................................. 5-35

5-15 Equation 9 .................................................................................................................................................................. 5-35

5-16 Equation 10 ............................................................................................................................................................... 5-44

5-17 Equation 11 ................................................................................................................................................................ 5-45

5-18 Equation 12 ............................................................................................................................................................... 5-45

5-19 Equation 13 ............................................................................................................................................................... 5-45

5-20 Determining Receiver Interference Margin ................................................................................................... 5-53

5-21 Equation 14 ............................................................................................................................................................... 5-55

5-22 Equation 15 ............................................................................................................................................................... 5-57

5-23 Equation 16 ............................................................................................................................................................... 5-57

5-24 Equation 17 ............................................................................................................................................................... 5-58

5-25 Equation 18 ............................................................................................................................................................... 5-58

List of figures

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

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

xx 401-614-323Issue 16 October 2009

Page 21: 1xev-Do Rf Engineering

5-26 Equation 19 ............................................................................................................................................................... 5-585-58

5-27 RevA performance ................................................................................................................................................. 5-685-68

5-28 General Erlang Model ........................................................................................................................................... 5-735-73

5-29 Aggregated Sector Throughput .......................................................................................................................... 5-815-81

6-1 Cellular Carrier Waveform Centered on Channel 283 at 878.49 MHz .................................................. 6-46-4

6-2 Distribution of Cellular Frequency Bands ........................................................................................................ 6-66-6

6-3 Distribution of the Personnel Communication System (PCS) Spectrum ........................................... 6-106-10

7-1 Connection Layer of 1xEV-DO TIA-856-A Protocol Architecture ......................................................... 7-57-5

7-2 1xEV-DO Operation ................................................................................................................................................. 7-67-6

7-3 Access Probe Structure ......................................................................................................................................... 7-107-10

7-4 Access Probe Sequence ......................................................................................................................................... 7-117-11

7-5 Initialization State Flow Diagram ..................................................................................................................... 7-147-14

7-6 UATIRequest Message .......................................................................................................................................... 7-167-16

7-7 Equation 1 .................................................................................................................................................................. 7-177-17

7-8 Authentication Challenge ..................................................................................................................................... 7-187-18

7-9 Idle Sub-States ......................................................................................................................................................... 7-207-20

7-10 Sleep Mode Slotted Control Cycle ................................................................................................................... 7-247-24

7-11 Enhanced Idle State ................................................................................................................................................ 7-267-26

7-12 Page Mask Periods .................................................................................................................................................. 7-287-28

7-13 Idle State Pilot Supervision ................................................................................................................................. 7-327-32

7-14 Traffic Channel Request Response to Page ................................................................................................... 7-357-35

7-15 Fast Connection Setup ........................................................................................................................................... 7-377-37

7-16 TIA-856A Session Layer ...................................................................................................................................... 7-407-40

7-17 Session Configuration �egotiations ................................................................................................................. 7-427-42

7-18 Establishing PPP Connection .............................................................................................................................. 7-437-43

7-19 Equation 2 .................................................................................................................................................................. 7-747-74

7-20 Dynamic Pilot Drop Threshold .......................................................................................................................... 7-797-79

List of figures

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

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

401-614-323Issue 16 October 2009

xxi

Page 22: 1xev-Do Rf Engineering

7-21 Inequality 1 ................................................................................................................................................................ 7-797-79

7-22 Adding A Pilot P� to the Active Set ................................................................................................................ 7-827-82

7-23 Inequality 2 ................................................................................................................................................................ 7-837-83

7-24 Inequality 3 ................................................................................................................................................................ 7-847-84

7-25 �eighbor List Ranking .......................................................................................................................................... 7-877-87

7-26 Combined �eighbor List ...................................................................................................................................... 7-887-88

7-27 Virtual Soft Handoff ............................................................................................................................................... 7-897-89

7-28 IFHO Decision Flow Chart ................................................................................................................................. 7-937-93

7-29 BCMCS distribution ............................................................................................................................................ 7-1037-103

7-30 BCMCS channel interlace ................................................................................................................................. 7-1047-104

7-31 BCMCS Dynamic Registration Request ...................................................................................................... 7-1057-105

7-32 Independent relationship between the Transition Point and Termination Target ........................... 7-1167-116

7-33 Leaky bucket control mechanism ................................................................................................................... 7-1177-117

7-34 Supporting bursty traffic .................................................................................................................................... 7-1187-118

List of figures

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

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

xxii 401-614-323Issue 16 October 2009

Page 23: 1xev-Do Rf Engineering

About this documentAbout this document

Purpose

This document, RF Engineering Guideline for 1xEV-DO Systems,, 401-614-323, provides

RF engineering guideline and recommendations for 1xEV-DO deployment. 1xEV-DO is a

wireless high data rate technology that optimized for data.

�ote:Alcatel-Lucent has changed the name of products within the CDMA portfolio.

The product previously known as has been renamed and is now referredto as

Base Station 8300 or Modcell 4.0 9218 Base Station Macro or 9218 Modcell

Base Station 8310 or High Density 4.0 9218 Base Station High Density or 9218 High

Density

Base Station 6300 or Compact 4.0 9216 Base Station Compact or 9216 Compact

Base Station 8400 or Modcell 4.0B 9228 Base Station Modcell or 9228 Modcell

Base Station 8410 or 4.0B High Density 9228 Base Station High Density or 9228 High

Density

OMC-RA� 9253 OMC-RA�

The use of any of these names in this document refer to the same product and

functionality.

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

401-614-323Issue 16 October 2009

xxiii

Page 24: 1xev-Do Rf Engineering

The document is divided into seven chapters

• Chapter 1, Introduction, provides introduction to 1xEV-DO technology and traces its

wireless evolution in third generation (3G) technology from IS-95 and 3G-1X, finally

• Chapter 2, Radio Access �etwork (RA�) Architecture, discusses the major

components in the Radio Access �etwork and how data is propagated from source to

destination. An overall description of each major network component is presented in

terms of its physical and functional makeup. The importance of protocol stacks

associated with each component is presented along with a description of each protocol

layer. This chapter also describes IP address assignments and the difference between

simple and mobile IP addresses.

• Chapter 3, Air Interface, discusses the makeup and characteristics of the forward

(downlink) and reverse (uplink) channels. The 1xEV-DO air interface characteristics,

which are dictated by the 1xEV-DO Physical Layer protocol, vary as a function of

channel type and information data rate. The chapter will introduce the 1xEV-DO

scheduling algorithm, which is one of the main differentiating characteristic between

1xEV-DO systems and IS-95 and 3G-1X systems.

• Chapter 4, Hardware Components, provides a high-level discussion of the

Alcatel-Lucent equipment that supports 1xEV-DO deployment. 1xEV-DO technology

is designed to protect the investment of existing CDMA service providers by using the

same RF carriers as in IS-95 and 3G-1X. While the Physical Layer of 1xEV-DO,

identifying channel encoding, and channel structure differ greatly from IS-95 and

3G-1X, the RF signal and the 1.25-MHz bandwidth are compatible with

IS-95/3G-1X.

• Chapter 5, RF Coverage and Capacity, describes the components used for the

calculation of the Reverse link (uplink) and forward link (downlink) budgets. These

link budgets are used to determine the base station coverage area for a desirable data

rate at the cell forward edge. .

• Chapter 6, Frequency Assignmentdescribes wireless frequency assignments for

overlay and standalone deployment and the RF characteristics of the 1xEV-DO carrier

waveform.

• Chapter 7, Call Processing, describes call processing, which is concerned with the

establishment and maintenance of airlink channels between the AT and RA�. Most of

call processing operation is governed by a set of protocols at the Connection Layer of

the TIA-856A protocol stack. Protocols within this layer control the AT's operating

states from the time the AT is powered on. This chapter discusses the AT operating

states from the Initialization State, when powered up, through the Idle State, to the

Connection State, when a traffic channel is assigned to a call. In addition, describe

call handoff, base station transmit power control, and overload control

About this document

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

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

xxiv 401-614-323Issue 16 October 2009

Page 25: 1xev-Do Rf Engineering

Reason for revision

Issue 16, Release 33 provides support for the following FIDs:

FID Where discussed

10696.1 “Location Update Feature (FID 10696.1)” (p. 2-77)

13500.2 “Support for multi-carrier RevB” (p. 2-47)

39111.10 “Support for Evolved High Rate Packet Data (eHRPD)”

(p. 2-45)

Issue 15, Release 32 provides support for the following FIDs:

FID Where discussed

8219.16 “Support for six 1xEV-DO carriers (FID-8219.16) ” (p. 4-18)

12589.0 “R�C limits” (p. 2-6)

12780.7 Figure 2-2, “R1SR R�C �etwork ” (p. 2-12)

13682.1 “Other delays” (p. 2-65)

Notes:

1. FID 14180.0 is not supported in Release 32.0; support will be available in a later release. As

of R32, the maximum number of R�Cs allowed per service node is 6.

Issue 14, Release 31.1, provides the support for the following FIDs:

FID Where discussed

8219.14 “Support For Multiple 1xEV-DO Carriers In Single EVM For

The Single Sector Configuration” (p. 4-24)

8219.21 “Support for five 1xEV-DO carriers (FID-8219.21)” (p. 4-16)

Issue 13 provides the support for the following FIDs:

FID Where discussed

8219.8 “Support for Three 1xEV-DO Carriers” (p. 4-22)

12078.44 “Applicable BTS Platform type with feature dependency”

(p. 4-22)

“Example of Support for Three 1xEV-DO Carriers” (p. 4-22)

“URC-II improvement supporting 3 DO carriers

(FID-12078.44)” (p. 4-23)

About this document

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

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

401-614-323Issue 16 October 2009

xxv

Page 26: 1xev-Do Rf Engineering

FID Where discussed

12102.2 “Voice over IP Related Features” (p. 1-42)

“Basic functionalities for VoIP” (p. 2-44)

13579 “1xEV-DO Distance Based Handoff (FID 13579.0)” (p. 7-99)

Issue 12 provides a description of FID-8219.17 - Support for Three 1xEV-DO Carriers

with two URCIIs. See “Support for Three 1xEV-DO Carriers with two URCIIs” (p. 4-21)

for more information.

Issue 11 provides descriptions of features to enhance paging. Information on these

features is in “Paging types” (p. 7-50).

Issue 10 describes support for BC0/BC1 Dual Band 1xEV-DO. This feature, FID 8219.7,

enables the support of BC0/BC1 dual band in the 1xEV-DO system. BC0 is the cellular

(850) frequency band and BC1 is the PCS (1900) frequency band. Information in this

feature is in “Dual Band Carriers” (p. 6-15).

Because Rev A functions have been offered after the inclusion of the dual band software

(8219.2), this feature will also include the testing of dual band BC0/BC1 using Rev 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)

Issue 8 introduce all the revisions introduced in Rev A. In addition to Voice over IP

(VoIP) services, 1xVE-DO Rev A upgraded networks will profoundly enhance user

service by enabling a wide variety of applications. These services include interactive 3D

gaming among large groups of players, FTP, instant messaging with full multimedia

content, push-to-talk (PTT) communication, video telephony.

In compliance with ITU-856-A standard, Alcatel-Lucent has bundled separate features in

its Rev A product that is scheduled for release in R26 and R27. The necessary hardware,

such as the single board EVM, is released in R26. Full deployment is in R27. Although

Rev A air interface enhancements are primarily influenced at the MAC and Physical

Layers, this upgrade affects all protocol layers and, therefore its operation touches on all

aspects of 1xEV-DO technology to varying degrees.

Unlike Rev 0, end-to-end delay performance to reduce latency is critical for optimizing

the air-interface and capacity in Rev A. Implementation of applications that will be

offered in Rev A, such as the Alcatel-Lucent end-to-end solution for VoIP, is

fundamentally designed to operate on an IMS core network. AlthoughAlcatel-Lucent's or

any other IMS core network is not an absolute requirement, the core network must

comply with IMS standard specifications such as 835-D for Rev A for QoS

implementation.

About this document

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

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

xxvi 401-614-323Issue 16 October 2009

Page 27: 1xev-Do Rf Engineering

Issue 7 describe the Support for Multiple 1xEV-DO Carriers - IFHO, FID 8219.11

(“Introduction” (p. 7-91)), which is introduced in Release 26. The feature uses the

multiple-carrier feature, introduced in Release R25.0, to enable 1xEV-DO carrier

inter-frequency handoff (IFHO), which is a hard handoff. The feature is used in areas

where multiply carriers are provided when a different carrier frequency becomes more

attractive than the ATs current carrier frequency. The implementation of this feature

improves session transfer time to provide a smooth transition for real-time applications

such as streaming video and audio when an AT user moves into a sector where the AT's

current carrier frequency is not available.

In addition this issue introduces the Single-Board EVM (SB-EVMm for Modular Cells 1,

2, and 3, and SB-EVM for Modular Cell 4, “Base Station cabinetsFlexent® CDMABase

Station Cabinet” (p. 4-4)) requiring one plug-in slot. The SB-EVM/SB-EVMm card,

which provides same functionality as the two-board EVM, is required for 1xEV-DO Rev

A deployment in release R27.0. Rev Awill permit interactive voice communication via

Voice over IP (VoIP) over the 1xEV-DO network. In addition to VoIP services, Rev A

upgraded networks will profoundly enhance user service by enabling a wide variety of

applications. These services include interactive 3D gaming among large groups of

players, FTP, instant messaging with full multimedia content, and video telephony.

Issue 6 coves the Multiple-Carrier Feature (FID-8219.1) which is introduced in Release

R25. Depending on the base station configuration, this feature (“Multiple-Carrier Feature

(FID-8219.1)” (p. 4-14)) permits two or three 1xEV-DO carriers at a single base station.

Issue 5 was published to include the multi-carrier radio (MCR) and the Ethernet Backhaul

support introduced in Release R24.0.This issue also provides a description of the Hybrid

Access Terminal (AT) and its operation during session transfer between 1xEV-DO and

3G-1X systems (“Description” (p. 2-67)). This description includes a discussion of the

Location Update feature as provided in TIA-856A for future implementation. Although

the Location Update feature is not implemented and cannot be enabled at this time, its

description is presented here to support the discussion of the hybrid AT. The Location

Update feature permits a hybrid AT with a mobile IP (M-IP) address to perform a more

efficient inter-PDS� handoff (“Description” (p. 2-72)).

The MCR may be used in place of the universal CDMA radio (UCR) and is capable of

handling up to eleven PCS or eight cellular carriers within 15MHz of contiguous

spectrum. The Ethernet backhaul support allows for the replacing existing T1 connections

for 1xEV-DO between a router and Modcell 4.0 with Ethernet cables. These two features

have minor influence on the scope of this manual and are covered in graphics and text in

Chapters 2, and 4 to state their function and availability in R24.0.

Issue 4 was to include RA� network increase security. Increased RA� network security

(see “RA� �etwork Security” (p. 2-9)) is achieved in three phases, starting with Release

R21.0 through Phase 3 in Release R23.0. In Phase 1 secure shell (SSH) tunnels are set up

between the OMP-FX and each DO-AP for file transfer protocol (FTP) and telnet-like

About this document

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

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

401-614-323Issue 16 October 2009

xxvii

Page 28: 1xev-Do Rf Engineering

traffic. Security for other types of traffic between the OMP-FX and the DO-APs is set in

Phase 2. Phase 3 allow other network connections to be protected within and across R�C

frames.

Issue 3 was published to include the Flexible Scheduler (FID 8948.0) feature introduced

in release R22.0. This feature (refer to “Introduction” (p. 3-58)) provides flexibility in

selecting different forward link scheduler algorithms to meet server providers'

requirements according to the needs of particular markets.

Issue 2 was published to describe the Test Application Feature introduced as part of

Release 20.1. The Test Application feature, which is described in “Introduction”

(p. 3-106), provides end to end performance testing of the system and is an OA&M

function. Therefore, a set of procedures to conduct forward and reverse link performance

measurements using this feature in a field environment is presented in Alcatel-Lucent

9271 EV-DO Radio �etwork Controller OA&M, 401-614-102. The Test Application

feature provides various testing capabilities for the forward links and reverse links. This

provides a collection of data statistics which were not available prior to the introduction

of this feature, such as the number of physical slots used in receiving the forward link

packet.

Three tests that can be run:

• Forward Test (TAF)

• Reverse Test (TAR)

• Combined Forward and Reverse Test (TAA).

The description of the Test Application Feature“Introduction” (p. 3-106) is supported in

Call Processing Chapter 7, which is new for the issue.

Intended audience

The primary target audience consists of engineers responsible for system design and

performance of an Alcatel-Lucent 1xEV-DO system.

Related documentation

Related Alcatel-Lucent and standards documents are listed below:

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

• Alcatel-Lucent 9271 EV-DO Radio �etwork Controller OA&M, 401-614-102

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

• Alcatel-Lucent CDMA Base Stations Operations, Administration and Maintenace,

401-703-407

• CDMA2000 High Rate Packet Data Air Interface Specification, TIA/EIA/TIA-856A

• Alcatel-Lucent 1xEV-DO Translation �otes

• Alcatel-Lucent Alerts

About this document

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

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

xxviii 401-614-323Issue 16 October 2009

Page 29: 1xev-Do Rf Engineering

You can obtain 1xEV-DO online technical information from the following:

• TIA Online, (http://www.tiaonline.com)

• Alcatel-Lucent Customer Wireless Support, (https://wireless.support.lucent.com)

Related training

Alcatel-Lucent training on 1xEV-DO and other related topics that are available are:

• 1xEV-DO RF Design Engineering and Base Station Call Processing, CL8306

• Flexent Wireless �etworks System Capacity, Monitoring, and Engineering (SCME)

for CDMA2000 1xEV-DO, CL1008

• TCP/IP Fundamentals, CL1910

• CDMA IS-95 and 3G-1X RF Design and Growth engineering for Cellular Systems,

CL8301

• CL8302, CDMA IS-95 and 3G-1X RF Design and Growth engineering for PCS

Systems, CL8302

• CDMA IS-95 and 3G-1X Base Station Call Processing, CL8303

• 3G-1X RF Design Engineering and Base Station Call Processing, CL8304

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

The Online Customer Support (OLCS) web site, http://support.alcatel-lucent.com,

provides access to technical support, related documentation, related training, and

feedback tools. The site also provides account registration for new users.

How to comment

To comment on this document, go to the Online Comment Form (http://infodoc.

alcatel-lucent.com/comments/) or e-mail your comments to the Comments Hotline

([email protected]) .

About this document

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

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

401-614-323Issue 16 October 2009

xxix

Page 30: 1xev-Do Rf Engineering
Page 31: 1xev-Do Rf Engineering

1 1Introduction

Overview

Purpose

This chapter introduces 1xEV-DO technology and is divided into three sections to

describe the wireless evolution to third generation (3G) technology, the evolution from

IS-95 to 3G-1X, finally, the concept that supports 1xEV-DO design.

Introduction

The evolution to 3G technology is guided by a set of recommendations proposed by

wireless service providers and manufacturers in response to a circular letter solicited by

the International Telecommunication Union (ITU), a U�-charted organization. Large

investments in various 2G technologies and equipment, held by service providers and

equipment vendors responding to the ITU C-circular letter that wanted to leverage their

knowledge and investment into the new 3G technology, delayed the ITU original vision

of single third-generation wireless technology. Consequently, three 3G terrestrial

solutions, two CDMA, and one TDMAwere adapted by the ITU for its third-generation

wireless technology. 1xEV-DO is an evolutionary outgrowth of CDMA2000™, which is

one of the two 3G CDMA solutions adapted by the ITU.

First section

The initial release of 1xEV-DO was guided by Interim Standard TIA-856Awhich is an air

interface optimized for data only, Subsequently this standard was revised to increase

forward and reverse link data rates, allow voice transmission, push-to-talk

communication, and a host of other telephony and Internet features. This revised standard

(TIA-856-A) is commonly referred to as 1xEV-DO Rev A, and in the context of this

technology, simply as Rev A. To differentiate between Rev A and the initial release of

1xEV-DO, the initial release is referred to as Rev 0. This document will cover both Rev 0

and Rev A.

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

401-614-323Issue 16 October 2009

1-1

Page 32: 1xev-Do Rf Engineering

Second section

The second section, Evolution from IS-95 to 3G-1X, reviews the evolution from wireless

second-generation IS-95 technology to wireless third-generation 3G-1X technology (3G)

to provide a common reference to introduce 1xEV-DO. This is done by identifying certain

of the improvements offered in 3G-1X.

Third section

The third section, Introduction to 1xEV-DO, describes how higher transmission data rates

and greater capacity can be achieved from a 1xEV-DO system, which permits data

transmission only. Unlike 3G-1X systems, which permit voice and data transmission,

1xEV-DO provides more efficient use of the spectrum for data transmission by

eliminating voice. Because voice must be transmitted uninterruptedly, in real time, the

high quality characteristics required for voice transmission results in data rate and

coverage limitations. The elimination of uninterrupted, real-time voice transmission

constraints allows 1xEV-DO systems to time-multiplex the distribution of downlink data

to each on-line subscriber in a particular service area. Unlike IS-95 and 3G-1X systems,

where base station transmit power must be shared among all active mobiles within a

sector to maintain simultaneous, continuous downlink voice channels, time-multiplexing

allows 1xEV-DO systems to concentrate their full downlink transmit power to a single

on-line user at any one time. In Rev 0 this allows the base station to transmit user data at

the highest data rate, up to 2.4-Mbps peak data rate, provided a discernible Eb/�o level is

maintained. In Rev A voice transmission is allowed by means of Voice over IP (VoIP)

technology and the forward data rate is increased to 3.1 Mbps.

The third section of this chapter also describes the 1xEV-DO air interface, its IP protocol

(Internet Protocol) for seamless data transfer over the Internet or any privet IP network,

and its downlink and uplink asymmetrical data flow rates.

Fourth section

The fourth section describes the changes and new features introduced in Rev A.

1xEV-DO Rev A upgraded networks profoundly enhance user service by enabling a wide

variety of applications. The primary consequence is VoIP and Multi-Flow operation

where the user can run multiple connections (sessions) at the same time where each

connection has its own Quality of Service (QoS). Certain other services are interactive 3D

gaming among large groups of players, FTP, instant messaging with full multimedia

content, Push-to-Talk (PTT) communication, video telephony.

Contents

Wireless Evolution to Third Generation (3G) Technology 1-4

ITU 3G Vision 1-5

Introduction Overview

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

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

1-2 401-614-323Issue 16 October 2009

Page 33: 1xev-Do Rf Engineering

Radio environments 1-6

Standards 1-8

Technologies 1-10

1xEV-DO 1-12

Evolution from IS-95 to 3G-1X 1-15

CDMA2000 1-16

Turbo Coder 1-17

Power control 1-19

Introduction to 1xEV-DO 1-20

Description of 1xEV-DO 1-21

Elimination of Voice Transmissions 1-22

1xEV-DO compatibility with voice 1-24

Forward Link Data Traffic Channel 1-26

Scheduling Algorithm 1-28

Reverse Link Data Traffic Channel 1-30

Changes and �ew Features Introduced in Rev A. 1-31

Rev A Physical Layer subtypes 1-32

Enhanced MAC Layer protocol 1-33

Rev A features and schedule 1-35

Basic Rev A Feature Bundle 1-37

Enhanced Rev A Feature Bundle 1-39

RA�Application Related Features 1-41

Latency issues resolved in Rev A 1-44

Rev A enhancements (MAC and Physical Layers) 1-45

Upper layer changes 1-47

Introduction Overview

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

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

401-614-323Issue 16 October 2009

1-3

Page 34: 1xev-Do Rf Engineering

Wireless Evolution to Third Generation (3G)Technology

Overview

Purpose

This section discusses wireless evolution to third generation (3G) technology.

Contents

ITU 3G Vision 1-5

Radio environments 1-6

Standards 1-8

Technologies 1-10

1xEV-DO 1-12

Introduction Wireless Evolution to Third Generation (3G) TechnologyOverview

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

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

1-4 401-614-323Issue 16 October 2009

Page 35: 1xev-Do Rf Engineering

ITU 3G Vision

Overview

The International Telecommunication Union (ITU) original vision was for one unifying

terrestrial air and core network system for the next generation of wireless communication.

Certain of the major aspects of the ITU vision, which help define 3G technology, include:

• Global Roaming with Fixed Wireless Services - Would allow a mobile user from

anywhere in the world to expect the same standard set of wireless services and

features, regardless of where the user travels and the country visited.

• High Circuit Mode and High Packet Data Rates -

Data rate optimization for three terrestrial radio environments:

– Vehicular, high-speed mobile environment

– Pedestrian low-mobility

– Indoor environment

• Internet Accessibility - Provides Internet connectivity and services comparable with

direct landline connection.

Patterned services in accordance with the Internet model, such as:

– Asymmetric link - Providing a low uplink data rate (narrow bandwidth) for

request and a high downlink data rate for web page download

– E-mail push -User does not have to connect to system to receive e-mail

– Multi-tasking - User may be on a video conference and receive mail at the same

time

• Quality of Service (QoS) - Allowing the user to negotiate the QoS with regard to data

rate, bit error rate, and latency

• Variable Data Rate - Allowing user to get a higher data rate when the system is less

busy

• Bandwidth-on-Demand - Allowing users willing to pay extra to negotiate for a wider

bandwidth when needed

• Support of Multimedia Services- Provides video and audio services for video

conferences and streaming video.

Introduction Wireless Evolution to Third Generation (3G) TechnologyITU 3G Vision

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

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

401-614-323Issue 16 October 2009

1-5

Page 36: 1xev-Do Rf Engineering

Radio environments

Radio Operating Environments

The ITU envisioned four distinct radio operating environments as shown in Figure 1-1,

“ITU'S IMT-2000 Vision Minimum Data Rates” (p. 1-6), one satellite and three

terrestrial, where the minimum data rates and coverage differ for each radio operating

environment:

• 9.6 kb/s for global satellite megacell coverage

• 144 kb/s for high-mobility vehicular macrocell coverage

• 384 kb/s for low-mobility pedestrian microcell coverage

• 2 Mb/s for indoor picocell coverage.

Data Rate vs. Coverage

There exists an inverse relationship between data rate and coverage; the higher the data

rate, the smaller the coverage area. Aamaller coverage area ensures an acceptable level of

quality; the receive Bit Error Rate (BER) must be kept to a minimum. In CDMA

transmission, low BER is accomplished by maintaining a high energy per bit level at the

receiver. This level is directly proportional to the transmit power and inversely

Figure 1-1 ITU'S IMT-2000 Vision Minimum Data Rates

Global

RegionalLocal Area

IndoorOffice/Home

MEGA CELL

MACRO CELL

MICRO CELL

PICO CELL

> 9.6 kb/s

> 144 kb/s

> 384 kb/s

> 2.048 Mb/s

8

9

7

4

5

6

3

2

1

#

0*

Introduction Wireless Evolution to Third Generation (3G) TechnologyRadio environments

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

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

1-6 401-614-323Issue 16 October 2009

Page 37: 1xev-Do Rf Engineering

proportional to the transmit distance and the transmit data rate. Hence, to insure an

acceptable receive high energy per bit level for a given transmit power level, as the data

rate increases, the distance between the transmitter and receiver must decrease.

Consequently, because the mobile transmit power is limited, the coverage areas of the

three terrestrial radio environments is a function of their respective data rates. The first

two rates, 144 kb/s and 384 kb/s, were adapted from the ISD� network, which the ITU

had originally envisioned for the 3G core network. The 2 Mb/s rate was considered the

data rate required to produce the look and feel of today's LA� line Internet connections.

Introduction Wireless Evolution to Third Generation (3G) TechnologyRadio environments

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

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

401-614-323Issue 16 October 2009

1-7

Page 38: 1xev-Do Rf Engineering

Standards

IMT-2000 Standards

Because of large investments in various 2G technologies and equipment, service

providers and equipment vendors responding to the ITU circular letter wanted to leverage

their knowledge and investment into the new 3G technology. In short, the service

providers from around the world proposed 3G solutions that provided a graceful evolution

from their current 2G terrestrial radio interface and core network technologies.

As a result, a variety of proposals were submitted to the ITU. The next step for the ITU

was to build a consensus among all participants to harmonize the different 3G proposals

into three major terrestrial radio interface proposals and two core-network technologies,

which became the International Mobile Telecommunication (IMT) family of 3G

technologies standards that are documented into the IMT-2000 Standards.

The three major terrestrial proposals and their primary deployment global region, which

are illustrated in Figure 1-2, “Interpretability of Standard IMT-2000 Services” (p. 1-9),

are:

• W-CDMA, proposed by GSM service providers and primary deployed in Europe

• CDMA2000, proposed by IS-95 CDMA service providers and primary deployed in

�orth America

• UWC-136, proposed by IS-136 TDMA service providers and primary deployed in

�orth America.

The core network defines the Mobile Application Part (MAP) that insures the operability

between service providers. The two core-network technologies are:

• GSM MAP, proposed by GSM service providers

• A�SI TIA/EIA - 41 MAP, proposed by IS-136 TDMA and CDMA IS-95 service

providers.

Introduction Wireless Evolution to Third Generation (3G) TechnologyStandards

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

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

1-8 401-614-323Issue 16 October 2009

Page 39: 1xev-Do Rf Engineering

Mix and Match

To permit service providers the freedom to chose any of the three terrestrial technologies

regardless of its present 2G radio interface, either core network can be used with any of

the three terrestrial technologies in a mix-and-match fashion. For example, a TDMA 2G

service provider closing to deploy W-CDMA is not compelled to use GSM MAP, and can

use the A�SI TIA/EIA-41 MAP core network solution.

Figure 1-2 Interpretability of Standard IMT-2000 Services

ANSI

TIA/EIA-41 - Based

Core Network

GSM-Based

Core Network

3G

UWC-136

ANSI-Based

Handset

3G

cdma2000

ANSI-Based

Handset

3G

W-CDMA

GSM-Based

Handset

Introduction Wireless Evolution to Third Generation (3G) TechnologyStandards

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

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

401-614-323Issue 16 October 2009

1-9

Page 40: 1xev-Do Rf Engineering

Technologies

Worldwide Support for the Three Terrestrial Technologies

There exists worldwide support for each terrestrial proposal, making core network

inter-operability and standard compatibility essential for achieving the ITU vision of

global communication.

The wideband CDMA or W-CDMA proposal comes primarily from Europe, where GSM

technology is widely deployed. Two official IMT standards are derived from this

proposal: IMT-DS (Direct Spread), which is a Frequency Division Duplex (FDD) scheme

where separate carriers are used for uplink and downlink and IMT-TC (Time Code); and a

Time Division Duplex (TDD) scheme, where uplink and downlink data is transmitted on

a single carrier separated by time. Although GSM uses a time division multiple access

radio interface, which is not compatible with CDMA, W-CDMAwill be

backward-compatible with GSM on the core network side, thus protecting the existing

GSM infrastructure. In addition to Europe, great support exists for W-CDMA from GSM

carriers on a worldwide basis. Asian service providers such as �ippon Telephone and

Telegraph (�TT) express strong support for W-CDMA. The �orth America GSM

Alliance and Microcell of Canada are conducting W-CDMA field-trials on behalf of the

�orth American carriers.

Support for CDMA2000, which is officially known in the IMT Standards as IMT-MC

(Multi-Carrier), comes from those service providers currently using cdmaOne (IS-95)

technology. This support is primarily in the United States. CDMA2000 is also supported

Korea and Japan. Lastly, the UWC-136, officially known as IMT-SC (Single Carrier), was

originally supported by TDMA service providers and manufacturers in the United States.

This support has dwindled considerably, and can play a minor role in the IMT-2000

family.

Introduction Wireless Evolution to Third Generation (3G) TechnologyTechnologies

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

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

1-10 401-614-323Issue 16 October 2009

Page 41: 1xev-Do Rf Engineering

CDMA2000, Multi-Carrier Mode

Both of the two different CDMA technologies emerging from wireless third- generation

CDMA2000 and wideband CDMA (W-CDMA) recognize that higher data rates can be

achieved through wider carrier bandwidths. While W-CDMA uses the direct spread

solution on carrier bandwidths ranging from 5-MHz and upwards, CDMA2000 provides a

multi-carrier solution using multiples of the IS-95 1.25 MHz carrier bandwidth to achieve

wider bandwidths. The multi-carrier solution leverages from IS-95 hardware and

technology. In this scheme, the carrier bandwidth is designated by the IS-95 carrier

multiplier: 1x designates 1.25 MHz, and 3x designates 3.75 MHz up to 12x, which

designates a 15-MHz carrier.

Figure 1-3 Global Wireless Standards Evolution

CDMAIS-95-A

2G 2.5G 3G CDMA IMT - 2000 Compliant

Voice &14.4 kbps

Circuit SwitchedData

CDMAIS-95-B

Voice &64 kbps PacketRF BackwardCompatible

CDMA20003G-1X

CDMA20003G-3X

CDMA20001xEV-DO

CDMA20001xEV-DV

High Capacity Voice &153 kbps Packet Data

RF BackwardCompatible

High Capacity Voice &Packet DataMulti-carrier

High Capacity Voiceand Packet Data

RF BackwardCompatible

High Capacity Voiceand 384 kbps+

Packet DataNew RF Interface

High Capacity Voiceand 384 kbps+

Packet DataNew RF Interface

2.4 Mbps Packet DataRF BackwardCompatible

PDC

W-CDMA(Europe)

W-CDMA(Japan)

PDC

1995 1999 2000 2001 2002 2003+

GSM

GSM

Voice &9.6 kbps

Circuit SwitchedData

Voice &9.6 kbps

Circuit SwitchedData

Voice28.8 kbpsVoice

9.6 kbps

Voice &114 kbps

Packet Data

384 kbps Packet Data

RF BackwardCompatible

RF BackwardCompatible

TDMAIS-136

EDGE (USA)EDGE (Europe)

Introduction Wireless Evolution to Third Generation (3G) TechnologyTechnologies

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

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

401-614-323Issue 16 October 2009

1-11

Page 42: 1xev-Do Rf Engineering

1xEV-DO

Description

1xEV-DO is a CDMA air interface and is an evolution of CDMA2000 to provide high-

speed packet data service to wireless users. The 1xEV-DO Rev 0 air interface is capable

of providing peak rates in excess of 2 Mbps to 1xEV-DO users. Rev A increases this data

rate to 3.1 Mbps. Even though the channel structure and channel encoding of 1xEV-DO is

different from the IS-95 interface, the 1xEV-DO RF signal is compatible with the IS-95

RF signal. So, the same radios, amplifiers, and filters used for IS-95 service can also be

used for 1xEV-DO service. The 1xEV-DO RF signal fits into the standard IS-95 spectrum

and the parameters of 1xEV-DO are adjusted to make the RF footprint of an 1xEV-DO

base station equal to the footprint of an IS-95 base station.

Fundamental Differences between 3G-1X and 1xEV-DO

The differences between 3C-1X and 1xEV-DO, both Rev 0 and Rev A, are shown in the

following table.

Table 1-1 Fundamental Differences between 3G-1X and 1xEV-DO

3G-1X 1xEV-DO Rev 0 1xEV-DO Rev A

Low to medium data rate

(144kbps)

High data rate (2.4Mbps) High data rate (3.1Mbps)

High capacity voice �o voice capability VoIP voice capability

May require OEM equipment A number of off-the-shelf IP

products

A number of off-the-shelf

IP products

Treats data just like voice,

designed for symmetrical

forward and reverse capacity

Treats data like data, designed

for asymmetrical forward and

reverse capacity

Treats data like data,

designed for asymmetrical

forward and reverse

capacity

Moving toward 1xEV-DO

In IS-2000 two high data rate evolutionary paths are provided: 1xEV-DO and 1xEV-DO.

1xEV-DO is fully backward compatible with 3G-1X and supports circuit-switched

operation for voice and packet switched operation for data on the same carrier. In its first

release defined by IS-2000 Rev C, 1xEV-DO provides a 3-Mbps forward link data rate

and a 307.2-kbps reverse link rate. The 1xEV-DO reverse link data rate was increased to

1.8 Mbps by IS-2000 Rev D.

Introduction Wireless Evolution to Third Generation (3G) Technology1xEV-DO

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

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

1-12 401-614-323Issue 16 October 2009

Page 43: 1xev-Do Rf Engineering

Compared to 3G-1X, 1xEV-DO uses a different approach to achieve high data rates in a

packet-switched data optimized system. In 1xEV-DO Rev 0, a single forward link

1.25-MHz carrier is time-shared with a maximum of 59 users. Voice transmission is not

implemented in 1xEV-DO Rev 0.

The 1xEV-DO technology, as defined by TIA-856A (Rev 0), uses the same 1.25-MHz

bandwidth as CDMA2000/IS-2000 and therefore is RF backward compatible. This

compatibility enables collocation with 3G-1X sharing the same RF filters, amplifiers, etc.

1xEV-DO is exclusively a packet-switched technology and in its introductory release

(Rev 0) provided data only connectivity.

Moving toward 1xEV-DO Rev A

Because Rev 0 is optimized for data only, minimal effort in its design is made to reduce

delay (latency). Rev A introduces a new set of packet sizes and data rates with its peak

forward-link rate going from 2.4 Mbps to 3.1 Mbps and a peak reverse-link rate 153.5

kbps to 1.8 Mbps (see Figure 1-4, “�ew Data Rates” (p. 1-14)). In addition to VoIP

services, Rev A upgraded networks profoundly enhances user service by enabling a wide

variety of applications. These services provide interactive 3D gaming among large groups

of players, FTP, instant messaging with full multimedia content, and video telephony.

New data rates

As shown in Figure 1-4, “�ew Data Rates” (p. 1-14), a number of new data rates are

added in both the forward and reverse links. As seen in later sections, Rev A introduces

different packet sizes and different transmission modes to achieve new peak rates.

Introduction Wireless Evolution to Third Generation (3G) Technology1xEV-DO

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

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

401-614-323Issue 16 October 2009

1-13

Page 44: 1xev-Do Rf Engineering

The reverse link undergoes improvements as well, the major one of which is that Rev A

shortens the frame size from 26.67 msec (full frame) to 6.67 msec (sub-frames) and

divides packet into sub-packets to provide early termination of the incremental

redundancy. This incremental redundancy is identified a hybrid ARQ.

Figure 1-4 New Data Rates

38.4 kbps

76.8 kbps

153.6 kbps

307.2 kbps

614.4 kbps

921.6 kbps

1,228.6 kbps

1,843.2 kbps

2,457.6 kbps

38.4 kbps

76.8 kbps

153.6 kbps

307.2 kbps

614.4 kbps

921.6 kbps

1,228.6 kbps

1,843.2 kbps

2,457.6 kbps

19.2 kbps

38.4 kbps

76.8 kbps

115.2 kbps

153.6 kbps

19.2 kbps

38.4 kbps

76.8 kbps

115.2 kbps

153.6 kbps

DO Rev 0

DO Rev 0

The

min

imum

dela

yof

apacket

deliv

ery

on

the

Forw

ard

Lin

kre

main

sat1.6

7m

s(1

TS

)

4.8 kbps

9.6 kbps

19.2 kbps

38.4 kbps

76.8 kbps

153.6 kbps

307.2 kbps

614.4 kbps

921.6 kbps

1,228.6 kbps

1,536 kbps

1,843.2 kbps

2,457.6 kbps

3,072 kbps

The

min

imum

dela

yof

apacket

deliv

ery

on

the

Forw

ard

Lin

kre

main

sat1.6

7m

s(1

TS

)

FL

19.2 kbps

38.4 kbps

76.8 kbps

115.2 kbps

153.6 kbps

230.4 kbps

307.2 kbps

460.8 kbps

614.4 kbps

921.6 kbps

1,228.6 kbps

1,843.2 kbps

RL

Rev A

Rev 0

19.2 kbps

38.4 kbps

76.8 kbps

115.2 kbps

153.6 kbps

230.4 kbps

307.2 kbps

460.8 kbps

614.4 kbps

921.6 kbps

1,228.6 kbps

1,843.2 kbps

4.8 kbps

9.6 kbps

19.2 kbps

38.4 kbps

76.8 kbps

153.6 kbps

307.2 kbps

614.4 kbps

921.6 kbps

1,228.6 kbps

1,536 kbps

1,843.2 kbps

2,457.6 kbps

3,072 kbps

Introduction Wireless Evolution to Third Generation (3G) Technology1xEV-DO

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

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

1-14 401-614-323Issue 16 October 2009

Page 45: 1xev-Do Rf Engineering

Evolution from IS-95 to 3G-1X

Overview

Purpose

CDMA2000 is introduced at 1x (1.25 MHz), designated 3G-1X, and allows voice and

data on the same carrier (bandwidth). The advent of CDMA2000 brought about a number

of air interface improvements over IS-95 to increase capacity, data rate, and transmission

quality while maintaining the same IS-95 1.25-MHz carrier bandwidth.

The improvements in 3G-1X over IS-95 include the following.

Contents

CDMA2000 1-16

Turbo Coder 1-17

Power control 1-19

Introduction Evolution from IS-95 to 3G-1XOverview

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

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

401-614-323Issue 16 October 2009

1-15

Page 46: 1xev-Do Rf Engineering

CDMA2000

Uplink Pilot Channel

Faster data rates are achieved through the use of uplink pilot channels. IS-95 employed a

blind detection technique in which the cell came up with its own timing to determine the

phase reference of the mobile signal. In 3G-1X, the mobile sends a pilot signal to indicate

the phase reference to the base station. This is referred to as coherent demodulation or

coherent detection, because the base station uses the timing on the uplink pilot channel to

demodulate the uplink traffic signal. As a result, the uplink traffic channel can be

transmitted at a lower power level, introducing less interference in the environment to

allow for increased capacity and data rate.

The uplink pilot channel provides significant power savings of up to 3 dB. This means

that the pilot channel enables a 3G mobile to transmit at twice the data rate, at same the

power level. To state it another way, a 3G mobile can transmit at the same data rate at half

the power level.

Introduction Evolution from IS-95 to 3G-1XCDMA2000

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

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

1-16 401-614-323Issue 16 October 2009

Page 47: 1xev-Do Rf Engineering

Turbo Coder

Convolution coder: K=9

IS-95 technology uses a K = 9 convolution coder to perform Forward Error Correction

(FEC). FEC is a technique used to lower the minimum received signal-to-interference

level, referred to as Eb/�o level, required to ensure quality reception. This is done in a

convolution coder by adding redundancy into the transmitted data bit stream. The

interrelationship of every bit with its preceding bits in the bit stream provides redundancy

at the receiver decoder, resulting in the ability to recover input data when a small number

of bits are corrupted. Bit recovery will be valid as long as the error in transmission is

restricted to a small number of bits at a time.

The K = 9 convolution coder is operated in IS-95 as half-rate or third-rate coder. For

every information bit input, when operating as a half-rate coder, a 2-bit coded output

symbol is generated, producing 100 percent redundancy. Similarly, when operating as a

third-rate coder, for every information bit input, a 3-bit output symbol is generated,

producing 200-percent redundancy.

3G turbo coder: K=10

The 3G technology introduces a turbo coder that can be used as a half-, third-, fourth-,

and fifth-rate coder. On average, a turbo coder effectively reduces the minimum required

Eb/�o by 1 dB to 2dB. Without a turbo coder, the exponential complexity for a K = 10

coder, which would be required for a fourth-and fifth-rate coder, does not offset its Eb/�o

benefits. This design complexity is minimized with a turbo coder. In 1xEV-DO, the turbo

coder is operated at a third- and fifth-rate in the forward link, and at a half- and

fourth-rate in the reverse link.

Turbo coder: K=4

A turbo coder consists of two K = 4 half-rate convolution coders and a turbo interleaver,

as shown in Figure 1-5, “Turbo Coder” (p. 1-18). Every information bit is routed through

the turbo coder unchanged to become one of the coder output symbol bits. The

information bit is also coded by the K = 4 half-rate coder, producing two symbol bits on

lines A and B. The K = 4 half-rate coder is not as complex as the K = 9 coder, and its

output is a function of the previous three bits. In addition, the input information bits are

scrambled by the turbo interleaver and are coded by the interleaver K = 4 half-rate coder,

producing two additional symbol bits on lines C and D.

The coder rate selection is implemented through the puncture control. When a half-rate

coding is selected, the puncture control inhibits the bit streams on lines B, C, and D. Thus,

the turbo coder generates only two coded symbol bits: the original instruction bits and the

bits on line A. When third-rate coding is required, the 2-bit symbol output of the K = 4

Introduction Evolution from IS-95 to 3G-1XTurbo Coder

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

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

401-614-323Issue 16 October 2009

1-17

Page 48: 1xev-Do Rf Engineering

half-rate coder is enabled along with the original information. When fourth-rate coding is

required, in addition to the 2-bit symbol at the output of the K = 4 half-rate coder and the

original information bit, the bit stream on line C is enabled.

Figure 1-5 Turbo Coder

K = 4 Half-RateCoder

InterleaveK = 4 Half-Rate

CoderTurbo Interleaver

InformationBit

OriginalInformation Bit

Encoded Bits

A

B

C

D

PunctureControl

Introduction Evolution from IS-95 to 3G-1XTurbo Coder

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

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

1-18 401-614-323Issue 16 October 2009

Page 49: 1xev-Do Rf Engineering

Power control

Forward Power Control

Another difference between IS-95 and 3G-1X technology is the implementation of

forward power control. Forward power control allows for an increase or decrease of the

signal power as a function of the signal level received at the base station.

Because of the high data rate capabilities in 3G-1X, tighter power control is required. In

IS-95, the mobile sends a power control request to the base station over the traffic channel

every 20 ms, or 50 times a second. In 3G-1X, the mobile sends a power control request

every 1.25 ms, or 800 times a second, over the reverse pilot channel. More frequent

power control requests provide more accurately adjusted power.

Supplemental Channel

Supplemental channels were introduced in 3G-1X for high data rate transmission, such as

for Internet or multimedia applications. The channel carries data only, and messages must

be transmitted with either the fundamental channel and/or the dedicated control channel,

which are also introduced in 3G-1X. A fundamental channel is operated as a traffic

channel in IS-95 and, in addition to providing control data for the supplemental channel,

the fundamental channel is primarily used to carry voice traffic. Rather than using a

fundamental channel, a dedicated control channel can be set up to support (provide

signaling for) the supplemental channel. A dedicated control channel can also be used for

short messages.

Introduction Evolution from IS-95 to 3G-1XPower control

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

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

401-614-323Issue 16 October 2009

1-19

Page 50: 1xev-Do Rf Engineering

Introduction to 1xEV-DO

Overview

Purpose

This section provides a high-level introduction to 1xEV-DO.

Contents

Description of 1xEV-DO 1-21

Elimination of Voice Transmissions 1-22

1xEV-DO compatibility with voice 1-24

Forward Link Data Traffic Channel 1-26

Scheduling Algorithm 1-28

Reverse Link Data Traffic Channel 1-30

Introduction Introduction to 1xEV-DOOverview

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

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

1-20 401-614-323Issue 16 October 2009

Page 51: 1xev-Do Rf Engineering

Description of 1xEV-DO

High data rates

Higher transmission data rates and greater capacity can be achieved from a 1xEV-DO

system, which permits data transmission only, than from a 3G-1X system, which permits

voice and data transmission. Even though Rev A permit voice transmission through VoIP,

VoIP is considered data, in that it does not require continuous real-time dedication of a

traffic channel.

1xEV-DO solution

In both direct spread and multi-carrier solutions employed by W-CDMA and

CDMA2000, respectively, a wide band is required to achieve high data rates while a

number of users are simultaneously sharing the same carrier for voice and high data rate

traffic. Rather than allowing multiple users to simultaneously share a single carrier for

both uplink and downlink transmission, CDMA2000 1xEV-DO uses a different approach

to achieve high data rates. 1xEV-DO recognizes the asymmetrical nature in which data is

moved over an IP network. Higher volumes of data are downloaded from the network to

the user than are uploaded from the user to the network. The download to upload ratio can

vary between four-to-one and six-to-one, and is, occasionally, even higher. To take

advantage of this asymmetrical pattern, 1xEV-DO technology uses different multiple

access division techniques for uplink and downlink data transmission. For uplink data

transmission, 1xEV-DO uses the classical CDMA code division technology similar to

IS-95 and 3G-1X, and for downlink transmission, a time division technique where, a

single 1.25-MHz carrier is time-shared with a maximum of 59 (113 in Rev A) users, is

used. Because voice transmission, other than VoIP, requires continuous use of the carrier,

voice transmission is not implemented in 1xEV-DO. This document focuses on

CDMA2000 1xEV-DO which, as in 3G-1X technology, also leverages from IS-95

hardware and technology. While the Physical Layer of 1xEV-DO, identifying channel

encoding and channel structure differs greatly from IS-95 and 3G-1X, the RF signal and

1.25-MHz bandwidth is compatible with IS-95. Therefore, the same RF equipment

(amplifiers, filters, etc.) used to provide IS-95 service can be used to provide 1xEV-DO

service.

Introduction Introduction to 1xEV-DODescription of 1xEV-DO

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

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

401-614-323Issue 16 October 2009

1-21

Page 52: 1xev-Do Rf Engineering

Elimination of Voice Transmissions

Introduction

To appreciate how the elimination of voice transmissions can improve data rates, which is

often defined as capacity or the amount of data transmitted in a unit of time, this topic

reviews the trade-off with quality, coverage, and capacity that is inherent in CDMA

systems.

Trade-off with Quality, Coverage, and Capacity

The quality of the transmission is directly proportional to the transmit power, and is

commonly expressed as the amount of energy transmitted in each bit (Eb) over the

ambient noise and interference (Eb/�o) level. Increasing the data rate increases the

capacity, which is the number of bits transmitted in a unit of time, and therefore requires

more energy or transmit power. After the transmitter reaches its maximum power output,

any further increase in the data rate will result in reducing the transmit-Eb/�o level

quality, thereby reducing the overall quality of the received signal. As a result, the quality

of the received signal at the outer coverage fringe will fall below levels acceptable to

maintain calls. Consequently, the transmitter range decreases, and the coverage area

shrinks. If the data rate is still increased, the Eb/�o levels in larger coverage continues to

drop, further reducing the quality of the received signal and increase cell shrinkage.

Limitation of Real-Time, Uninterrupted Voice Transmissions

Voice quality is the ultimate criterion to consider in IS-95 and 3G-1X systems. Because

voice must be transmitted uninterruptedly, in real time, the high quality characteristics

required for voice transmission results in data rate and coverage limitations. Whereas the

relaxed time constraints allow corrupted received packet data to be retransmitted, the

uninterrupted, real-time constraint of voice transmission prohibits retransmission.

Because retransmission is prohibited, voice transmission is less tolerant to high Bit Error

Rates (BERs), demanding high quality transmission by forcing transmission at higher

Eb/�o levels than allowed for data transmission. The higher transmission Eb/�o levels

create more interference in the environment, consequently imposing major limitations on

CDMA transmission data rates.

Increased Data Rates

The elimination of uninterrupted, real-time voice transmission constraints allow

1xEV-DO systems to time-multiplex the distribution of downlink data to each on-line

subscriber in a particular service area.

Unlike IS-95 and 3G-1X systems, where the base station must be able to maintain

simultaneous, continuous downlink voice channels within a sector, time multiplexing

allows 1xEV-DO systems to concentrate its full downlink transmit power to a single

Introduction Introduction to 1xEV-DOElimination of Voice Transmissions

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

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

1-22 401-614-323Issue 16 October 2009

Page 53: 1xev-Do Rf Engineering

on-line user at any one time.

Introduction Introduction to 1xEV-DOElimination of Voice Transmissions

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

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

401-614-323Issue 16 October 2009

1-23

Page 54: 1xev-Do Rf Engineering

1xEV-DO compatibility with voice

Overlay Solution

A 1xEV-DO system can coexist with 3G-1x technology and is optimized for packet data

services using flexible architecture based on standard Internet Protocols (IP). By using

voice and data, prior to Rev A, on separate dedicated carriers, the 1xEV-DO overlay

solution allows service providers to optimize wireless systems to provide the higher

traffic capacities without negatively influencing voice service and performance.

While 3G-1X provides high-capacity voice and low to medium rate data services,

1xEV-DO provides additional capacity for data users where data becomes a significant

portion of the traffic on a network. A 3G-1X network can provide operators with

substantial advantages for high capacity, high quality voice services, and packet data

services of 144 Kbps user rate for mobile subscribers. The 1xEV-DO systems will

complement a 3G-1X network offering in areas where high speed, high throughput data

traffic is expected. Users with multi-mode terminals can access data over the Internet

while maintaining a voice conversation over the 3G-1X network.

The 1xEV-DO Rev 0 architecture provides an overlay solution to voice networks running

in cellular or Personal Communications Services (PCS) spectrums and requires a

dedicated 1.25-MHz channel. Although designed to leverage from IS-95 and 3G-1X

systems, protecting current investments in existing Alcatel-Lucent Flexent® and

AUTOPLEX® infrastructures, the 1xEV-DO does not require any signaling or backhaul

interaction with the MSC and can co-exist with any voice technology such as GSM and

TDMA.

1xEV-DO Characteristics

1xEV-DO is a high data rate air interface providing high speed, high capacity packet data

service for wireless users. This service employs the IP protocol (Internet Protocol) for

seamless data transfer over the Internet or any private IP network. Rather than using

mobiles, users access the system with a hand-held Access Terminal (AT). Because

experience with the Internet indicates asymmetrical data flow, where downlink data flow

is much higher than uplink data flow, downlink and uplink data flow between AT and the

Base Transceiver Station (BTS) is asymmetrical.

Rev 0 forward link average aggregate throughput can be from 350 to 550 kbps per

carrier-sector for high mobility (vehicle) end users, and up to 650 kbps per carrier-sector

for low-mobility and stationary end users. 1xEV-DO supports a host of new higher-rate

services such as faster speeds for corporate access, as well as streaming multimedia

content.

Although a 1xEV-DO base stations can be collocated with an IS-95 or a 3G-1X system,

1xEV-DO requires separate CDMA carriers that cannot be used by either IS-95 or 3G-1X.

This is because 1xEV-DO air interface channel protocol that defines the forward and

Introduction Introduction to 1xEV-DO1xEV-DO compatibility with voice

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

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

1-24 401-614-323Issue 16 October 2009

Page 55: 1xev-Do Rf Engineering

reverse link data traffic channels is not compatible with the IS-95 and 3G-1X forward and

reverse link data traffic channels.

Introduction Introduction to 1xEV-DO1xEV-DO compatibility with voice

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

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

401-614-323Issue 16 October 2009

1-25

Page 56: 1xev-Do Rf Engineering

Forward Link Data Traffic Channel

Purpose

The following is an overall description of the forward and reverse data link traffic

channels as defined by the 1xEV-DO air interface. A detailed discussion of the traffic

channels and the air link interface is given in Chapter 3.

Forward Link Data Traffic Channel

A single forward link data traffic channel is used on each CDMA carrier designated for

1xEV-DO operation, and is time-shared by a maximum of 59 (113 in Rev A) users on the

carrier. This means that at any one time, only one user is actively receiving data over the

traffic channel. With only one user, the need for transmit power sharing as in IS-95 and

3G-1X is removed, and the BTS software is not concerned with co-channel interference.

Therefore, the BTS can transmit at full power to produce the highest carrier to noise

(Eb/�o) ratio possible, allowing high data rate transmission.

Dynamic Rate Control

Data rate is assigned based on the signal strength measured at the AT. The data rate that is

transmitted to any one AT is a function of that AT RF environment. The AT continuously

monitors the quality of its receive pilot signal, in addition to monitoring the pilot signal

from other neighboring sectors. As with IS-95 and 3G-1X, the pilot signal transmitted by

each sector is distinguished by an offset of the P� short code. Because the received pilot

signals from the different sectors are predictable, the AT can acquire the pilot signal and

measure the pilot channel carrier-to-interference (C/I) ratio. By measuring the C/I ratio,

the AT is able to determine its current best serving sector and the highest data rate it can

receive reliable data from that sector. As a result of this determination, the AT sends back

a Data Rate Control (DRC) report to the BTS. The DRC identifies the serving sector and

the highest rate in which the AT can receive quality data from the sector. The Rev 0 and

Rev A base station response to the DRC value different ways. The serving sector

transmits to a scheduled AT at the rate indicated in its DRC report and then follows the

scheduling algorithm described below

Packet Data Transmission

Forward link data is transmitted in successive 26.67-ms frames, which are divided into

sixteen 1.667-ms slots in which packets of data are transmitted.

• The transmission duration of a single packet can vary from 1 to 16 slots as a function

of the data transmission rate.

• Pilot and control information are inserted (punctured) within each frame at fixed

intervals for AT extraction.

Introduction Introduction to 1xEV-DOForward Link Data Traffic Channel

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

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

1-26 401-614-323Issue 16 October 2009

Page 57: 1xev-Do Rf Engineering

• The packet AT destination is specified within the packet.

• Upon receiving the packet, the AT transmits an acknowledge signal (ACK) indicating

that the packet is received and its data is uncorrupted.

Introduction Introduction to 1xEV-DOForward Link Data Traffic Channel

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

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

401-614-323Issue 16 October 2009

1-27

Page 58: 1xev-Do Rf Engineering

Scheduling Algorithm

Introduction

To maximize the overall sector throughput, 1xEV-DO uses a scheduling algorithm that

takes advantage of a multi-user pool vying for time on the carrier. Based on the DRC

reported by each AT, the scheduling algorithm will typically schedule data transfer for

only the ATs operating in favorable RF conditions, so that the data is transferred at the

highest possible rate. ATs operating in less favorable RF conditions are served later,

hopefully when their RF conditions improve.

Different scheduler and scheduling algorithm are uses in Rev 0 and Rev A. The

scheduling algorithm is used to determine the transmission format in which the forward

link date is sent to the AT user. At this level discussion it only important to remember the

transmission format identifies the packet size and data rate that the packet is transmitted

to the AT user.

Rev 0 Scheduling Algorithm

As shown in “Rev 0 Scheduling Algorithm” (p. 1-28) forward link data can be transmitted

at nine different data rates that are chosen to provide efficient coverage under a full range

of conditions experienced at typical cellular/PCS cell sites. The data starts at 38.4 kbps

and doubles itself up to 2.457.6 kbps. Each data rate is associated with a particular packet

bit size and modulation type.

Data Rate (kbps) 38.4 76.8 153.6 307.2 614.4 921.6 1228.8 1843.2 2457.6

Bit per Packets 1024 1024 1024 1024 1024 3072 2048 3072 4096

Modulation Type QPSK QPSK QPSK QPSK QPSK QPSK QPSK 8

PSK

16

QAM

Packet Data Transmission

Forward link data is transmitted in successive 26.67-ms frames, which are divided into

sixteen 1.667-ms slots in which packets of data are transmitted.

• The transmission duration of a single packet can vary from 1 to 16 slots as a function

of the data transmission rate.

• Pilot and control information are inserted (punctured) within each frame at fixed

intervals for AT extraction.

• The packet AT destination is specified within the packet.

• Upon receiving the packet, the AT transmits an acknowledge signal (ACK) indicating

that the packet is received and its data is uncorrupted.

Introduction Introduction to 1xEV-DOScheduling Algorithm

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

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

1-28 401-614-323Issue 16 October 2009

Page 59: 1xev-Do Rf Engineering

Rev A Scheduling Algorithm

Five new forward link data rates are added in Rev A. Three are 128-bit, QPSK modulated

packets at 4.8, 9.6 and 19.2 Kbps. The other two are 5120-bit, 16 QAM modulated

packets at 1536.0 and 3072.0 Kbps.

In addition to maximizing the air interface as the Rev 0 scheduler, the Rev Amust also be

concerned with the user QoS profile and traffic data QoS Class. Where the Rev 0

scheduler only used the Best Effort (BE) to maintain high reliability with low, the Rev A

scheduler must also concern itself with two other QoS classes: Expedited Forwarding

(EF) and Assured Forwarding (AF).

Expedited Forwarding (EF) is delay-intolerant with lower reliability requirements than

BE. This QoS class provides stringent end-to-end delay requirements. Examples of such

flows are VoIP and online gaming. Assured Forwarding (AF) is typically the same as BE

with a minimum average throughput requirement.

Unlike Rev 0, where a one-to-one relationship exists between DRC value and

forward-link transmission format that determines the packet size, and span, which is the

maximum number slots in which the packet is transmitted, the Rev A scheduler is

permitted greater flexibility in determining the packet size, and span, in response to a

DRC value. The transmission format selected in any instance is determined by factors

such as: delay requirement, payload size, traffic class, etc. This flexibility allows the

scheduler to maximize air capacity in accordance with the different QoS criteria of the

various flows vying for forward link transmission.

Introduction Introduction to 1xEV-DOScheduling Algorithm

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

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

401-614-323Issue 16 October 2009

1-29

Page 60: 1xev-Do Rf Engineering

Reverse Link Data Traffic Channel

Reverse Link Data Traffic Channel

As in 3G-1X, 1xEV-DO uses reverse link (uplink) pilot pulses permitting coherent

detection by the BTS of the reverse link data from the AT. In Rev 0 the reverse link data is

transmitted in successive 26.67-ms frames at data rates from 9.6 kbps to 153.6 kbps. The

initial transmit rate of an AT is 9.6 kbps. Subsequently, the transmit rate can be increased

or decreased depending on the total traffic activity in the sector. A Reverse Rate Indicator

(RRI) transmitted by the AT is used by the BTS to identify the rate in which the AT is

transmitting traffic data.

Higher data rates

To provide higher data rates on the reverse link, the 16-slot Rev A reverse channel frame

is divided into four 4-slot sub-frames, and a physical layer packet is divided into 1, 2, 3,

or 4 sub-packets to provide incremental redundancy. In Rev A, an Automatic Repeat

Request (ARQ) is transmitted by the base station to support incremental redundancy.

Reverse channel incremental redundancy allows early termination of the reverse packet

transmission. In the reverse link enough data is transmitted in each sub-packet so that if

RF conditions improve during transmission, the receiver is able to reconstruct the

complete packet information in one or two sub-packs less than the full complement

required. After each sub-packet is transmitted an ARQ signal is sent back to the AT

indicating if additional sub-packet transmissions are required. When the RF conditions

improve, early termination can occur after the first or second sub-packet of a

four-sub-packet complement is transmitted. Therefore, the transmission of the packet is

terminated earlier, effectively increasing the packet data rate.

Introduction Introduction to 1xEV-DOReverse Link Data Traffic Channel

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

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

1-30 401-614-323Issue 16 October 2009

Page 61: 1xev-Do Rf Engineering

Changes and New Features Introduced in Rev A.

Overview

Purpose

In compliance with ITU-856-A standard, Alcatel-Lucent has bundled separate features in

its Rev A product that is scheduled for release in R26 and R27. The necessary hardware,

such as the single board EVM, will be released in R26. Full deployment occurs in R27.

Although Rev A air interface enhancements are primarily influenced at the MAC and

Physical Layers, this upgrade affects all protocol layers and, therefore its operation

touches on all aspects of 1xEV-DO technology to varying degrees.

Contents

Rev A Physical Layer subtypes 1-32

Enhanced MAC Layer protocol 1-33

Rev A features and schedule 1-35

Basic Rev A Feature Bundle 1-37

Enhanced Rev A Feature Bundle 1-39

RA�Application Related Features 1-41

Latency issues resolved in Rev A 1-44

Rev A enhancements (MAC and Physical Layers) 1-45

Upper layer changes 1-47

Introduction Changes and New Features Introduced in Rev A.Overview

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

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

401-614-323Issue 16 October 2009

1-31

Page 62: 1xev-Do Rf Engineering

Rev A Physical Layer subtypes

Introduction

�ote:Rev A is built on the technology developed in Rev 0. To provide a meaningful

discussion on the on changes and new features introduced in Rev A, this discussion

make the assumption that the reader has basic familiarity with Rev 0 technology.

Unlike Rev 0, end-to-end delay performance to reduce latency is critical for optimizing

the air-interface and capacity in Rev A. Implementation of applications that will be

offered in Rev A, such as the Alcatel-Lucent end-to-end solution for VoIP, is

fundamentally designed to operate on an IMS core network. Although Alcatel-Lucent's or

any other IMS core network is not an absolute requirement, the core network must

comply with IMS standard specifications such as 835-D for Rev A for QoS

implementation.

Physical Layer subtypes

The evolution to Rev A is mainly in the Air-Interface and is principally implemented at

the Physical and MAC Layers.

Two new Physical Layer Subtypes have been introduced in TIA-856-A, in addition to the

default Physical Layer protocol set that is used in Rev 0 and is subsequently defined as

Subtype 0. Subtype 1 - defined as Enhanced Rev 0 which, with the exception of adding

19.2 and 38.4 kbps access channel data rates with shorter preamble (4-slots), is the same

as Subtype 0. Subtype 2 supports a wider range of Physical Layer packet sizes to improve

packing efficiency. A 128-bit smaller packet size is introduced in both the forward and

reverse links. Also introduced is a 5120-bit packet in the forward link and a 12288-bit

packet in the reverse link.

A wider range of data rates is also provided:

• 4.8 kbps to 3.072 Mbps in the forward link, and

• 19.2 kbps to 1.843 Mbps in the reverse link.

Introduction Changes and New Features Introduced in Rev A.Rev A Physical Layer subtypes

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

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

1-32 401-614-323Issue 16 October 2009

Page 63: 1xev-Do Rf Engineering

Enhanced MAC Layer protocol

Enhanced MAC Layer protocol

The MAC layer protocols provide enhanced operation to the Control, Access, Forward

Traffic and Reverse Traffic channels. In Rev A these channels are prefixed with the word

Enhanced, that is, Enhanced Forward Traffic channel. The corresponding Rev 0 channels

takes on the prefix word Default, that is, Default Forward Traffic channel. In addition

three new Enhanced Reverse Traffic channel (RTC) MAC Layer Subtypes have been

introduced in TIA-856-A.The enhanced channel and three enhanced RTC subtypes are

closely mapped to the Physical Layer subtypes as shown Figure 1-6, “MAC Layer

Subtype” (p. 1-33).

Enhanced control channel

The Enhanced Control Channel operates only with Physical Layer Subtype 2 to provide

rapid connection setup. The Enhanced Control Channel also minimizes forward link

resource usage for transmitting pages. The Enhanced Access Channel operates with

Physical Layer Subtype 2 or Subtype 1 to provide rapid connection setup

Enhanced Forward Traffic Channel: operates only with Physical Layer Subtype 2 to

provide Multi-Users Packet (MUP) support. MUP allows up to seven users to share a

single transmitted packet, improving packing efficiency and, thereby, improving the

performance of delay-sensitive applications.

Figure 1-6 MAC Layer Subtype

DefaultControlChannel

DefaultAccessChannel

DefaultForwardTraffic

Channel

DefaultReverseTraffic

Channel

X X X X

X X X X

X X X

Introduction Changes and New Features Introduced in Rev A.Enhanced MAC Layer protocol

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

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

401-614-323Issue 16 October 2009

1-33

Page 64: 1xev-Do Rf Engineering

MAC RTC

Except for Rate Transition Vectors Setable by the Generic Attribute Update Protocol

(GAUP), MAC RTC Subtype1 is the same as Rev 0 default MAC RTC. The GAUP

protocol dynamically updates values of certain attributes belonging to different lower and

higher layer protocols in the AT and RA�.

RTC Subtype 2 operates with Physical Layer Subtype 0 or Subtype 1 to map multiple

reverse link MAC flows to application flows.

RTC Subtype 3 operates with Physical Layer Subtype 2 to map multiple reverse link

MAC flows with Rev A Physical Layer and to support Low Latency and High Capacity

Transmission mode, providing efficient transport of data from latency-sensitive and

delay-tolerant applications

Introduction Changes and New Features Introduced in Rev A.Enhanced MAC Layer protocol

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

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

1-34 401-614-323Issue 16 October 2009

Page 65: 1xev-Do Rf Engineering

Rev A features and schedule

Rev A coverage approach

Alcatel-Lucent features developed to support new 1xEV-DO Rev A enhancement that are

in compliance with the following standard documentations:

• TIA-856-A-1: cdma2000® High Rate Packet Data Air-Interface Specification

• TIA-835-D: cdma2000®Wireless IP �etwork Standard: Quality of Service

• TIA-878-A: Inter-Operability Specification for CDMA 2000 Access �etwork

Interfaces

• TIA-1054: cdma2000® High Rate Packet Data Supplemental Services

Rev A Feature Release Schedule

Rev A features are bundles and schedule for release in R27 through R29. The features that

are available in these releases are group into three categories which are roughly align with

release number. These feature groups are:

• Basic Rev A Feature Bundle - Planned available in R27 and is a mandatory set of

features required to support Rev A, activated via software licensing key.

• Enhanced Rev A Feature Bundle - Planned availability in R28, optionally activated,

FAF optionally enabled as a bundle per Service node.

• RA� Application Related Features - The features in this category are divided into two

sub-categories; Push-to-Talk (PTT), planned availability in R28, and Voice over IP

(VoIP), planned availability in R29. Each feature is separately activated per Service

�ode.

Prior to Rev A Release in R27

Modem upgrades FIDs 12078.17 and 12078.27 (see Figure 1-7, “Modem Upgrades Prior

R27” (p. 1-36)) are required prior to deployment of any other Rev A features in R27.0.

Modem upgrade is made available in the R26.0/R26.01 time frame. The service provider

is required to either upgrade the classic Rev 0 EVM modem board with the Rev A capable

Single Board EVM modem (SB-EVM or SB-EVMm) or to add a new carrier using the

SB-EVM/SB-EVMm. The SB-EVM/SB-EVMm modem board will support all Rev 0

operation.

Introduction Changes and New Features Introduced in Rev A.Rev A features and schedule

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

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

401-614-323Issue 16 October 2009

1-35

Page 66: 1xev-Do Rf Engineering

The SB-EVM/SB-EVMm will:

• use QualcommASIC Tile based on CSM6800 chip

• provides higher capacity in terms of number of channels supported: supports 192 CEs

in RL for 96 users and 288 flows in the forward link. Full capacity of 192 users and

576 flows. In Rev A a flow is termed as an open reservation in which a stream of data

between the AT and a specific web location.

• supports 3 sector-carriers with two-way receive diversity

Figure 1-7 Modem Upgrades Prior R27

12078.17 Support of Rev 0 calls on Rev A capable hardware

(SB-EVM) for ModCell 4.0

12078.27 Support of Rev 0 calls on Rev A capable hardware

(SB-EVMm) for ModCell 1-3

Introduction Changes and New Features Introduced in Rev A.Rev A features and schedule

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

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

1-36 401-614-323Issue 16 October 2009

Page 67: 1xev-Do Rf Engineering

Basic Rev A Feature Bundle

Basic Rev A Feature Bundle

All of the features in the Basic Rev A Feature Bundle (see Figure 1-8, “Basic Rev A

Feature Bundle” (p. 1-37)) must be activated, via a software licensing, to support Rev A

functionality and this activation is required before any feature in the two other categories

are activated. The features in this bundle increase reverse link peak data rate to 1.8 Mbps.

This increase is support at the MAC layer and is attributed for the most put to incremental

redundancy on the reverse link know as Hybrid - Automatic Repeat Request (H-ARQ).

The features in this bundle increase the forward link peak data rate to 3.1Mbps

Enhanced Reverse & Forward Links

Enhanced Reverse & Forward Links using Enhanced MAC Protocols with Rev A Subtype

2 Physical Layer, FID 12078.2, supports the full Rev A Physical Layer (defined as

Subtype 2 Physical Layer in TIA-856-A) with the complete set of Rev A enhanced MAC

protocols that is, 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

HRPD Rev A Support on ModCell 1-3 BTS/9218 Macro Platforms

HRPD Rev A Support on ModCell 1-3 BTS/9218 Macro Platforms, FID 12078.4/.5,

supports Rev A technology on their respective ModCell 1-3 BTS/9218 Macro Platform.

Figure 1-8 Basic Rev A Feature Bundle

12078.2 Enhanced Reverse and Forward Links using Enhanced

MAC Protocols with Rev A Subtype2 Physical Layer

12078.4 HRPD Rev A Support on ModCell 1-3 BTS Platforms

12078.5 HRPD Rev A Support on ModCell 4.0 BTS Platforms

12078.7 Inter and Intra -RNC Handoff Enhancement

Introduction Changes and New Features Introduced in Rev A.Basic Rev A Feature Bundle

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

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

401-614-323Issue 16 October 2009

1-37

Page 68: 1xev-Do Rf Engineering

Inter and Intra-RNC Handoff Enhancement

Inter and Intra-R�C Handoff Enhancement, FID 12078.7, supports every type of handoff

situation in both Rev 0 systems and in mixed Rev 0/Rev A systems, which includes

soft/softer traffic channel handoff; hard handoff across carriers on traffic channel, and

inter-R�C dormant session handoff. This feature also includes handoffs from Rev-A

PHY/MAC connections to Rev 0 PHY/MAC connections. However, the feature does not

include handoff from Rev 0 to Rev A systems.

Introduction Changes and New Features Introduced in Rev A.Basic Rev A Feature Bundle

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

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

1-38 401-614-323Issue 16 October 2009

Page 69: 1xev-Do Rf Engineering

Enhanced Rev A Feature Bundle

Enhanced Rev A Feature Bundle

The features in this bundle (see Figure 1-9, “Enhanced Rev A Feature Bundle” (p. 1-39))

provide enhanced service flexibility such as per application Quality of Service (QoS), fast

paging/battery life trade-off, Data over Signaling (DOS). Activation of these features is

required for the activation of the RA�Application Related features.

RAN Quality of Service (QoS) support for HRPD

RA� Quality of Service (QoS) support for HRPD, FID 12078.9/RA� Quality of Service

(QoS) enhancements for 1xEV-DO, FID 12078.10, are optional features. The former

supports QoS (Quality of Service) based applications. In Rev A users can have separate

application flows with separate QoS requirements for delay, jitter or bandwidth. This

feature uses the Multi Flow Packet Application that is defined in the TIA-856-A-1

addendum. The main focus of this feature is to provide a basic QoS infrastructure.

Specifically, this feature provides the QoS capabilities framework that other FIDs (VoIP)

build on to provide:

• Multi-flow Packet Application (MFPA)

• QoS authorization

• Forward link scheduler support

• Subtype 3 RTCMAC configuration to support QoS requested

Figure 1-9 Enhanced Rev A Feature Bundle

12078.12 Data Over Signaling Protocol Support

12102.13 Enhanced Idle State Protocol

12078.9 RAN Quality of Service (QoS) support for HRPD

RAN Quality of Service (QoS) enhancementsfor 1xEV-DO Rev A

12078.10

Introduction Changes and New Features Introduced in Rev A.Enhanced Rev A Feature Bundle

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

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

401-614-323Issue 16 October 2009

1-39

Page 70: 1xev-Do Rf Engineering

Admission Control

• Low latency treatments for R�C and BTS

• A10/A11 enhancements to support multiple Radio Link Protocol (RLP) flows and

QoS

The specific application supported by this feature is Video Telephony.

Data Over Signaling Protocol Support

Data Over Signaling Protocol Support, FID 12078.12, permits small parcels of data

(small data bursts) to be sent over the Control and Access signaling channels when no

traffic channel connection exists. Data over Signaling (DOS) benefits applications that

require quick message timing, such as push to talk and Short Message Service (SMS).

Enhanced Idle State Protocol

Enhanced Idle State Protocol, FID 12078.13, provides support to the Enhanced Idle State

protocol defined in the TIA-856-A-1 standard. This protocol provides additional benefits

over the default Idle State defined in Rev 0. The benefits include the following:

• shorter slot cycles for reducing paging delay

• longer slot cycles for improving battery life

• dynamic slot cycles defined for different ATs

• mobiles hash to particular types of carriers

This feature is applicable for all the BTS types that HRPD currently supports, with classic

EVMs/EVMms or SB-EVMs/SB-EVMms.

Introduction Changes and New Features Introduced in Rev A.Enhanced Rev A Feature Bundle

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

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

1-40 401-614-323Issue 16 October 2009

Page 71: 1xev-Do Rf Engineering

RAN Application Related Features

RAN Application Related Features

The RA�Application Related Features, shown in Figure 1-10, “RA�Application

Related Features” (p. 1-41) are optional and are functional divided into to group. The first

contains PTT-related features, scheduled for R28 release. The second contains VoIP

related features, scheduled for R29 release.

Push-to-Talk Related Features:

1xEV-DO Backhaul with MLPPP at layer 2 over T1/E1, FID 12304.11 replaces the Cisco

HDLC with MLPPP as layer 2 protocol. The MLPPP/MC protocol has been developed

under 3G1X IPBH program. This feature must be enabled on any EV-DO base station

Figure 1-10 RAN Application Related Features

12102.2 VoIP over 1xEV-DO to 3G-1x CircuitVoice Handoff

12078.25 Pilot Interference Cancellation Support onthe SB-EVM

12102.1 Basic Functionality for VoIP Support on1xEV-DO Rev A RAN

12102.5

12102.14

Backhaul Enhancement in Support of SmallBackhaul Enhancement in Support of SmallPackets on RL in 1xEV-DO, Phase 1a

Backhaul Enhancement in Support of Small

Packets on FL in 1xEV-DO, Phase 1b

VoIP Related Features (release 29)

12304.11 1xEV-DO Backhaul with MLPPP at layer 2over T1/E1

12184.1

12184.4

12184.5

PTT Related Features (release 28)

1xEV-DO Basic PTT using 1xEV-DORev A Networks

1xEV-DO PTT End-to-End Service using QChat

1xEV-DO PTT Paging Enhancements

Introduction Changes and New Features Introduced in Rev A.RAN Application Related Features

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

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

401-614-323Issue 16 October 2009

1-41

Page 72: 1xev-Do Rf Engineering

where FID 12078.9 is used to provide backhaul traffic load-balance and QoS handling

under MLPPP extension protocol, which is IETF standard. Edge router in the DO

backhaul should also support the MLPPP protocol

1xEV-DO Basic PTT using 1xEV-DO Rev A �etworks, FID 12184.1 provides push-to-talk

functionality for 1xEV-DO and is based on the Multiflow Packet Application (MFPA).

�ew QoS service categories are introduced for PTT signaling & bearer are used. The

signaling flows and the media flow have separate A10s and RLP flows

1xEV-DO PTT End-to-End Service using QChat, FID 12184.4, provides RA�

enhancements for PTT specific for Qualcomm Qchat (quick chat) application. It also

provides the end-to-end PTT service integration testing using the HRPD-A RA� and the

QchatTM servers. The RA� enhancements include performance enhancements in

addition to the functionality already provided by this FIDS and FID 12184.5 features.

1xEV-DO PTT Paging Enhancements, FID 12184.5 provides paging enhancements that

are required for PTT. The paging enhancements improve paging efficiency by increasing

the probability of locating the users on the first page attempt. Paging enhancements

include the following:

• priority paging,

• R�C Group and �eighbor R�C paging (used by QoS paging)

• distance-based paging.

Voice over IP Related Features

Basic Functionality for VoIP Support on 1xEV-DO Rev A RA�, FID 12102.1, is the

primary feature to support voice call over the 1xEV-DO network. This feature introduces

the basic functionalities to support commercial grade VoIP over the RA� and supports

Enhanced Multi-Flow Packet Application (EMFPA) and ROHC parameter negotiation

using EMFPA as defined in TIA-1054. This feature also sports Video Telephony (VT)

with EMFPA.

VoIP over 1xEV-DO to 3G-1X Circuit Voice Handoff, FID 12102.2 supports A21 Interface

to support 1xEV-DO to 3G-1X Handoff.

Backhaul Enhancement in Support of Small Packets on RL and FL in 1xEV-DO, Phase 1,

FIDs 12102.5 and 12102.14, enhance the current backhaul used in EV DO Rev 0. The

current EV DO backhaul design is not appropriate for carrying small packets such as VoIP

applications where the voice frames are much smaller than IP packets. Therefore, for the

Rev A network to carry the small bearer traffic efficiently, a type of compression, or

multiplexing needs to be implemented in a similar way to 3G 1x IP Backhaul. In Phase I

of this feature RMI (remote massaging interface) Header Compression (RMI HC)

function on bearer traffic is provided.

Introduction Changes and New Features Introduced in Rev A.RAN Application Related Features

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

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

1-42 401-614-323Issue 16 October 2009

Page 73: 1xev-Do Rf Engineering

Pilot Interference Cancellation Support on the SB-EVM, FID 12078.25 supports Pilot

Interference Cancellation (PIC) on the SB-EVM. PIC is expected to increase reverse link

capacity especially for VoIP. VoIP increase in capacity could be as much as 15%.

Introduction Changes and New Features Introduced in Rev A.RAN Application Related Features

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

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

401-614-323Issue 16 October 2009

1-43

Page 74: 1xev-Do Rf Engineering

Latency issues resolved in Rev A

Latency issues resolved in Rev A

The default FTC MAC used in Rev 0 was designed for efficient support of delay-tolerant

traffic. For the evolution to Rev A, a number of latency issues were resolved. These issues

include the following:

• Large packet sizes (Physical Layer packet size equal or greater than 1024 bits) -

Compressed voice frames transits about 200 bits every 20 ms. The smallest packet in

Rev 0 is 1024 bits which make voice transmission inefficient. Rev A provides smaller

packet size for voice transmission.

• Entire traffic channel allocated to a single user at any given time – To reduce delay,

Multi-user packets (MUP) where small parcels data for up to eight users is transmitted

in one forward link packet.

• Service interruption during Forward Link handoffs – Developed new Data Source

Control (DSC) channel to provide advance handoff prediction – allow candidate cell

to prepare for handoff, resulting in faster handoff.

Introduction Changes and New Features Introduced in Rev A.Latency issues resolved in Rev A

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

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

1-44 401-614-323Issue 16 October 2009

Page 75: 1xev-Do Rf Engineering

Rev A enhancements (MAC and Physical Layers)

Rev A enhancements (MAC and Physical Layers)

The main Rev A enhancements are in the air-interface and are described in TIA-856-A

standard. The most important enhancements in TIA-856-A are in the Physical and MAC

Layers as well as the introduction of the multi-flow packet application which allows the

support of different applications with different Quality of Service (QoS). Following are

the MAC and Physical layer enhancements:

Increases the number users:

To accommodate the increase users resulting from increase data rates, a 128-ary Walsh

Function is used, increasing the number of users to 113.

Provides Packet Division Multiplexing (MUP):

Allowing a single Physical Layer packet to contain one or more Upper Layer packets

addressed to different users through Multi-Users Packet (MUP). This enhancement is

especially useful for voice over IP where compressed voice of about 200 bits are

transmitted every 20 ms. MUPs improves over the air capacity efficiency.

Provide Flexible packet length:

In Rev 0 transmission of all reverse link packets are fixed to 16 slots. In Rev A, the

transmission of the entire packet may use 1, 2, 3 or 4 sub-packets with each sub-packet

spanning over 4 slots, providing incremental redundancy for early termination.

Provide Data over Signaling:

Applications that require quick message timing such as push to talk (PTT) or small data

burst transport, such as short message service, may use Data over Signaling (DOS) if a

traffic channel is not assigned to an AT. Forward transmission of DOS bursts is

transferred over the control channel, and reverse transmission is transferred over the

access channel.

Provide a Data Source Control Channel:

A new DSC channel allows a more seamless cell selection to improve forward link

handoff. In Rev 0, AT service on the forward may be interrupted during cell selection

when the candidate cell undergoes the necessary preparation. The function of the DSC is

to indicate the desired forward serving cell before the DRC information is transmitted.

Introduction Changes and New Features Introduced in Rev A.Rev A enhancements (MAC and Physical Layers)

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

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

401-614-323Issue 16 October 2009

1-45

Page 76: 1xev-Do Rf Engineering

Enhanced Control Channel MAC:

Allows a single-user page of 4-slot transmission versus default control channel of

16-slots.

Introduction Changes and New Features Introduced in Rev A.Rev A enhancements (MAC and Physical Layers)

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

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

1-46 401-614-323Issue 16 October 2009

Page 77: 1xev-Do Rf Engineering

Upper layer changes

Introduction

In addition to the Physical and MAC Layers changes, a number of changes have been

introduced for the Upper Layers.

Multi-Flow Packet Application (MFPA)

MFPA allows applications with different QoS requirements to be assigned up to four

different RLP Flows (BE, best effort), Speech (VoIP), Video, and BMCS.

3G1X Circuit Services Notification Application

Permits an AT to receive 3G-1X circuit-switched services such as Page, SMS, crossing of

3G-1X paging zone boundary, etc., while the AT is still operating for packet data service

through 1xEV-DO. It also permits an AT to monitor 3G-1X only to save battery life while

still operating for packet data service.

Multi-mode Capability Discovery Application

Discovers the specific capabilities and limitation of multi-mode devices, such as the

ability to support hybrid MS/AT operation or inability to support simultaneously

monitoring common channels of 1xEV-DO and cdma2000.

Enhanced Idle State Protocol

Improves the control of idle state monitoring capabilities by supporting different slot

cycles:

• shorter slot cycles for reduced paging delay

• longer slot cycles for better battery life

The selection of shorter or longer cycles is a trade-off between connection setup time and

terminal battery life. Also this enhancement introduces a new Paging Mask attribute to

allow the AT to specify dead times when not monitoring the HRPD control channel to

monitor functions of other technologies such as 3G-1X.

Generic Attribute Update Protocol

Allows simple configuration attribute changes without costly session configuration

protocol exchange and without releasing the connection.

Introduction Changes and New Features Introduced in Rev A.Upper layer changes

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

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

401-614-323Issue 16 October 2009

1-47

Page 78: 1xev-Do Rf Engineering
Page 79: 1xev-Do Rf Engineering

2 2Radio Access Network

(RAN) Architecture

Overview

Purpose

The chapter discusses the major components in the Radio Access �etwork and how data

is propagated from source to destination. An overall description of each major network

component is presented in terms of its physical and functional makeup. The importance of

protocol stacks associated with each component is presented along with a description of

each protocol layer. This chapter also describes IP address assignments and the difference

between simple and mobile IP addresses.

A good understanding of the Radio Access �etwork and its major network components,

and how the data interface protocols are used to move data from source to destination, is

important for the efficient design of a system, maximizing the air interface to increase

capacity and performance.

Contents

�etwork Data Flow 2-3

Radio Access System (RAS) 2-4

IPAddress Assignment 2-7

RA� �etwork Security 2-9

Release R21.0, Phase 1 2-10

Release R22.0, Phase 2 2-11

Release R23.0, Phase 3 2-14

Data Interface Protocols 2-15

Reference models 2-16

Protocol stack and data transfer 2-18

Layers 2-20

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

401-614-323Issue 16 October 2009

2-1

Page 80: 1xev-Do Rf Engineering

Host-to-�etwork Interface 2-23

1xEV-DO Rev 0 default architecture layers 2-26

Rev A Enhanced Architecture Layers 2-29

Protocols 2-30

Simple IP and Mobile IP Internet Access 2-33

RA� Protocol Interface 2-34

Simple IP connection 2-37

Simple IP Connection with Private �etwork 2-38

Mobile IP Connection 2-41

Basic functionalities for VoIP 2-44

Support for Evolved High Rate Packet Data (eHRPD) 2-45

Support for multi-carrier RevB 2-47

Rev A�etwork Challenges 2-52

IMS Core 2-53

Header compression 2-56

End-to-End 2-59

Delay budget 2-62

Session Transfer Between 1xEV-DO and 3G-1X Systems 2-66

Hybrid Access Terminal (AT) 2-67

3G-1X Priority Over 1xEV-DO System 2-69

Access State 2-70

Maintenance of PPP Sessions 2-71

Location Update Protocol 2-72

Mobile IPAssignment 2-73

PPP Reconfiguration Trigger 2-74

Location Tracking Value 2-75

Location Update Protocol Procedure 2-76

Location Update Feature (FID 10696.1) 2-77

Handoffs 2-79

Location Update Service Measurement 2-82

Radio Access Network (RAN) Architecture Overview

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

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

2-2 401-614-323Issue 16 October 2009

Page 81: 1xev-Do Rf Engineering

Network Data Flow

Overview

Purpose

This section discusses the flow of data across the network.

Contents

Radio Access System (RAS) 2-4

IPAddress Assignment 2-7

Radio Access Network (RAN) Architecture Network Data FlowOverview

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

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

401-614-323Issue 16 October 2009

2-3

Page 82: 1xev-Do Rf Engineering

Radio Access System (RAS)

Description

Air interface and data traffic connection for 1xEV-DO is provided by a wireless IP

network that is independent and different from the IS-41 network model used for IS-95

and 3G-1X. In 1xEV-DO air interface and data connection to and from the public packet

switched network (Internet) and in private IP networks is provided by the 1xEV Radio

Access System that is shown in Figure 2-1, “Radio Access System (RAS)” (p. 2-4). This

figure shows network hardware, providing the air interface and data traffic connections

through the network.

Figure 2-1 Radio Access System (RAS)

UplinkInputRouter

DownlinkInput

Router

DownlinkInput

Router

UplinkInputRouter

Router

Flexent MobilityServer (FMS5)

Flexent MobilityServer (FMS0)

OMP FX(Element Management

System)

Radio AccessNetwork (RAN)

1x EV-DO BTS 1

1x EV-DO BTS 48

1x EV-DO BTS 288

1x EV-DO BTS 240

PacketData

ServiceNode

(PDSN)

Internet

AAA

T1/E1* Lines

T1/E1* Lines

Ethernet

Ethernet

*May be an Ethernet line from ModularCell 4 base station if Ethernet Backhaulfeature is enable in Release R24.0

Radio Access Network (RAN) Architecture Network Data FlowRadio Access System (RAS)

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

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

2-4 401-614-323Issue 16 October 2009

Page 83: 1xev-Do Rf Engineering

Access Terminal

Users will access the system, which is referred to as the Radio Access �etwork (RA�),

through an Access Terminal (AT) that maintains an air interface with a 1xEV-DO base

station. The AT may be used in a laptop computer, a hand-held device such a Palm Pilot

or personal digital assistant, or multi-mode mobile with AMPS/IS-95 and

3G-1X/1xEV-DO capabilities.

Base Transceiver Station (BTS)

The base station (sometimes referred to on maintenance and configuration data displays

such as RC/V screens as Base Transceiver Station, or BTS) receives and transmits a

CDMA signal from and to all of the ATs in its service area. As stated in Chapter 1,

downlink transmission from the base station to the AT is on a time-share basis or time

division, and uplink transmission is classical CDMA code division. All call processing

negotiated between the AT and the base station is covered in later chapters and is defined

by 1xEV-DO Protocol Architecture TIA-856A and TIA-856-A, which is introduced later

in this chapter. The objective of this present discussion is to describe data flow between

the AT and a land IP network such as the Internet. To that extent, the TIA-856-A

architecture provides a Radio Link Protocol (RLP) that encapsulates small chunks of

transmitted and received data bits into datagrams.

Flexent® Mobility Server (FMS)

The 1xEV-DO base stations within the RA� coverage area, which may be stand-alone

devices or co-located with 2G or 3G-1X base stations, are connected by a Flexent®

Mobility Server (FMS) through a network router via a T1 or E1 line. The FMS provides

the interface to complete the call control functions required by the AT to acquire the RA�

network. This interface is defined by the 1xEV-DO TIA-856-A Protocol Architecture. In

release R24.0 an Ethernet Backhaul feature is introduced to support Ethernet connection

between a router and a 9218 Macro base station.

Two network routers (switches) are physically housed with an FMS in the same frame.

The routers shown in Figure 2-1, “Radio Access System (RAS)” (p. 2-4) are functionally

located and do not necessarily represent individual routers. The routers are bidirectional

devices, and for this discussion will be identified in terms of its uplink data path from the

ATs to the RA� network. Therefore, the routers receiving input commands and data

stream from the base stations are functionally identified as uplink input routers. If the

Ethernet Backhaul feature introduced in R24.0 is not enabled, these routers, which

provide a common point to terminate backhaul T1/E1 lines from all 1xEV-DO base

stations, steer and convert the uplink data stream received over the T1/E1 line to the FMS

via an Ethernet line.

Radio Access Network (RAN) Architecture Network Data FlowRadio Access System (RAS)

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

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

401-614-323Issue 16 October 2009

2-5

Page 84: 1xev-Do Rf Engineering

FMS Frames

The RA� network may contain up to eight FMS frames, designated FMS0 through

FMS5. The FMS frame, commonly referred to as the Radio �etwork Controller (R�C),

houses up to four primary and four backup A Servers. Each A-Server contains one DO

Application Processor (DO-AP) running on the Sun Solaris Operating System (OS),

Version 8. The A Server also contains up to two Traffic Processors (TPs), one Alarm

Card, and one local boot disk. The DO-APs run the 1xEV Controller software to perform

overhead channel management signaling processing and OA&M control functions. These

functions include session establishment and release, frame selection, and radio link

protocol (RLP) processing. The TPs run VxWorks to perform traffic processing and the

Packet Control Function (PCF) to handle the packet data interface between the base

station and the PDS� components.

The 1xEV controller software also performs the packet control function (PCF) to process

the data for standard A10/A11, Radio-Packet (R-P) interface with the Packet Data Serving

�ode (PDS�). A10 refers to the traffic data interface between the PCF and PDS� and

A11 refers to the signaling interface between the two. This interface is maintained either

via a 100 Mbps Ethernet connection or an ATM interface to the Internet service provider

backbone IP network. The A10/A11 R-P interface terminates the mobility management

defined by the air interface protocol (TIA-856A) and is the demarcation point between

the RA� and IP packet networks. The FMS-processed data is connected to PDS� via the

downlink input router, and because the PDS� is located at Internet serving network, the

router is connected to the PDS� over an Ethernet connection.

Each FMS frame is capable of interfacing and handling the call processing function for 48

base stations. User maintenance and controls for the eight FMS within the RA� are

provided through OMC-RA�, which runs on the Flexent® OMP FX platform. The

Flexent® OMP FX, which is located on-site with the FMS frames, is connected to each

frame via a router over an Ethernet connection. When certain 1xEV-DO base stations are

collocated with 3G-1X/IS-95 cell sites, the same Flexent® OMP FX may also be used to

run the Flexent® OMC RA� for the 3G-1X/IS-95 cell sites.

RNC limits

FID-12589.0 increases the upper limit of 1xEV-DO logical frame numbering from 28 to

40. This increase allows 1xEV-DO applications to use the same logical frame numbering

range as CDMA 3G-1X. The larger numbering space allows growing FMM or 1xEV-DO

R�C frames in a shared OMP environment. The CDMA 3G-1X logical frame numbering

limit was increased to 40 under FID-12583.0 to support the CDMA 3G-1X 2M BHCA

capacity offer.

Radio Access Network (RAN) Architecture Network Data FlowRadio Access System (RAS)

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

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

2-6 401-614-323Issue 16 October 2009

Page 85: 1xev-Do Rf Engineering

IP Address Assignment

Description

The PDS� is operated as a Home Agent (HA) for the serving network in which it resides.

As its agent, the serving network allocates the PDS� to open an IP session with a

petitioning AT. The IP address defines a physical location on the Internet. When an IP

session is established with an AT, the most significant digits of the IP address, which are

listed in the Internet routing tables, are used to direct Internet data traffic associated with

the AT to and from the PDS�. The PDS� maps the AT to the IP address so that data

reaching the PDS� is directed to the AT.

IP address values are classified into two categories: dynamic and static. A dynamic IP

address is a temporary address generally issued by the host serving network to the

petitioning user machine for the duration of the session. When the session is terminated,

the IP address is surrendered back to the host serving network for use by another

machine. If the user petitions to open another session, its machine would most likely be

assigned a different dynamic IP address value.

A static IP address is a permanent address assigned by a serving network to a machine.

The serving network may or may not be the serving network that is currently hosting the

session. Each time a machine with a static IP address opens a session, it uses the same IP

address value.

Simple IP

Unless the AT requests otherwise, when a session is allocated, a dynamic IP address is

assigned to the AT. The IP address belongs to the host serving network, and is assigned by

that serving network Dynamic Host Configuration Protocol (DHCP). The IP address,

which is called a Simple IP (S-IP), is assigned to the AT for the duration of the session as

long as the AT remains within the domain of the PDS�. The PDS� is operated as a Home

Agent (HA) for the DHCP.

The IP address provides the AT with a source/destination location address, allowing

packet data to be moved to and from the AT during the session. Although an IP address,

which is a series of multi-decimal octal numbers, is ideal for machines such as network

routers to steer packet data between source and destination, the IP address is not friendly

for human recognition. That is why the serving network uses a Domain �ame Server

(D�S) for the human interface that maps the IP address to a recognizable name, such as

[email protected].

Mobile IP

Rather that accepting an S-IP address, an AT may request a mobile IP (M-IP) address.

Typically in this case, the AT would be programmed or hard-wired with its own static IP

address. When the AT petitions the PDS� to open an Internet session, rather than

Radio Access Network (RAN) Architecture Network Data FlowIP Address Assignment

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

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

401-614-323Issue 16 October 2009

2-7

Page 86: 1xev-Do Rf Engineering

accepting a dynamic IP address, the AT may identify its static IP address, which the

PDS� uses as an M-IP address to open the session. If the AT moves out of the service

area of its current PDS�, the AT can maintain the same static IP address, rather than

accepting a different IP address from the new PDS�. The benefit of having an M-IP

address is that the AT is allowed to roam in and out of different serving networks without

the need to use different IP addresses in different service areas. The M-IP address

provides an advantage if the AT user maintains a session through the firewall of a private

IP network. Without the M-IP, the AT would have to renegotiate its way through the

firewall each time the IP address changes.

If the AT is roaming outside its home RA�, most likely its static IP address will be

foreign to the serving network currently hosting the session. In this case, the PDS� in the

host serving network will be operating as a Foreign Agent (FA) for the serving network

having domain over the static IP address. Data transmitted between the AT and the

Internet will be directed via the FA PDS� and the Home Agent (HA) PDS� that has

domain over the static IP address used by the AT.

If the AT requires an M-IP and does not have its own static IP address, upon starting a

session, an AT can request an M-IP address. In this case, the AT is assigned a dynamic IP

address that it keeps (just as a static IP address) for the entire session even when the AT

enters the domain of another serving network. If the AT enters the domain of another

PDS�, the PDS� becomes a Foreign Agent for the serving network that issued the

dynamic IP address.

Authentication, Authorization and Accounting (AAA)

Prior to allowing an AT network access, the AT is challenged for authentication to

determine if the AT is not masquerading under a false ID, and also for authorization to

determine if the AT is permitted (authorized) to access the network. This challenge is

implemented by the Authentication, Authorization and Accounting (AAA) server via a

server/client relationship with the PDS� client. The AAAmaintains a subscriber database

which is used to validate the user's ID and password. The PDS� records AT data usage to

provide accounting information to the AAA Server.

Radio Access Network (RAN) Architecture Network Data FlowIP Address Assignment

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

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

2-8 401-614-323Issue 16 October 2009

Page 87: 1xev-Do Rf Engineering

RAN Network Security

Overview

Purpose

Increased RA� network security is achieved in three phases starting with Release R21.0.

In Phase 1 secure shell (SSH) tunnels are set up between the OMP-FX and each DO-AP

for file transfer protocol (FTP) and telnet-like traffic. Security for other types of traffic

between the OMP-FX and the DO-APs is set in Phase 2. Phase 3 allow other network

connections to be protected within and across R�C frames.

Contents

Release R21.0, Phase 1 2-10

Release R22.0, Phase 2 2-11

Release R23.0, Phase 3 2-14

Radio Access Network (RAN) Architecture RAN Network SecurityOverview

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

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

401-614-323Issue 16 October 2009

2-9

Page 88: 1xev-Do Rf Engineering

Release R21.0, Phase 1

Description

The security measures taken in Phase 1 prevent FTP and telnet-like traffic access to the

OMP-FX by any element in the network other than the designated DO-APs. In addition to

authentication by user login name and password, the SSH allows another level of

authentication to be established by encrypting the exchange of data between the DO-APs

and the OMP-FX using a public key scheme. In this scheme the DO-APs and the

OMP-FX will have unique private and public keys that are strings of alphanumeric

characters similar to a password. The private and public keys, which are used to code and

decode messages, are complementary in that a message coded with a public key can only

be decoded using its complementary private key.

Process

Telnet-like and FTP messages sent from the OMP-FX to a DO-AP are encrypted by the

OMP-FX using its private key. Thus, this message can only be decoded using the

OMP-FX public key which will only be distributed to associated DO-APs. The DO-AP

intended to receive the message uses the OMP-FX public key to decode all Telnet-like

and FTP messages from the OMP-FX. If the received message is decipherable, it will be

authenticated and acted upon. If the message is not from the OMP-FX, the message will

be undecipherable and will be rejected. In this way, a secure tunnel is set up from the

OMP-FX to the DO-AP. In very much the same way, a secure tunnel is set up from each

DO-AP to the OMP-FX.

Problems with public key encryption

When any public key scheme is used, care must be taken to ensure that the message

recipient obtains a certified copy of the sender's public key. Conceivably an unauthorized

rogue agent may publish its own un-certified public key while masquerading as an

authorized agent. If this un-certified public key is accepted, the message from the rouge

sender will be decipherable, and the receiver will act upon the message as if it came from

an authorized agent. As a result, a breach in the secure tunnel will occur. To ensure the

validity of the public keys circulated between the OMP-FX and the DO-APs, the public

keys will be distributed via the Local Maintenance Terminal (LMT). The LMT is a

terminal emulation program running on a laptop computer. The laptop will be manually

plugged into the OMP-FX and each DO-AP where a U�IX super-user must log in to the

password protected root directory to download the private and public keys for

distribution.

Radio Access Network (RAN) Architecture RAN Network SecurityRelease R21.0, Phase 1

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

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

2-10 401-614-323Issue 16 October 2009

Page 89: 1xev-Do Rf Engineering

Release R22.0, Phase 2

Description

In phase 2 (release R22.0.) The R1SR R�C frame is introduced to increase RA� network

security by subdividing the RA� network into three smaller networks. The smaller

networks are shown in Figure 2-2, “R1SR R�C �etwork ” (p. 2-12) and are:

• Internal �etwork - base station connections to Cajun Ethernet switch within each

R�C frame (connection is made via external routers which are not shown)

• Maintenance �etwork - OMP-FX connections to two lead DO-APs within each R�C

frame

• External �etwork - connection between the TPs in each R�C frame and the packet

data service node (PDS�)

Radio Access Network (RAN) Architecture RAN Network SecurityRelease R22.0, Phase 2

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

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

401-614-323Issue 16 October 2009

2-11

Page 90: 1xev-Do Rf Engineering

R1SR RNC Network diagram

�ote: In R32.0 the Universal Traffic Processor (UTP) was introduced. The UTP is

fully compatible with the OMC-RA� and continues to use the same procedures that

Pre-R32 UTP used.

Additional Ethernet Ports

Physical connectivity isolation is made possible by additional Ethernet ports provided on

the DO-AP and TP assemblies. Each DO-AP in the R1SR R�C frame has four 100Base-T

Ethernet ports. Two are connected to Cajun Ethernet switches (one to switch A and the

other to switch B) to handle data traffic between the DO-APs within the frame, and

between the DO-APs and the TPs. The other two are connected to the OMP-FX to

provide access to the data. However, only two DO-AP pairs are designated to

communicate with the OMP-FX. In addition to its other duties, one of the DO-APs in the

two pairs is assigned responsibility for the R�C lead and overhead control; the other

DO-AP in the pair will operate in a standby backup mode for this function. One of the

Figure 2-2 R1SR RNC Network

1x EV-DO BTS 1

1x EV-DOBTS 48

1x EV-DO BTS 288

1x EV-DO BTS 240

DO-APPair

DO-APPair

DO-APPairs3 & 4

Cajun Ethernet Switches

OMP-FX

TPs TPs

Packet Data Serving Node(PDSN, A11)/AAA (A12)

Internet

R1RS RNC Frame

R1RS RNC FrameR1RS RNC Frame

UplinkInput

Router

Router

DownlinkInput Router

Radio Access Network (RAN) Architecture RAN Network SecurityRelease R22.0, Phase 2

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

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

2-12 401-614-323Issue 16 October 2009

Page 91: 1xev-Do Rf Engineering

DO-APs in the other DO-AP pair will provide a database repository for configuration data

downloaded. If the R�C frame has only a single DO-AP pair, then both the lead and the

database repository are handled by a single DO-AP in the pair, with the other DO-AP to

assume backup in the event of a failure.

Additional Levels of Security

In addition to the introduction of the R1SR R�C frame, security features introduced in

Phase 2 set-up security tunnels to protect other type of data traffic within the R�C frame.

Besides the telnet-like and FTP data between the OMP-FX and the DO-APs, which are

protected by the SSHs, Phase 2 protects S�MP and JDBC traffic data that is transferred

between these network elements. S�MP is an acronym for Simple �etwork Management

Protocol, which is a protocol for querying network entity status and for receiving alarms

from those same entities. JDBC stands for Java Database Connectivity, which is used to

download the database. In Release R22.0, the S�MP data transfer protocol is upgraded

from version 2 to version 3, which provides a much more secure data transfer scheme.

JDBC data will pass through an IPSec tunnel, which uses a standards-based security

protocol to provide privacy, integrity, and authenticity of the information transferred

across IP networks, where IPSec provides IP network-layer encryption. In addition, this

release allows SSH tunnels to be set up between the DO-AP pairs that communicate with

the OMP-FX and their associated TPs.

Radio Access Network (RAN) Architecture RAN Network SecurityRelease R22.0, Phase 2

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

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

401-614-323Issue 16 October 2009

2-13

Page 92: 1xev-Do Rf Engineering

Release R23.0, Phase 3

Description

In Release R23.0, other network connections may be protected within and across R�C

frames. For example, this release allows SSHs to be set up between the DO-APs that are

connected to the OMP-FX and the DO-AP that are not.This release also allows the

availability of an IPSec layer providing traffic data protection between R�C frames. This

feature provides protection during dormant inter-PCF (packet control function) handoffs

across R�C frames. The PCF handles the packet data interface between the base station

and the PDS� and the Authentication, Authorization, and Accounting (AAA) server. An

inter-PCF handoff will occur when a call is handed off from a sector serviced by one PCF

to a sector serviced by a different PCF. The PCF may be on the same or a different R�C

frame. When the PCFs are on different R�C frames, A13 data transfer occur across the

R�C Frames. Another security measure offered in Release R23.0 will permit the R�C to

be optionally connected to network timing protocol (�TP) server that can be

authenticated.

Radio Access Network (RAN) Architecture RAN Network SecurityRelease R23.0, Phase 3

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

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

2-14 401-614-323Issue 16 October 2009

Page 93: 1xev-Do Rf Engineering

Data Interface Protocols

Overview

Purpose

This section covers the data interface protocols.

Contents

Reference models 2-16

Protocol stack and data transfer 2-18

Layers 2-20

Host-to-�etwork Interface 2-23

1xEV-DO Rev 0 default architecture layers 2-26

Rev A Enhanced Architecture Layers 2-29

Protocols 2-30

Radio Access Network (RAN) Architecture Data Interface ProtocolsOverview

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

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

401-614-323Issue 16 October 2009

2-15

Page 94: 1xev-Do Rf Engineering

Reference models

OSI Reference Model

User traffic data is moved across the RA� network in discrete packets, which are data

parcels containing a specified number of data bits in accordance with the TCP/IP

reference model, which is universally adapted for Internet use. This reference model is

similar to the Open System Interface (OSI) reference model.

The OSI reference model separates and groups the different functional network tasks to

be performed into layers. The processing of user traffic data at each layer is governed by

one or more protocols. Protocols are sets of rules and procedures that each network entity

must agree to follow to achieve seamless data traffic across different network entities.

TPC/IP Reference Model

The difference between the OSI and TCP/IP reference models is shown in Figure 2-3,

“OSI to TCP/IP Reference Model Map” (p. 2-16). Both the OSI and the TCP IP reference

models use independent protocol stacks.

The TCP/IP reference model is named after its two primary protocols:

• TCP: Transmission Control Protocol used in the transport layer

• IP: Internet Protocol, used in the internet layer.

Figure 2-3 OSI to TCP/IP Reference Model Map

Radio Access Network (RAN) Architecture Data Interface ProtocolsReference models

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

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

2-16 401-614-323Issue 16 October 2009

Page 95: 1xev-Do Rf Engineering

Because experience with the ISO reference model has shown limited use for the

functionality of the presentation and session layers, these layers were eliminated from the

TCP/IP model. In addition, the TPC/IP ignores defining the physical and data link layers,

designated as the Host-to-�etwork interface, and its definition is left up to the user, so

long as it services the Internet layer in accordance with its protocol. In 1xEV-DO, the

Host-to-�etwork layer is provided by 1xEV-DO Protocol Architecture TIA-856A, which

defines an additional seven layers. These additional layers will be described later in this

chapter.

Radio Access Network (RAN) Architecture Data Interface ProtocolsReference models

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

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

401-614-323Issue 16 October 2009

2-17

Page 96: 1xev-Do Rf Engineering

Protocol stack and data transfer

AT Protocol Stack

The set of protocols used in any network entity are typically represented by a protocol

stack, where the protocols are stacked vertically in accordance with their functional

layers. The protocol stack in the AT device is shown in Figure 2-4, “AT Protocol Stacks

Interface” (p. 2-18).The TCP/IP reference model forms the top layers of the laptop

computer/AT protocol stack, where the host-to-network layer is provided by 1xEV-DO

Protocol Architecture IA-856A to form the bottom layers.

Figure 2-4 AT Protocol Stacks Interface

Application

Application

Transport

Internet

Hostto

NetworkDefined by

IS-856

Session

Connection

Security

MAC

Physical

StreamThis layer adds header to each stream to be transmitted and removesthe receive stream headers

Operates with the PC operated system and contains a number ofprotocols to interface the user network applications. Examples are:

SMTP, servicing e-mail browse

TELNET, enabling remote login

DNS, for mapping host name to network address

FTP, for file transport services

HTTP, for fetching pages on the World Wide Web

,

,

,

,

,

Organizes the data into segments for network delivery. woprimary protocols are used on this layer: TCP and UDP

T

Primarily concerned with the movement of data from point A to point B;that is, from the data source to its destination

Handles the transport of protocol messages and user data

Provides access terminal (AT) contact address informationmanagement, and session configuration and management

Provides connection management to maintain the establishedAT/RAN air-link.

Provides air interface security using authentication and encryptionof AT traffic, control, and access channel data

Identifies the procedures used to receive the transmit data overthe physical layer

Provides channel structure, frequency, power output and modulationspecifications for the forward and reverse links

Radio Access Network (RAN) Architecture Data Interface ProtocolsProtocol stack and data transfer

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

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

2-18 401-614-323Issue 16 October 2009

Page 97: 1xev-Do Rf Engineering

The TCP/IP reference model forms the top layers of the laptop computer/AT protocol

stack, where the host-to-network layer is provided by 1xEV-DO Protocol Architecture

IA-856A to form the bottom layers.

Network Data Transfer

Data from the user's AT starts its journey at the application layer installed on an AT/laptop

PC, and functionally moves down and up the layers in the protocol stacks to reach its

destination. As the data is processed through each layer, header information is appended

to the data parcel to direct it through its peer layers at each network entity in the path of

the data parcel as it travels to its intended destination. One or more protocols are used at

each layer to perform specific functions to reliably deliver the data parcel to its

destination.

The following is a brief description of each layer and the functions of the primary

protocol at each layer.

Radio Access Network (RAN) Architecture Data Interface ProtocolsProtocol stack and data transfer

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

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

401-614-323Issue 16 October 2009

2-19

Page 98: 1xev-Do Rf Engineering

Layers

Application Layer

The application layer operates with the AT/PC-operated system and contains a number of

protocols to interface with the user network applications, such as an e-mail browser, with

the transport layer. Protocols commonly found in the application layer are:

• SMTP, servicing e-mail browser

• TEL�ET, enabling remote login

• D�S, for mapping host name to network address

• FTP, for file transport services

• HTTP, for fetching pages on the World Wide Web.

The data stream sent to the transport layer will be proceeded by an application header.

This header contains information that is used at the data destination to inform its

application layer of the type of data being transmitted, and the protocol used on the data.

Transport Layer

The transport layer organizes the data into segments for network delivery. In addition, this

layer is used to insure reliable data delivery.

Rather than transmitting data as a long stream of binary bits, the binary bit stream from

the application is segmented by the transport layer into discrete message parcels know as

datagrams or packets. Header data is added to each packet to identify the protocol used,

its checksum value (when applicable), and the packet number in the transmission series.

Two primary protocols are used on this layer: TCP and UDP.

Transmission Control Protocol (TCP)

The Transmission Control Protocol (TCP) provides a reliable connection-oriented

protocol to insure that the data originating at the source machine is delivered to its

destination free from any errors that may be introduced by other machines and network

routers in its path. In addition to fragmenting the data stream being sent in to packets, the

TCP protocol computes a checksum value on the packet. The checksum value is a value

related to the number of "1" bits within the packet. A transport header is appended to each

packet and identifies, among other things, the packet number within the data stream and

the checksum value.

At the packet destination, the checksum algorithm is again performed on the received

packet and its result is compared with the checksum value inserted in the packet transport

layer header. If the two checksum values match, there exists a reasonable assurance that

the message data is received uncorrupted. As a result, the receiving machine sends back

Radio Access Network (RAN) Architecture Data Interface ProtocolsLayers

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

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

2-20 401-614-323Issue 16 October 2009

Page 99: 1xev-Do Rf Engineering

an acknowledgment indicating that the transmission is successful. If the checksum values

do not match, the received data packet is assumed to be corrupted. Consequently, a

request for retransmission is sent back to the data source.

User Datagram Protocol (UDP)

Whereas TCP is a reliable, connection-oriented protocol, User Datagram Protocol (UDP)

is an unreliable connectionless-oriented protocol. This protocol allows the user to turn off

its checksum feature (flag), rendering an unreliable source-to-destination datagram

delivery system. The advantage of UDP over TCP is realized by eliminating the

calculation and handshaking operation required for checksum reliability; a faster packet

delivery data stream is achieved. Unlike TCP, which would be used to transmit numeric

data or text requiring a high degree of reliability, UDP is generally used for streaming

audio or streaming video, where corrupted packets now and then result in momentary

glitches in the audio or video. The UDP also appends each datagram with a header

containing very limited information other than destination address.

Internet Layer

This layer is primarily concerned with the movement of data from point A to point B; that

is, from the data source to its destination. Each terminal device on the Internet or any IP

network is located by a unique logical address. The physical paths from source to

destination are provided via network routers and gateways which are interconnected to

each other to form the Internet infrastructure. �ames and logical addresses of devices on

the public Internet are listed with an accredited registrar that periodically updates and

circulates routing tables over the Internet. These tables allow the network routers and

gateways to translate the logical address of each packet it receives to a physical path that

will ultimately lead the data packet to its destination.

For 1xEV-DO, the network layer may be considered as being divided into two sub-layers.

The top sub-layer is the Internet Protocol (IP) sub-layer, and the bottom is the

Point-to-Point Protocol (PPP) sub-layer.

Internet Protocol (IP)

The IP protocol defines the addressing scheme that is used over the public Internet, or any

IP network. This scheme requires that every terminal device on the network be assigned a

unique, four-byte logical IP address where each byte, which is commonly referred to as an

octet, is 8 bits long. For human readability, each octet is represented by its decimal

equivalent and is separated by periods. The IP protocol encapsulates (groups) each packet

or datagram together with its transport layer head, and adds its IP network header to

identify the data source and designation IP addresses.

Point-to-Point Protocol (PPP)

Unlike the IP protocol that allows data delivery over the Internet, the PPP protocol

establishes connection between two discrete points. The PPP protocol provides a standard

method for transporting multi-protocol datagrams from one point to another. In this case,

Radio Access Network (RAN) Architecture Data Interface ProtocolsLayers

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

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

401-614-323Issue 16 October 2009

2-21

Page 100: 1xev-Do Rf Engineering

multi-protocol datagrams implies wrapping a datagram or packet within (encapsulating)

another packet having a different network-layer transport protocol. This would be done to

support tunneling where the inner wrapped packet and its transport protocol are routed

(tunneled) through a network that supports a different transport protocol, which is the

transport protocol of the outer wrapped packet. When the packet reaches the tunnel

terminal point, which is the junction of two networks having different transport protocols,

the outer packet is stripped, allowing the inner packet to continue its journey using its

transport protocol.

In 1xEV-DO, the PPP protocol is used to transport datagram packets between the AT and

the PDS�. The AT datagram packets, which carry the transport protocol IP address of its

destination network rather than the RA� network, is wrapped in a PPP parcel to navigate

its way through the RA� network. The PDS� unwraps the PPP parcel to uncover the

datagram destination IP address prior to releasing the data over the Internet. The most

common use of PPP today is when a dial-up network is established between a personal

computer (PC) user and an Internet service provider (ISP) via the public telephone switch

network. At this time, a tunnel is established; the PC user is at one end, and the ISP

modem at the other end. The TCP (or UDP) packets to and from the PC are encapsulated

in a PPP datagram that travels the tunnel route between the PC and the ISP modem. When

a message from the PC is sent out over the Internet, the ISP modem strips away the PPP

encapsulation on datagrams from the PC, and assigns an IP source address to each TCP

(or UDP) before the message is sent out over the Internet. The reverse occurs when

Internet data is received by the PC. Data targeted to the PC is steered to its ISP which has

dominion over the PC-assigned IP address. The ISP-encapsulated packet data is received

on the Internet in a PPP datagram and uses the IP address to direct the datagram to the

modem servicing the PPP tunnel to the PC.

In 1xEV-DO, the PPP protocol is used to provide a direct connection between the user

and the PDS�, which is the demarcation point between the air interface and the public

Internet. The connection, which is referred to as a tunnel connection, is supported by the

1xEV-DO IA-856A architecture that provides the Host-to-�etwork Interface.

Radio Access Network (RAN) Architecture Data Interface ProtocolsLayers

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

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

2-22 401-614-323Issue 16 October 2009

Page 101: 1xev-Do Rf Engineering

Host-to-Network Interface

Description

The PPP connection is supported by the Radio Link Protocol (RLP), which is part of the

application layer in the 1xEV-DO IA-856A architecture installed on the AT device. If the

user terminal is a laptop PC, then the AT device is the plug-in PCMCIA card, and the PPP

payload is passed to the 1xEV-DO IA-856A/AApplication Layer via an internal

connection. The RLP maintains the air interface between the AT and the FMS. The

Application Layer provides a suite of protocols that ensure reliability over the airlink. As

described earlier, the host-to-network layers are defined by the 1xEV-DO IA-856A

architecture, of which the RLP and the MAC and Physical layers are instrumental for data

transfer.

The 1xEV-DO Protocol Architecture provides a suit of protocols in most layers. To

illustrate the new protocols that are added to provide Rev A operation, two protocol

structures are used in this document. The default structure shown in Figure 2-5,

“1xEV-DO Protocol Architecture IA-856A” (p. 2-24) is used for Rev 0. When responding

to a call from a Rev 0 AT, the R�C will use the default protocol set to process the call.

This figure and a discussion of its protocols is followed by the enhanced protocol

structure used for Rev A is shown in Figure 2-6, “Enhanced 1xEV-DO Protocol

Architecture IA-856A-A” (p. 2-29) and a discussion of its protocols. The enhanced

protocols that are added to the default structure shown in Figure 2-5, “1xEV-DO Protocol

Architecture IA-856A” (p. 2-24).

Rev 0 Default Architecture Layers

The following is a brief description of each 1xEV-DO Rev 0 default architecture layers

and associated protocols.

The 1xEV-DO Protocol Architecture provides a suit of protocols in most layers, as shown

in Figure 2-5, “1xEV-DO Protocol Architecture IA-856A” (p. 2-24).

Radio Access Network (RAN) Architecture Data Interface ProtocolsHost-to-Network Interface

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

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

401-614-323Issue 16 October 2009

2-23

Page 102: 1xev-Do Rf Engineering

Except for Radio Link Protocol (RLP) in the Application Layer and the Physical and

MAC layers, most of the top and upper layers of this architecture are used for call

processing rather than network interface. The MAC and Physical layers govern the radio

Figure 2-5 1xEV-DO Protocol Architecture IA-856A

Radio Access Network (RAN) Architecture Data Interface ProtocolsHost-to-Network Interface

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

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

2-24 401-614-323Issue 16 October 2009

Page 103: 1xev-Do Rf Engineering

link between the AT and the base station, and are discussed in this chapter and the

following chapters.

Radio Access Network (RAN) Architecture Data Interface ProtocolsHost-to-Network Interface

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

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

401-614-323Issue 16 October 2009

2-25

Page 104: 1xev-Do Rf Engineering

1xEV-DO Rev 0 default architecture layers

Introduction

The following is a brief description of each 1xEV-DO Rev 0 default architecture layers

and associated protocols.

Application Layer

Handles the transport of protocol messages and user data. This layer covers the two

default applications that are supported by 1xEV-DO compliant ATs in RA� networks.

Protocols provided by the application layer are:

• Provides transport of protocol message and user data

Default Signal Application:

– Signaling �etwork Protocol (S�P): Provides message transmission services for

signaling messages

– Signaling Link Protocol (SLP): Provides fragmentation mechanisms, along with

reliable and best-effort delivery mechanisms for signaling messages. When used

in the context of the Default Signaling Application, SLP carries S�P packets

• Default Packet Application: Provides an octet stream used to carry packets between

the access terminal and the access network. The default packet application provides

three protocols:

– Radio Link Protocol (RLP): Provides retransmission and duplicate detection for

an octet aligned data stream

– Location Update Protocol: Defines location update procedures and messages in

support of mobility management for the Default Packet Application

– Flow Control Protocol: Defines flow control procedures to enable and disable the

Default Packet Application data flow.

Stream Layer

The air interface can support up to four parallel application streams. This layer adds

headers to each stream to be transmitted and removes the receive stream headers. The first

stream (Stream 0) always carries signaling, and the other three can be used to carry

applications with different Quality of Service (QoS) requirements or other applications.

Radio Access Network (RAN) Architecture Data Interface Protocols1xEV-DO Rev 0 default architecture layers

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

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

2-26 401-614-323Issue 16 October 2009

Page 105: 1xev-Do Rf Engineering

Session Layer

Provides Access Terminal (AT) contact address information management, and session

configuration and management. A session is an AT/A�-shared state, and the session layer

is used to store the protocols and protocol configurations that must be negotiated and are

used for AT/A� communications. Protocols provided by the session layer are:

• Session Management Protocol: Provides a means to control the activation and

deactivation of the Address Management Protocol and the Session Configuration

Protocol. It also provides a session keep-alive mechanism.

• Address Management Protocol: Provides Access Terminal Identifier (ATI)

management

• Session Configuration Protocol: Provides negotiation and configuration for the

protocols used in the session.

Connection Layer

Provides connection management to maintain the established AT/RA� air link. The

connection layer manages the forward traffic channel and the reverse traffic channel. The

control channels assigned to the AT. Protocols provided by the connection layer are:

• Air Link Management Protocol: Provides the overall state machine management that

an AT and an RA� follow during a connection

• Initialization State Protocol: Provides the procedures that an AT follows to acquire a

network and that an RA� follows to support network acquisition

• Idle State Protocol: Provides the procedures that an AT and an RA� follow when a

connection is not open

• Connected State Protocol: Provides the procedures that an AT and a RA� follows

when a connection is open

• Route Update Protocol: Provides the means to maintain the route between the AT and

the RA�

• Overhead Messages Protocol: Provides broadcast messages containing information

that is mostly used by Connection Layer protocols

• Packet Consolidation Protocol: Provides transmit prioritization and packet

encapsulation for the Connection Layer.

Security Layer

Provides air interface security using authentication and encryption of AT traffic, control,

and access channel data. Protocols provided by the security layer are:

• Key Exchange Protocol: Provides the procedures followed by the AT and the RA� to

exchange security keys for authentication and encryption

• Authentication Protocol: Provides the procedures followed by the AT and the RA�

for authenticating traffic

Radio Access Network (RAN) Architecture Data Interface Protocols1xEV-DO Rev 0 default architecture layers

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

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

401-614-323Issue 16 October 2009

2-27

Page 106: 1xev-Do Rf Engineering

• Encryption Protocol: Provides the procedures followed by the AT and the RA� for

encrypting traffic

• Security Protocol: Provides procedures for generation of a cryptosync that can be

used by the Authentication Protocol and Encryption Protocol.

MAC Layer

Identifies the procedures used to receive the transmit data over the physical layer.

Protocols provided by the MAC Layer are:

• Control Channel MAC Protocol: Provides the procedures followed by the RA� to

transmit and by the AT to receive the Control Channel

• Access Channel MAC Protocol: Provides the procedures followed by the AT to

transmit, and by the RA� to receive the Access Channel

• Forward Traffic Channel MAC Protocol: Provides the procedures followed by the

RA� to transmit, and by the RA� to receive the Forward Traffic Channel

• Reverse Traffic Channel MAC Protocol: Provides the procedures followed by the AT

to transmit, and by the RA� to receive the Reverse Traffic Channel.

Physical Layer

Physical Layer Protocol: Provides channel structure, frequency, power output and

modulation specifications for the forward and reverse links. At the RF engineering level,

this course is primarily concerned with the physical and MAC layers.

Radio Access Network (RAN) Architecture Data Interface Protocols1xEV-DO Rev 0 default architecture layers

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

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

2-28 401-614-323Issue 16 October 2009

Page 107: 1xev-Do Rf Engineering

Rev A Enhanced Architecture Layers

Description

The enhanced protocols that are added to the default protocols to provide Rev A operation

are shown in Figure 2-6, “Enhanced 1xEV-DO Protocol Architecture IA-856A-A”

(p. 2-29).

Figure 2-6 Enhanced 1xEV-DO Protocol Architecture IA-856A-A

Enhanced Idle

State

Protocol

Virtual Stream

Protocol

CDMA2000

Circuit Services

Notification

ProtocolRadio Link

Protocol

Enhanced

Control

Channel MAC

Protocol

Enhanced

Access Channel

MAC Protocol

Subtype 1

Reverse Traffic

Channel MAC

Protocol

Enhanced

Forward Traffic

Channel MAC

Protocol

Session

Layer

Stream

Layer

Application

Layer

MAC

Layer

Security

Layer

Physical

Layer

Generic

Security

Protocol

SHA-1

Authentication

Protocol

Multi-flow Packet

Application

CDMA2000 Circuit

Services Notification

Application

Location Update

Protocol

DH Key

Exchange

Protocol

Flow

Control

Protocol

Data Over

Signaling

Protocol

Multimode

Capability Discovery

Application

Multimode

Capability

Discovery

Protocol

Connection

Layer

Subtype 2

Reverse Traffic

Channel MAC

Protocol

Subtype 3

Reverse Traffic

Channel MAC

Protocol

Subtype 1

Physical Layer

Protocol

Subtype 2

Physical Layer

Protocol

Radio Access Network (RAN) Architecture Data Interface ProtocolsRev A Enhanced Architecture Layers

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

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

401-614-323Issue 16 October 2009

2-29

Page 108: 1xev-Do Rf Engineering

Protocols

Rev A Application Layer Protocols

The application layer is divided into four sections. The primary section is the Multi-Flow

Packet Application (MFPA) that supports. The four sections are:

Radio Link Protocol (RLP) - provides the air interface for multiple flows (MFPA) from

different types of applications with different QoS requirements.

Data Over Signaling Protocol - Supports the transmission of a small amount of data over

the access or control channel to provide push-to-talk (PTT) functionality.

3G1X Circuit Services �otification Application - Permits the AT user to receive 3G-1X

circuit-switched services such as Page, SMS, Crossing of 3G-1X Paging Zone Boundary,

etc., while the AT is still operating for Packet Data Service via 1xEV-DO Rev A.

Multimode Capability Discovery Application - Discovers the specific capabilities of

multimode devices, such as the ability to support hybrid MS/AT operation or the

limitation of the AT's multimode operating capabilities (e.g., can the AT simultaneously

monitor common channels of 1x-EV-DO and CDMA2000).

Rev A Stream Layer Protocol

AVirtual Stream Protocol is added to provide multiplexing of distinct application streams

and supports up to 127 Virtual Streams that are dynamically configured via GAUP. The

Default Stream Protocol in Rev 0 provides four streams: Stream 0 is dedicated to

signaling and defaults to the Default Signaling Application and Streams 1 through 3 can

be used for any other applications. In Rev A, the new Virtual Stream Protocol is required

only when more than 4 applications need to be bounded to more than 4 different streams.

Rev A Connection Layer Protocols

Two new protocols are provided at the Connection layer:

Enhanced Idle State protocol - allows variable wake-up time intervals as negotiated

between the AT and the R�C during session configuration (or using GAUP). This new

protocol improves idle state monitoring capabilities by supporting different control

channel cycles:

• Shorter control channel cycles for reduced paging delay and enhance PPT operation

• Longer control channel cycles for better battery life

The selection of shorter or longer cycles is a trade-off between connection setup time and

terminal battery life. Also, this enhancement introduces a new PagingMask attribute to

allow the AT to specify dead times when the AT is not monitoring the 1xEV-DO control

channel to monitor functions of other technologies such as 3G-1X, IEEE 802.11, etc.

Radio Access Network (RAN) Architecture Data Interface ProtocolsProtocols

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

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

2-30 401-614-323Issue 16 October 2009

Page 109: 1xev-Do Rf Engineering

Generic Attribute Update Protocol (GAUP) - allows simple configuration attribute

changes without costly session configuration protocol exchange and without releasing the

connection.

Rev A MAC Layer Protocols

Enhance protocols are provided at the MAC layer for the Forward, Reverse, Access and

Control channel

Enhanced Forward Traffic MAC Protocol - supports both delay-tolerant and

delay-sensitive traffics, providing:

• Data Source Control (DSC) channel for uninterrupted data transfer during switching

of forward serving cells

• Short packet formats to improve transmit-packing and reduce the interruption to data

flow to a user during virtual soft handoff (VSHO)

• Multi-user packets for delivering data to a number of users in a single packet,

improving support for delay sensitive applications such a VoIP

The following attributes are new for Enhanced Reverse Traffic MAC protocol, and are

not in Default Reverse Traffic.

The three Enhanced Reverse Traffic Channel (RTC) MAC Protocol Subtypes are as

follows:

1. Subtype 1 RTC MAC protocol - operates with Physical Layer Subtype 0 or Subtype 1.

Except for Rate Transition Vectors Setable by the Generic Attribute Update Protocol

(GAUP), Subtype 1 RTC MAC protocol is the same as Rev 0 default RTC MAC

protocol. The GAUP protocol dynamically updates values of certain attributes

belonging to different lower and higher layer protocols in the AT and R�C without

costly Session Configuration Protocol Exchange and without releasing the connection.

2. Subtype 2 RTC MAC Protocol - operates with Subtype 0 or Subtype 1 Physical Layer

protocol to map multiple reverse link MAC flows to application flows.

3. Subtype 3 RTC Protocol - operates with Subtype 2 Physical Layer Protocol:

• Uses multiple reverse link MAC flows with Rev A Physical Layer

• Provides efficient support for latency-sensitive and delay-tolerant applications by

supporting Low Latency and High Capacity Transmission mode

Rev A Physical Layer Protocols:

Two new Physical Layer Subtypes have been introduced in addition to the default

Physical Layer protocol set that is used in Rev 0, which is designated as Subtype 0.

Subtype 1 Physical Layer Protocol – provides the 19.2 and 38.4 kbps access channel data

rates with shorter preamble. With the exception of providing new access channel date

rate, the functionality of this protocol is the same as the default Physical layer protocol in

Rev 0.

Radio Access Network (RAN) Architecture Data Interface ProtocolsProtocols

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

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

401-614-323Issue 16 October 2009

2-31

Page 110: 1xev-Do Rf Engineering

Subtype 2 Physical Layer Protocol – supports a wider range of Physical Layer packet

sizes to improve packing efficiency. A 128-bit smaller packet size is introduced in both

the forward and reverse links. Also introduced is a 5120-bit packet in the forward link and

a 12288-bit packet in the reverse link. A wider range of data rates is also provided:

• 4.8 kbps to 3.072 Mbps in the forward link

• 4.8 kbps to 1.843 Mbps in the reverse link

The Subtype 2 Physical Layer protocol suit includes a new set of enhanced protocols

governing the operation of the control channel and forward and reverse traffic channels to

provide:

• Reverse link incremental redundancy and hybrid ARQ to shorten reverse link latency

• Rapid Connection Setup with improved terminal battery life

• Short inter-transmit interval on control channel

• Short packet control channel (4-slots) in Idle state

�ew Data Source Control (DSC) Channel for seamless cell selection

Radio Access Network (RAN) Architecture Data Interface ProtocolsProtocols

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

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

2-32 401-614-323Issue 16 October 2009

Page 111: 1xev-Do Rf Engineering

Simple IP and Mobile IP Internet Access

Overview

Purpose

The section covers the Simple IP and Mobile IP Internet Access.

Contents

RA� Protocol Interface 2-34

Simple IP connection 2-37

Simple IP Connection with Private �etwork 2-38

Mobile IP Connection 2-41

Basic functionalities for VoIP 2-44

Support for Evolved High Rate Packet Data (eHRPD) 2-45

Support for multi-carrier RevB 2-47

Radio Access Network (RAN) Architecture Simple IP and Mobile IP Internet AccessOverview

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

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

401-614-323Issue 16 October 2009

2-33

Page 112: 1xev-Do Rf Engineering

RAN Protocol Interface

Description

Using protocol stacks, the RA� network interface with the PDS� can be represented as

shown in Figure 2-7, “RA� Protocol Interface” (p. 2-34) for a simple IP access, where

the wireless service provider is the Internet service provider. The major difference

between simple and mobile IP access occurs at the interface between the PDS� and the

connecting IP network. This figure assumes a laptop PC connected to an AT PCMCIA

card via a 10BaseT connection; therefore, the network protocols provided by the laptop

PC /AT PCMCIA card is considered a single network entity.

Peer-to-Peer Communication

When a message entered on the laptop/AT is sent over the Internet, its data parcels, which

are referred to as the payloads, are functionally passed down the laptop/AT protocol stack

and subsequently up and down each protocol stack between the laptop and its ultimate

destination. As each payload is passed down the stack layers, the payload is encapsulated,

and a header, and sometimes a trailer, is appended to the payload. The header contains

information that is only useful to its peer (corresponding) layer at each network entity in

the path of the data as its payload travels to its intended destination. As the payload and

appended header is passed down to the next layer, the receiving layer does not distinguish

Figure 2-7 RAN Protocol Interface

Application

Transport

Network

Hostto

Network

TCPUDP

TCPUDP

TCPUDP

TCPUDP

S-IP

PPPPPP

MAC HDLC HDLC

PHY PHYPHY

MAC

PHY

RLP

IP IP IPIP

IPIP

EthernetEthernet EthernetEthernetEthernetT1/E1 T1/E1

RLP

GRE GRE

IP IP

S-IP S-IP IP

Air Intrface

Backhaul

T1/E1* Line 100Base T R-P A10/A11 IP Network

Laptop/AT BTS Uplink RANRouter

Downlink RANRouter

FMS PDSN Internet

** ** **

** May be an ATM over SONET or similar type connection

FixedEnd

System

L2 L2

*May be an Ethernet line from Modular 4 base station if EthernetBackhaul feature is enable in Release R24.0

Radio Access Network (RAN) Architecture Simple IP and Mobile IP Internet AccessRAN Protocol Interface

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

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

2-34 401-614-323Issue 16 October 2009

Page 113: 1xev-Do Rf Engineering

between header and payload, and regards the entire parcel as being passed down as the

payload. The receiving layer will then encapsulate the parcel passed down to append its

header to the payload.

This process is repeated until the payload is passed between the Physical Layers (the

bottom layer of each stack) of adjacent network entities. For example, after the Physical

Layer (PHY) in the laptop/AT protocol stack, the Physical Layer appends its header on

the payload passed down from the MAC layer, and the data parcel is transmitted over the

air interface to the base station. The Physical layer in the base station protocol stack will

use the appended Physical Layer header to identify the individual control and traffic

channel being transmitted, and will strip off this header before passing the data parcel

(payload) up to its MAC layer. Therefore, the payload passed up to the MAC Layer in the

base station stack is identical to the payload passed down from the MAC to Physical

layers in the laptop/AT stack. Because the payloads passed between the two MAC layers

are identical, a peer-to-peer connection between the two corresponding layers can be

assumed.

PPP Connection Between the AT and PDSN

The payload encapsulated for PPP transmission between the laptop/AT and the PDS� is

transported by two concatenated protocols: the Radio Link Protocol (RLP) and the

Generic Routing Encapsulation (GRE) protocol. The RLP protocol carries the PPP

payload received from the laptop PC between the AT and the FMS, and the GRE protocol

carries the payload between the Packet Control Function (PCF) in the FMS and the

PDS�. Both the RLP and the GRE are processed on the same single board computer in

the FMS, and the paths between the two protocols are connected by data transfers in

memory. Therefore, a peer-to-peer PPP connection is established between the laptop PC

and the PDS�.

Radio Link Protocol (RLP)

The RLP connection between the AT and the FMS has negative acknowledgment

(�ACK) capabilities, indicating when missing frames are discovered. This �ACK

capability, which reduces the amount of signaling required, allows for the retransmission

of frames that were lost. While this capability will not totally eliminate lost frames, it will

significantly decrease the probability of incurring lost frames. If frames are lost anyway, a

high-level protocol or mechanism, such as TCP should recover from that problem as it

does now in wire Internet connections.

The physical layer between the base station and uplink RA� route is provided across an

Ethernet or T1/E1 lines. Up to two T1/E1 lines are supported for each carrier for a

three-sector base station deployment. Backhaul non-channelized data interface over the

T1/E1 lines is controlled by the High Data rate Link Control (HDLC) protocol, which is

operated on the MAC layer. The uplink RA� router unwraps the HDLC protocol from the

datagram, and the datagram is then sent to the proper FMS in accordance with its IP

Radio Access Network (RAN) Architecture Simple IP and Mobile IP Internet AccessRAN Protocol Interface

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

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

401-614-323Issue 16 October 2009

2-35

Page 114: 1xev-Do Rf Engineering

address via an Ethernet connection. In this case, the IP address is a local IP, identified an

UATI (Unicast Access Terminal Identifier) so that the AT can be addressed by the RA�

and subsequently direct the datagram packets to and from the AT through the RA�

network. The UATI should not be confused with the dynamic IP address provided by the

PDS� for a simple IP connection. In the FMS, the TCP/IP headers encapsulated by the

base station are removed to restore the RLP datagram transmitted by the AT. If the RLP

datagram is not properly received, the FMS causes a signal to be sent back to the AT, and

the RLP datagram is retransmitted.

Generic Routing Encapsulation (GRE) Protocol

The datagram is then converted from the RLP protocol to a Generic Routing

Encapsulation (GRE) protocol for transferring to the PDS�. Data transmission between

the FMS and PDS� is via the output RA� router, which operates in the same manner as

the input RA� router. In a drawing such as Figure 2-7, “RA� Protocol Interface”

(p. 2-34), it may become difficult to visualize the need and function for the uplink and

downlink RA� routers without considering that a RA� may consist of eight FMSs, each

servicing up to 48 base stations at any one time. At the PDS�, the GRE encapsulation is

stripped from the received datagram to complete the PPP protocol between the AT and the

PDS�.

Unicast Access Terminal Identifier (UATI)

The UATI is 128 bits long and consists of two fields: UATI104 and UATI024. This

address is modeled after the IPv6 address, which is expected to be widely in use as a

public Internet standard. The UATI104 field provides the 104 most significant bits

(MSB), higher-order bits, of the UATI address and is used to steer data packets through

the RA� network between the base station and the PDS�. The 104-bit value is used as

part of the base station sector identification; therefore, each sector has a unique UATI104

value. The 24 least significant bits (LSB), which make up the UATI024 are assigned by

the base station sector to identify each AT user in its sector area. Whenever an AT enters

(or registers) into a subnet the system assigns the AT a new UATI address to index its

sector location.

Radio Access Network (RAN) Architecture Simple IP and Mobile IP Internet AccessRAN Protocol Interface

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

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

2-36 401-614-323Issue 16 October 2009

Page 115: 1xev-Do Rf Engineering

Simple IP connection

Description

For a simple IP (S-IP) connection, the PDS� assigns an S-IP address to the AT for the

duration of the session as long as the AT remains in the PDS� domain. The S-IP address

is appended to the datagram received from the AT as the datagram packet source IP

address.The datagram enters the Internet via the Level 2 (L2) and physical Internet layers,

and is then steered to its designated fixed-end system by its destination IP address, which

was selected or entered by the AT user at the application level.

Process

When the datagram packet reaches the protocol stack of its intended destination, the

datagram packets climb their way up its protocol stack to the application level to create a

specific communication objective. This objective might be to send or reply to e-mail,

request a download, initiate an inquiry or search, etc. Prior to reaching the application

layer, a checksum validation may be performed at the transport level to ensure that

datagram packets are received uncorrupted. If the content of a packet is corrupted, a

request for retransmission of that packet is initiated. At this time, the source IP address

appended by the datagram packet is used to route the retransmission request through the

Internet back to the PDS�. The source IP address is also used in the fixed-end system

whenever datagram packets must be sent to the AT.

Radio Access Network (RAN) Architecture Simple IP and Mobile IP Internet AccessSimple IP connection

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

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

401-614-323Issue 16 October 2009

2-37

Page 116: 1xev-Do Rf Engineering

Simple IP Connection with Private Network

Description

Most private networks use tunneling to interconnect a number of geographically

non-continuous Local Area �etworks (LA�s) through the ubiquitous public Internet via a

firewall to create one virtual private network (VP�). The firewall, which effectively

separates the LA�s within VP� from the public Internet, provides private network

security by preventing Internet users outside the VP� from penetrating the VP�. This is

done while allowing users within the VP� to access the Internet and reach across the

Internet to access any LA� within the VP�. Essentially, tunneling is the process of

placing an entire packet within another packet and sending it over an external network.

The protocol of the outer packet must be understood by the external network at both

tunnel end points (known as tunnel interface points), where the packet enters and exits the

VP�.

AAA Process

The firewall within the VP� provides a Layer 2 Tunneling Protocol (L2TP) network

server (L�S) which is operated in conjunction with an AAA (Authentication,

Authorization And Accounting) Server (see Figure 2-8, “RA� to VP� Connectivity via

the Internet” (p. 2-39)) to ensure secure access from any environment outside the VP�.

L2TP is a packet-encapsulating protocol used by VP� to tunnel datagram packets through

an external network such as the Internet. When a request to establish a session comes in

from the Internet or any remote-access VP� environment, the request is proxy to the

AAA Server. The AAA Server then performs the following:

1. Authentication: Identifies client (user) petitioning access and verifies password

2. Authorization: Determines client's rights to system resource (what resources are the

client allowed to access, and functions the client is allowed to perform)

3. Accounting: Maintains database tracking client activity for security auditing, billing,

or reporting purposes.

If the client requesting access to the VP� is authenticated by the AAA Server, access

through the firewall to the VP� is permitted by L�S.

Radio Access Network (RAN) Architecture Simple IP and Mobile IP Internet AccessSimple IP Connection with Private Network

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

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

2-38 401-614-323Issue 16 October 2009

Page 117: 1xev-Do Rf Engineering

RAN to VPN Connectivity via the Internet

Packet transfer process

When the AT user accesses a fixed-end system within a private IP network, the PDS�

strips away the GRE header to recover the original PPP-wrapped AT datagram packet.

The PPP datagram is encapsulated for Layer 2 Tunneling Protocol (L2TP) transmission,

as shown in Figure 2-9, “Simple IP Connection with Private �etwork, Protocol Stack”

(p. 2-40).

When the AT user accesses a fixed-end system within a private IP network, the payloads

received through the air interface at the base station are PPP- transferred to the PDS� via

the RLP and GRE protocols as described for S-IP connectivity to the Internet (refer to

“PPP Connection Between the AT and PDS�” (p. 2-35)). The GRE encapsulation of data

packets received at the FMS is stripped by the PDS� to expose the original PPP packets.

The PDS� encapsulates the PPP packet using the L2TP protocol to tunnel the PPP data

packet through the Internet to the VP� using the source IP address received from the AT,

as shown in Figure 2-9, “Simple IP Connection with Private �etwork, Protocol Stack”

Figure 2-8 RAN to VPN Connectivity via the Internet

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Radio AccessNetwork (RAN)

1x EV-DO BTS 1

1x EV-DO BTS 48

1x EV-DO BTS 288

1x EV-DO BTS 240

PacketData

ServiceNode

(PDSN)

Internet

AAA AAA

FixedEnd

System

L2TPNetworkServer(LNS)

Virtual Private Network

Radio Access Network (RAN) Architecture Simple IP and Mobile IP Internet AccessSimple IP Connection with Private Network

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

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

401-614-323Issue 16 October 2009

2-39

Page 118: 1xev-Do Rf Engineering

(p. 2-40). If the data packets are authorized to penetrate the VP�, the data packets are

routed to their designated fixed-end system via the physical and lower L1 and L2 layers

defined by the VP�.

Simple IP Connection with Private Network, Protocol Stack

Figure 2-9 Simple IP Connection with Private Network, Protocol Stack

PHY PHY PHYEthernet

GRE

IP

IPIP

L2TP L2TP

PDSN Internet L2TP NetworkServer (LNS)

FixedEnd

System

UDP UDP

L2

L2

L2

L2

L2

L1 L1

PHY

To/From AT

To/From FMS

Virtual Private Network

PPP

TCPUDP

APPL

Radio Access Network (RAN) Architecture Simple IP and Mobile IP Internet AccessSimple IP Connection with Private Network

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

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

2-40 401-614-323Issue 16 October 2009

Page 119: 1xev-Do Rf Engineering

Mobile IP Connection

Description

As previously described, an AT may have its own static IP address that is constant and

issued by an agent (ISP) other than the serving PDS�. In this case, which is shown in

Figure 2-10, “Mobile IP Internet Access” (p. 2-42), the agent issuing the IP address is

considered a Home Agent (HA) for the IP address, and the PDS� will operate as a

Foreign Agent (FA) for the network having domain over the static IP address. Amobile IP

provides the AT user three advantages over a simple IP address:

• The AT user is free to roam outside of its current serving PDS� without the need to

renegotiate a new IP address (most horizontal applications with a simple IP result in

momentary traffic delay between 10 and 30 seconds when renegotiating a new IP

address, and certain applications may require restarting)

• In most cases, the home agent is behind the firewall of a VP�, permitting the AT user

full access within the VP�

• Certain ATs are able to support multiple IP M-IP sessions.

Radio Access Network (RAN) Architecture Simple IP and Mobile IP Internet AccessMobile IP Connection

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

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

401-614-323Issue 16 October 2009

2-41

Page 120: 1xev-Do Rf Engineering

Mobile IP Internet Access diagram

Process

When the AT accesses the Internet to initiate a session and presents the PDS� with its

own static IP address, the PDS� first validates the static IP address with the AAA Server

having domain over the IP address. This is done through the AAA Server associated with

the serving PDS�. To validate the static IP address, a connection is established between

the AAA Server and the AAA Server associated with the static IP address. After the IP

address and AT user are validated, the AT user data is tunneled via the Internet between

the PDS�, which is operating as a foreign agent, and the home agent having domain over

the static IP address. Because the home agent is behind the VP� corporate firewall, the

home agent permits the AT user to access any fixed-end system permitted by its AAA

profile, through the VP�, as well as any fixed-end system connected to the Internet. The

protocol stack setup for mobile IP connectivity is similar to the protocol stack setup for

simple IP connectivity shown in Figure 2-11, “Mobile IP Internet Access, Protocol Stack”

Figure 2-10 Mobile IP Internet Access

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Radio AccessNetwork (RAN)

1x EV-DO BTS 1

1x EV-DO BTS 48

1x EV-DO BTS 288

1x EV-DO BTS 240

Packet DataService Node

Foreign Angent(PDSN/FA)

AAA

FixedEnd

System

AAA

HomeAgent(HA)

Virtual Private Network

Radio Access Network (RAN) Architecture Simple IP and Mobile IP Internet AccessMobile IP Connection

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

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

2-42 401-614-323Issue 16 October 2009

Page 121: 1xev-Do Rf Engineering

(p. 2-43). The primary difference is that when operating as a foreign agent, the serving

PDS� uses an IP Security (IPSec) tunneling protocol to transfer AT user data to the VP�

rather than the L2TP protocol.

Mobile IP Internet Access, Protocol Stack diagram

IP/Sec

Internet Protocol Security Protocol (IP/Sec) provides enhanced security features such as

better encryption algorithms and more comprehensive authentication. IPSec has two

encryption modes: tunnel and transport. Tunnel encrypts the header and the payload of

each packet, while transport only encrypts the payload. Only systems that are

IPSec-compliant can take advantage of this protocol. Also, all devices must use a

common key, and the firewall of each network must have similar security policies set up.

The IPSec protocol is an IETF effort to add security capabilities to the IP at Layer 3, and

is a natural choice for native IP traffic. Implementing IPSec is a key element of the HA

solution, as it provides clear and widespread support to enterprise users, service

providers, and equipment vendors.

Figure 2-11 Mobile IP Internet Access, Protocol Stack

PHY PHY PHYEthernet

GRE

IP

M-IP IPM-IP

PDSN/Foreign Agent

(FA)

Internet VPN Home Agent (HA)

FixedEnd

System

L2

L2 L2 L2

L2

IP/SEC IP/SEC

L1 L1

PHY

To/From AT

To/From FMS

Virtual Private Network

PPP

TCPUDP

APPL

Radio Access Network (RAN) Architecture Simple IP and Mobile IP Internet AccessMobile IP Connection

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

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

401-614-323Issue 16 October 2009

2-43

Page 122: 1xev-Do Rf Engineering

Basic functionalities for VoIP

Introduction

The basic functionalities to support VoIP over a Rev A Radio Access �etwork (RA�) is

provided by Basic functionalities for VoIP support on HRPD Rev A RA�, FID12102. The

main functionalities included in this feature are:

Support of the Enhanced Multi-Flow Packet Application (EM-FPA)

This feature was introduced in 3GPP2 standard TIA-1054. The EM-FPA has additional

functionalities to the Multi-Flow Packet Application (M-FPA) and is used to better

support certain supplemental services such as VoIP. The EM-FPA additional

functionalities include support of the RObust Header Compression (ROHC) Scheme

(Feature FID-12102.6). ROHC reduces IP overhead by decreasing VoIP packet header

size. ROHC parameter negotiation uses EM-FPA signaling attributes to eliminate the need

to create a PPP tunnel over the air-interface.

Support of Multiple Link Flows (a.k.a. RLP Flows in TIA-856-A)

The EM-FPA provides packet streams that can be used to carry octets or packets between

the AT and the RA�. Each packet stream is called a Link Flow.

A Link Flow can be configured to be Packet or Octet-based. In this feature Packet-based

will be used for VoIP flow and Octet-based will be used for all other flows. Link Flow can

be configured to support out-of-order delivery. The Operator will have the choice to set

(through translations) the VoIP Link low, to support either in-order or out-of-order

delivery.

Although up to 31 activated Link Flows are permitted, in this feature, no more than 4

Link flows will be configured. These are:

• Link Flow for VoIP speech part

• Link Flow for Control Signaling (SIP)

• Link Flow for regular BE data traffic

• Link Flow is used for Video flow, if Video Telephony (VT) is used with EM-FPA

Support of Mapping of Reservations

In the EM-FPA, each Link Flow provides two routes for transmission and reception of

payloads. Each route is associated with a Transmitter-Receiver pair. In the initial VoIP

offering of this feature, only one route will be supported. Multiple routes might be useful

in the future when Inter-System/Inter-Vendor Seamless handoffs are defined.

The R�C will support mapping of Routes and Links Flows. An application associated

with an IP flow, such as VoIP, that has been negotiated between the AT and RA� is

defined as a Reservation in TIA-1054. Each Reservation is identified by a Reservation

Radio Access Network (RAN) Architecture Simple IP and Mobile IP Internet AccessBasic functionalities for VoIP

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

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

2-44 401-614-323Issue 16 October 2009

Page 123: 1xev-Do Rf Engineering

Label, assigned by the AT, and an associated ProfileID. An IP Flow is a series of packets

exchanged to support certain applications, for example VoIP, and the ProfileID as defined

in TSB-58-G to represent a set of QoS characteristics such as data rate, packet error rate,

latency etc.

Reservation Labels are bound to Link Flows that carry higher layer flows.

• A reservation is in either the open or closed state

• A reservation must be in the open state before it can be used

By Default, one reservation exists: 0xff: Associated with BE traffic. In the open state; all

other reservations are in the closed state by default.

The Flow QoS requirement can be requested by AT via a ProfileID. Even though this

feature mainly focuses on the support of VoIP over the Rev A RA� using the EM-FPA,

other applications, such as VT, can be negotiated with the EM-FPA, using one of the

supported ProfileIDs.

The ProfileIDs supported in this feature are the same as in FID-12078.9, which are:

• Conversational Rate Set 1 Speech (used for VoIP speech part)

• Conversational Video (4 ProfileIDs, one for each data rates: 24kbps, 40kbps, 48kbps

and 64kbps for Video flow)

• Conversational Media Control Signaling (CMCS) (used for SIP)

• Best Effort (BE) service is associated with the default Link Flow so the BE ProfileID

does not need to be explicitly signaled

Support for Evolved High Rate Packet Data (eHRPD)

Overview

With FID 39111.10, the R�C supports Evolved High Rate Packet Data (eHRPD) service

as well as HRPD. Legacy mobiles will continue to receive HRPD service, while evolved

mobiles will receive eHRPD service. The eHRPD system uses the same Evolved Packet

Core (EPC) network as does LTE. Hence, FID 39111.10 is a key prerequisite in enabling

seamless mobility between HRPD and LTE.

FID 39111.10 supports the following:

• Interfaces to the HRPD Serving Gateway (HSGW) and to the PDS� network

elements, routing eHRPD traffic/signaling to HSGWs and HRPD traffic/signaling to

the PDS�s

• Enhanced Multi Flow Packet Application (EMFPA)

• Multiple bearer flows such as Best Effort, Session Initiation Protocol, Conversational

Speech and Conversational Video.

• FL acceleration of EMFPA flows in the R�C's UTP.

Radio Access Network (RAN) Architecture Simple IP and Mobile IP Internet AccessBasic functionalities for VoIP

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

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

401-614-323Issue 16 October 2009

2-45

Page 124: 1xev-Do Rf Engineering

This feature is an essential enabler for VoIP over eHRPD.

Description

FID-39111.0 upgrades a legacy HRPD Rev A RA� to support eHRPD. This include a

software upgrade to enable the access network to control eHRPD radio resources and to

communicate properly with an HSGW. An R�C enabled with feature 39111.0 is referred

to as an eR�C. �ote that an eR�C capable of supporting eHRPD also supports legacy

HRPD functionality. With feature 39111.0 enabled, the eR�C sets up an eHRPD session

with a selected HSGW instead of PDS� to provide eHRPD services for eAT mobiles. The

eR�C sets up a HRPD connection with PDS� if the mobile is a legacy AT.

Hardware supported

AR1SR R�C (with TP690, TP752i or UTP), or on an U�C (UTP) supports this feature.

Any BTS type that currently supports Rev A can be used in an eHRPD network. There are

no BTS changes needed for eHRPD support in this feature (FID-39111.0 is not dependent

on any BTS change beyond what is supported in FID-12102.1).

As with the legacy HRPD network, the BTS and eR�C in an eHRPD network are

managed by the same OA&M entity using existing interfaces.

Dependencies

This feature is implemented on top of the legacy Enhanced Multi-Flow Packet

Application (EMFPA) feature FID-12102.1 which supports VoIP over legacy HRPD Rev

A Radio Access �etwork. The following are the main changes introduced in this feature

with respect to the legacy HRPD functionality:

Session configuration and EMFPA related changes

Some of the key changes include the following:

• Support a new dummy packet application subtype 0xFFFE ('Alternate EMFPA for

eHPRD) in the ATSupportedApplicationSubtype attribute. This subtype is not

configured for any stream, it is only used to help the R�C figure out that the AT is

eHRPD capable before deciding to negotiate the EMFPA personality. It does not

necessarily imply the AT is capable of eHRPD in any other personality.

• Support a new Protocol ID = 0x07 for the main Link Flow (Link Flow 00, a.k.a RLP

0). The Protocol ID = 0x07 indicates the upper layer is HDLC framing and eHRPD

procedures in X.S0057 will be used. This Protocol ID will be the main identification

of whether a session is configured for eHRPD.

eHRPD to HSGW interface

An eHRPD session interfaces to HSGW rather than PDS�.

Support minor changes to the A11 messaging (include the HSGW H1 IPAddress in the

A11 RRQ and RRP).

Radio Access Network (RAN) Architecture Simple IP and Mobile IP Internet AccessSupport for Evolved High Rate Packet Data (eHRPD)

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

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

2-46 401-614-323Issue 16 October 2009

Page 125: 1xev-Do Rf Engineering

HSGW selection

When registering an eHRPD session (a session is eHRPD if the Flow Protocol on the

main Link Flow uses Protocol ID = 0x07) for the first time, the eR�C has to select an

HSGW (to connect to) from the table of provisioned HSGWs (defined by the operator).

Active and idle handoff impact

For idle handoff, the source eR�C will include for an eHRPD session in the A13 Session

Information Response the new dummy packet application subtype 0xFFFE (Alternate

EMFPA for eHPRD) in the ATSupportedApplicationSubtype attribute and the new

session state attributes. For example, RLP 0 use Protocol ID = 0x07.

Alcatel-Lucent strongly recommends that the operators upgrade all R�Cs in the network

with FID-39111.0 for the commercial deployment of eHRPD. Operators might not

upgrade all the R�Cs with feature 39111.0 in the initial deployment of eHRPD. This

means FID 39111.0 is active on some Service �odes (S�) before neighboring S�s are

upgraded to support eHRPD. In these cases those neighbors S�s still work as HRPD only.

To deal with this transitional behaviors, several eHRPD and HRPD interactions are

handled.

Support for multi-carrier RevB

Overview

The Feature provides software upgrade for the current Rev A RA� products with support

of multi-carrier 1xEV-DO RevB. This feature enables the RevB mobile to receive data

over the Forward Link at rates up to 6.2 Mbps (3.1 Mbps x 2 carriers) and transmit data

over the Reverse Link at rates up to 3.6 Mbps (1.8 Mbps x 2 carriers).

Important! RevA needs to be activated before RevB can be activated.

Supported BTS

The feature covers the following BTS types:

• 9218 Macro (formerly Modcell 4.0)

• 9228 Macro (formerly Modcell 4.0B)

• 9216 Compact (formerly Compact 4.0)

• 9226 Compact (formerly Compact 4.0B)

• 9224 Sub-compact (formerly BTS-4400)

• 9234 Distributed (formerly BTS-3430)

Radio Access Network (RAN) Architecture Simple IP and Mobile IP Internet AccessSupport for Evolved High Rate Packet Data (eHRPD)

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

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

401-614-323Issue 16 October 2009

2-47

Page 126: 1xev-Do Rf Engineering

Functionality

This feature provides the following functionalities:

• Multi-carrier support of up to 2 RevB carriers per sector

• Support of dynamic carrier allocation as well as dynamic addition and deletion of

multi-carriers per call

• Symmetric mode configuration requiring the same number of forward and reverse

link carriers

• Support of new protocols (e.g. Multicarrier Router Update Protocol, Subtype 3

Physical Layer protocol) introduced in the RevB standard defined in 3GPP2

C.S0024-B

• Support of Multi-Link Multi Flow Packet Application defined in 3GPP2 C.S0063-A

v2.0

• Backward compatibility with Rev A and coexistence of Rev A& B mobile users on

the same carrier.

Performance impacts

An end user’s data throughput performance is influenced by the condition of the RF

environment. When RF conditions allow, the FID-13500.2 can provide up to two times

better in data throughput with Rev BATs when comparing to that can be provided by a

Rev A system.

Rev.B provides a flexible utilization of spectrum for the mobile users. A user is able to

obtain broadband service without losing coverage of Rev.A. When the RF condition

allows, the mobiles can utilize multiple carriers' spectrum to expedite the application.

When the mobile moves to the cell edge, it can revert to single-carrier operation to

maintain coverage and save power.

From the system prospective, Rev.B also provides a more efficient utilization of

spectrum. As the carrier loading is dynamic, especially for bursty data applications,

allowing multiple carriers per user helps balancing the different carriers, utilizing the RF

spectrum more efficiently.

Description

FID 13500.2 delivers the RevB Multi-Carrier DO (MCDO) function in the 1xEV-DO

system. Prior to the HRPD RevB standard (C.S0024- B v2.0), the Access �etwork (A�)

assigns traffic channel to the Access Terminal (AT) on a single carrier. With RevB, traffic

channels of more than one carrier can be assigned to the AT simultaneously, increasing

the data throughput to the end users.

The increased data bandwidth applies to both the forward and reverse links. This feature

supports RevB for up to two carriers and can effectively offer up to 6.2 Mbps data rate to

the AT over the forward link and 3.6 Mbps data rate over the reverse link.

Radio Access Network (RAN) Architecture Simple IP and Mobile IP Internet AccessSupport for multi-carrier RevB

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

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

2-48 401-614-323Issue 16 October 2009

Page 127: 1xev-Do Rf Engineering

FID 13500.2 provides a software upgrade solution of RevB MCDO, using existing BTS

and R�C hardware. This feature is also backward compatible with RevA and Rel0

services.

FID 13500.2 will provide MCDO on OneBTS platform BTSs and both R1SR and U�C

R�Cs. The enabling of MCDO service will be controlled via Licensing on Rev B MCDO

carriers.

Feature Dependencies

The implementation of FID-13500.2 assumes the QoS feature 12078.9 is present. The

QoS feature control parameter "Per Application QoS Feature Enable"must be placed in

the "enable" position via translation before FID-13500.2 can be turned on.

It is recommended that the QoS feature control be set in the "enable" position even if the

R�C does not have Rev B carriers. This will ensure that the user will get Rev A service in

those places where Rev B carriers are not available.

Supported mobile access terminals

FID-13500.2 requires newATs. The AT must conform to the 1xEV-DO RevB air-interface

standard specified in 3GPP2 C.S0024-B v2.0 and the Multi-link Multi-flow Packet

Application (MMPA) specified in 3GPP2 C.S0063-A v2.0.

It must be able to switch to the RevA or Rel0 personality when it is not served by the

RevB network.

FID-13500.2 to supports three personalities for interfacing to the Rev BAT. It will

support a Rev B personality, a Rev A personality and a Rel 0 personality. Each personality

and its underlying protocols are shown below:

• Rev B: MMPA + MC-RUP, MC-FTC, MC-RTC, and Subtype 3 PHY

• Rev A: one of (EMPA, MFPA, DPA) + RUP, Rev AMAC and PHY

• Rel 0: DPA + RUP, Rel0 MAC and PHY

Multiple personalities allows the A� to switch the AT’s personality appropriately to meet

the capability of AT’s serving sector. For example, the sector may be equipped with a Rev

B, Rev A or Rel 0 carrier.

Initial release of Rev B

The initial AT release supports up to three Rev B carriers. The three carriers do not need

to be adjacent, but must be in the same band. In addition, the highest and lowest CDMA

channels must be within the limit of a maximum frequency separation. The value of the

limit varies depending on the AT device. The earlier device (e.g., QSD5860) has a

maximum frequency separation of 5 MHz, while the later device has a maximum

frequency separation of 7.5 MHz.

Radio Access Network (RAN) Architecture Simple IP and Mobile IP Internet AccessSupport for multi-carrier RevB

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

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

401-614-323Issue 16 October 2009

2-49

Page 128: 1xev-Do Rf Engineering

In the first phase, FID-13500.2 provides an increase data throughput up to 6.2 Mbps over

the FL and 3.6 Mbps over the RL for a single RevBAT.

MCDO protocols required

The support of Rev B MCDO requires the following new protocols specified in the

3GPP2 C.S0024-B v2.0 standard be supported:

• Subtype 3 Physical Layer

• Multi-Carrier Forward Traffic Channel MAC (MC-FTC)

• Multi-Carrier Reverse Traffic Channel MAC (MC-RTC)

• Multi-Carrier Route Update Protocol (MC-RUP)

In addition, the Multi-link Multi-flow Packet Application (MMPA) application protocol

defined in the 3GPP2 C.S0063-A v2.0 standard is supported.

Enabling on a per RNC basis

The service provider can enable or disable the RevB feature on a per R�C basis via

OMC-RA�. The service provider cannot enable the RevB feature on a R�C unless all the

equipped APs on the R�C have 2GB RAM. If the feature is enabled, the customer can

activate the individual RevB carrier licenses via the OMC-RA�. The OMC-RA� will

present the following in the R�C level:

• �umber of 1xEV-DO carrier allowed by the Rev B software license key

• �umber of 1xEV-DO carrier activated for Rev B service

Equipment and spectrum requirements

The feature supports MCDO with SB-EVMs and URC-IIs (no classic URC) in the above

BTSs. For the backhaul, up to 8 T1s/E1s on the URC-II or Ethernet backhaul can be used.

The MCDO carriers can be in the same BTS frame or separate BTS frames. FID-13500.2

does not support RevB MCDO on legacy Modcells (Modcells 1-3).

Traffic Processor and AP requirements

The system supports MCDO on R1SR and U�C R�Cs. It requires the use of the

following types of APs and TPs:

• AP with 2G bytes memory

• TP: UTP or 752i TP on R1SR, UTP on U�C

The system does not provide Rev B connections on the 690 TPs. It selects other TP types

(that is, 752i, UTP) for Rev B connections. Amix of 690 TPs and other TP types (that is,

UTP and 752i) on the R1SR R�C is still allowed.

Radio Access Network (RAN) Architecture Simple IP and Mobile IP Internet AccessSupport for multi-carrier RevB

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

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

2-50 401-614-323Issue 16 October 2009

Page 129: 1xev-Do Rf Engineering

The following shows the R1SR and U�C support:

• R1SR:

– TP: 752i TP and UTP (no Rev B connection to 690 TP)

– AP: AP with 2G bytes memory only, no 1GAP support

• U�C

– 2GAP and UTP

Band Class

BC0 (850) and BC1 (1900)

• All MCDO carriers in a sector must be of the same frequency band

• Can be Rev B carriers in one band, and Rev A carriers in another band in a dual band

environment

Radio Access Network (RAN) Architecture Simple IP and Mobile IP Internet AccessSupport for multi-carrier RevB

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

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

401-614-323Issue 16 October 2009

2-51

Page 130: 1xev-Do Rf Engineering

Rev A Network Challenges

Overview

Purpose

This section covers issues associated with Rev-A networks.

Contents

IMS Core 2-53

Header compression 2-56

End-to-End 2-59

Delay budget 2-62

Radio Access Network (RAN) Architecture Rev A Network ChallengesOverview

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

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

2-52 401-614-323Issue 16 October 2009

Page 131: 1xev-Do Rf Engineering

IMS Core

Description

Except for the single-board EVM swap out/installation and software updates in the BTS

and R�C, no other changes are required for Rev A implementation on the Radio Access

�etwork (RA�). To meet the network challenges associated with transporting voice

packets over IP (VoIP) along with other multimedia features provided in Rev A, the Rev

A RA� software is designed primarily to interface with an IP Multimedia Sub-system

(IMS) core network (see Figure 2-12, “RA� Interface with an IMS Core” (p. 2-54)).

Fundamental to an IMS network is the Session Initiation Protocol (SIP) that allows the

inter-working between RA� and other IP systems based on implementation of common

signaling and bearer protocols. For example, in a VoIP call, the call control signaling is

removed from the bearer transport, providing more flexibility and freeing the bearer

packet overhead to quicken delivery.

Radio Access Network (RAN) Architecture Rev A Network ChallengesIMS Core

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

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

401-614-323Issue 16 October 2009

2-53

Page 132: 1xev-Do Rf Engineering

RAN Interface with an IMS Core diagram

Call/Session Control Function

All session connections through the IMS core are handled by the Call/Session Control

Function (CSCF), which is a collective name for different SIP servers that process

signaling packets within the IMS internal IP network. SIP is a standard signaling protocol

for enabling the integration of telephony and Internet services in a converged wireline,

wireless, and Internet network. For example, an SIP server may be a proxy server

(P-CSCF) providing the first point of contact for the IMS clients, authenticating the user

and establishing a security association. Another SIP server may provide

interrogating-CSCF (I-CSCF). The I-CSCF is positioned at the edge of an administrative

domain and its IP address is published on the D�S record for the domain. The I-CSCF

enables a P-CSCF from a visitor domain to find the server over the Internet and to use the

Figure 2-12 RAN Interface with an IMS Core

Packet DataServing Node(PDSN, A11)

RNC

RNC

Handoff

OMP FX/OMC RAN

(Element ManagementSystem)

(Element ManagementSystem)

AAA

AAA

Optional

1xEV-DO Rev A Network

1xEV-DO Rev A Network

IPBackhaul

IP Connectivity

OMP FX/OMC RAN

ApplicationServer

HomeSubscriber

System(HSS)

MediaGatewayControl

Function(MGCF)

MediaGateway(MGW)

Call/SessionControl Function

(CSCF)

IPNetwork

IPNetwork

PSTN

IMS Core Network

Radio Access Network (RAN) Architecture Rev A Network ChallengesIMS Core

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

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

2-54 401-614-323Issue 16 October 2009

Page 133: 1xev-Do Rf Engineering

I-CSCF for an entry point into the domain. Essentially, the CSCF is the central node of

the signaling plane and performs session control for all the data packets passing through

the IMS internal IP network that interfaces with the RA� as well as the public Internet.

When a new session is started, the CSCF consults the IMS subscriber profile data that is

provisioned on the Home Subscriber System (HSS). The HSS is the master user database

for the IMS core. Alcatel-Lucent's HSS product is operated on a Super Distributed HLR

(Home Location Register) platform, providing a superset of HLR functions. To provide a

highly available and reliable system, HSS data and control functions are distributed on

separate servers, where the subscriber data is stored across multiple data servers. The

combined HSS and HLR functionality provides the ability to better integrate subscriber

data when a user has a subscription in both the IMS and legacy networks. Both integrated

and standalone configurations are supported.

List of allowed applications

Each IMS subscriber is provisioned with a list of allowed applications. The interface for

these applications is provided by their respective application server. For VoIP, the

Alcatel-Lucent Telephony Application Server (FS-5000) will provide the mass market

and enterprise telephony features, such as:

• Call Forwarding, Call Transfer, Call Waiting, Call Pickup

• Conference Call (6 party max)

• Directed Call Park, and Directed Call Pickup

VoIP calls are handled by the Media Gateway Control Function (MGCF) via the Media

Gateway (MGW). The MGCF provides the SS7 interface with the PST� to control the

connectivity of VoIP packets between the IMS internal IP network and the PST� through

the MGW. The PST�, which is primarily a circuit-switched network, must be enhanced to

support IMS VoIP.

Radio Access Network (RAN) Architecture Rev A Network ChallengesIMS Core

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

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

401-614-323Issue 16 October 2009

2-55

Page 134: 1xev-Do Rf Engineering

Header compression

Description

Header compression and the enhanced multi-flow packet application (EM-FPA) will be

used in Rev A for VoIP transported over the air interface. In the initial VoIP offer, EVRC

coding will be used. The full rate voice frame, based on EVRC, is about 22 bytes; for

transport, an eight-frame payload (8 octets) is encapsulated. For real-time VoIP wireless

interactive voice conversations, Rev Awill be used Real-time Transport Protocol (RTP)

transmission. This protocol is an Internet protocol standard that specifies a way for

programs to manage the real-time transmission of multimedia data over either unicast or

multicast network services.

VoIP Transmission Without Header Compression

Because the RTP will use the UDP/IP protocols at Transport and Internet layers, in

addition to the 12-octet (96 bits) RTP header, a 20-octet IP (160 bits with IPv4) header

and an 8-octet (64 bit) UDP header (totaling 40 octets or 320 bits) are added to the EVRC

payload (see Figure 2-13, “VoIP Transmission Without Header Compression” (p. 2-57)).

This number will increase by one half from 40 octets to 60 octets, if IPv6 is used. A 32-bit

PPP header is then added at the Internet layer. In the IA-856A-A protocol stack, a 22-bit

RLP header and a 2-bit stream header are added at the Application and Stream layers.

Before the payload is sent down to the MAC layer, it pads the payload with 184-bits, and

finally a 2-bit MAC header and 30 physical header are added, resulting in a 3.35-to-1

header-to-payload ratio.

Radio Access Network (RAN) Architecture Rev A Network ChallengesHeader compression

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

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

2-56 401-614-323Issue 16 October 2009

Page 135: 1xev-Do Rf Engineering

RObust Header Compression (ROHC)

Although the RTP ensures consistent delivery order of voice packets in an IP network, it

cannot guarantee real-time operation. Due to the high header-to-payload ratio,

real-time-operation is less assured. Therefore, the RObust Header Compression (ROHC)

scheme is used to replace the RTP, IP, and UDP headers, as shown in Figure 2-14,

“RObust Header Compression (ROHC)” (p. 2-58).

Figure 2-13 VoIP Transmission Without Header Compression

EVRC

EVRC

EVRC

EVRC

EVRC

EVRC

EVRC

RTP/UDP/IP

RTP/UDP/IP

RTP/UDP/IP

RTP/UDP/IP

RTP/UDP/IP

RTP/UDP/IP

PPP

PPP

PPP

PPP

PPP

RLP

S

SPAD

PAD S

RLP

RLP

RLP

Payload

MAC

MAC

PHY

17632032222184230

ApplicationLayer

ApplicationLayer

SteamLayer

MACLayer

PhysicalLayer

1xEV-DO

Transport

Internet

Bits

~~

~~

~~~

~

~

Radio Access Network (RAN) Architecture Rev A Network ChallengesHeader compression

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

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

401-614-323Issue 16 October 2009

2-57

Page 136: 1xev-Do Rf Engineering

When the ROHC scheme is used along with the Enhanced Multi-Flow Packet Application

(EM-FPA) feature, the point-to-point protocol (PPP) can be eliminated, along with the

RTP, UDP, IP headers. These headers are replaced by a single 16-bit ROHC header. This

header will contain a 5-bit value to identify 31 different active Link Flows (only 4 are

supported at this time; a zero value indicates inactive flow). Because each Link Flow has

two routes for transmission and reception of payloads, a single route bit is used to identify

the route (only one route is used at this time). The First and Last identifies the first and

last packet.

Figure 2-14 RObust Header Compression (ROHC)

EVRC

EVRC

EVRC

EVRC

EVRC

EVRC

RLP

S

S

SPAD

PAD

RLP

RLP

RLP

Payload

MAC

MAC

PHY

1761614216230

ApplicationLayer

ApplicationLayer

SteamLayer

MACLayer

PhysicalLayer

1xEV-DO

Transport

Bits

ROHC

ROHC

ROHC

ROHC

ROHC

Discription Bits

LinkFlowID 5

Route 1

1

1First

Last

SEQ 6 for VoIP

ROHC with EM-FPA

~~

~~

~~

Radio Access Network (RAN) Architecture Rev A Network ChallengesHeader compression

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

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

2-58 401-614-323Issue 16 October 2009

Page 137: 1xev-Do Rf Engineering

End-to-End

End-to-End Protocol Stack for VoIP

The end-to-end protocol stack for VoIP with a mobile IP call to a land line is shown in

Figure 2-15, “End-to-End Protocol Stack for VoIP” (p. 2-59). Although ROCH

compression is required for the air interface, header compression/decompression is

performed at the PDS�. The Rev 0 point-to-point pipeline between the AT and the PDS�

is now replaced by the ROHC scheme. Another change that is worth noting is that the

Radio Link Protocol (RLP) is part of EM-FPA and is very different from the RLP used in

Rev 0.

Signaling using SIP

Signaling for the VoIP call is transfer using SIP as shown in Figure 2-16, “Signaling using

SIP” (p. 2-60).

Figure 2-15 End-to-End Protocol Stack for VoIP

UDPUDP

UDP UDP UDP

MAC

HDLC

PHY PHYPHY PHYPHY

MAC

PHY

RLP

IPIP

IPIPIP

EthernetEthernet EthernetEthernetEthernet

RLP

GRE GRE

IP IP

IPIP

Air IntrfaceBackhaul R-P A10/A11 IP Network

Laptop/AT BTS Router RouterRNC PDSN Internet

L2 L2 L2

L2

EVRC

RTP RTPRTP

IPIP

ROHC ROHC

L2L1 L1

IPsec IPsec

EVRC

IMS

UDPUDP

UDP UDP UDP

MAC

HDLC

PHY PHYPHY PHYPHY

MAC

PHY

RLP

IPIP

IPIPIP

EthernetEthernet EthernetEthernetEthernet

RLP

GRE GRE

IP IP

IPIP

Air IntrfaceBackhaul R-P A10/A11 IP Network

Laptop/AT BTS Router RouterRNC PDSN Internet

L2 L2 L2

L2

EVRC

RTP RTPRTP

IPIP

ROHC ROHC

L2L1 L1

IPsec IPsec

EVRC

IMS

Radio Access Network (RAN) Architecture Rev A Network ChallengesEnd-to-End

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

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

401-614-323Issue 16 October 2009

2-59

Page 138: 1xev-Do Rf Engineering

End-to-end delay guideline for VoIP

End-to-end delay for VoIP that meets user voice quality expectations is the primary

consideration in Rev A deployment. Delay requirements impose serious challenges to

system implementations. To provide the quality of circuit-switched voice without

degrading the system capacity, end-to-end QoS support in the wireless and wireline

packet network infrastructure is essential. RA� Quality of Service (QoS) support for

HRPD Rev A, FID 12078.9, which is an optional feature, provides a basic QoS

infrastructure for achieving the required QoS objectives.

In circuit-switched voice systems such as 3G-1X, the transmission delay is about fixed.

The voice quality is mainly determined by the packet error rate (PER), which ranges from

1% to 3%. The transmission delay for VoIP has fixed as well as variable components, of

which the latter can be traded off for spectral efficiency. Guidelines are needed regarding

tolerable delay and acceptable voice quality. Laboratory measurement indicates that the

voice transmission delay from mouth-to-ear needs to be limited within about 300 ms

before noticeable annoyance is experienced in interactive conversations. The acceptable

delay guideline has been studied and reported in ITU G.114 standard. Findings of this

Figure 2-16 Signaling using SIP

UDPUDP

UDPUDP

S-IP

PPPPPP

MAC L2 L2

PHY

MAC

PHY

RLP

IP IPL2

IPL2IP

IP

EthernetEthernet Physical Physical Physical Physical

Physical

Physical L11 L1

RLP GRE GRE

L2 L2

IP IP IP

Air IntrfaceBackhaul

R-P A10/A11

Laptop/AT Router Router PDSN Internet

L2 L2IP

SIPSIP

RNC

IMS

BTS

Radio Access Network (RAN) Architecture Rev A Network ChallengesEnd-to-End

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

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

2-60 401-614-323Issue 16 October 2009

Page 139: 1xev-Do Rf Engineering

standard are summarized in Figure 2-17, “End-to-End Delay Guideline for VoIP”

(p. 2-61). The minimum mouth-to-ear delay to achieve a satisfied response, in general,

needs to be kept within 285 ms.

End-to-End Delay Guideline for VoIP diagram

Speech frame delay estimates

Laboratory measurement indicates that the speech frame delay of the commercial 3G-1X

systems is about 130 ms for the forward or reverse link, whereas the mobile-to-mobile

delay is about 260 ms, which is well within the G.114 guideline. Because delay from

VoIP applications using a 1xEV-DO network is a random variable, the appropriate

guideline is not clear. At this time, limited laboratory measurement data is available to

indicate what delay requirement will be appropriate. For instance, it may be too tolerant if

the required mean delay is less than 285 ms, whereas it may be too strict if 99 percent of

the delay is less than 285 ms.

Figure 2-17 End-to-End Delay Guideline for VoIP

VerySatisfied

Satisfied

SomeUnsatisfied

ManyUnsatisfied

Nearly allUnsatisfied

Mouth to ear delay in ms

All customers aresatisfied if theend-to-end delayis less than 285 ms

0 100 200 300 400 500 600 700

50

60

70

80

90

100

E-modelrating R

Radio Access Network (RAN) Architecture Rev A Network ChallengesEnd-to-End

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

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

401-614-323Issue 16 October 2009

2-61

Page 140: 1xev-Do Rf Engineering

Delay budget

Introduction

Delay budget is summarized for VoIP over a Rev A network, assuming VoIP capacity

around 35 Erlangs per sector-carrier, for the following calls:

• Mobile-to-landline, Figure 2-18, “Mobile to Wireline End-to-End Delay Budget”

(p. 2-63)

• Landline-to-mobile, Figure 2-19, “Landline to Mobile End-to-End Delay Budget”

(p. 2-64)

• Mobile-to-mobile, Figure 2-20, “Mobile to Mobile End-to-End Delay Budget”

(p. 2-65)

The total end-to-end delay is viewed as a combination of fixed and controllable delays.

Fixed delays are introduced by standards and/or implementations of speech and channel

coding, interleaving, etc. Controllable delays are those determined by the network

topology and design choices made by the service and/or network providers. Examples are

jittering compensation buffering, IP network routing and transport delay. In a VoIP-based

system, the controllable delays can be minimized by having a well-engineered IP network

with adequate QoS control.

Definable criteria

Definable criteria, such as packet error rate (PER) and packet transmission delay, for the

VoIP network must be met to ensure the VoIP voice quality is comparable to that of a

circuit switched 3G-1X network. The analysis on this and the following two slides

assumes a 2% PER and that the packets that are delayed are less than 2%. A further

assumption is that the users that cannot meet the ultimate PER of 2% due to excessive

packet delay is less than 2%. Excessive packet delay is defined as delays exceeding 285

ms.

Although packets on the reverse link may require one to four sub-frames, early

termination is desired and three sub-frame transmissions rather than four, as allowed in

the TIA-856-A standard, is preferred. This is because three voice frames arrive every 60

ms from the EVRC source, and nine sub-frames available in the same time period on the

reverse link. If each packet is transmitted in three sub-frames, the three voice frames can

be transmitted in nine sub-frames, avoiding queuing delays.

Depending on the compression scheme context state, the encoded packet size required to

transmit a VoIP packet could vary; however a 256-bits will mostly be used. To minimize

the transmission delay by ensuring a high percentage of three-sub-frame early

terminations, the Traffic to Power ratio (T2P) is adjusted for a different encoded packet

size. By aggregating packets from all users in the system, it was observed in the

simulation that the probabilities that a packet completes in 1, 2, and 3 Sub-Frames are

0.35, 0.50, and 0.14 respectively.

Radio Access Network (RAN) Architecture Rev A Network ChallengesDelay budget

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

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

2-62 401-614-323Issue 16 October 2009

Page 141: 1xev-Do Rf Engineering

Mobile to Wireline End-to-End Delay Budget

In the forward link, 12 time slots occur every 20 ms. Based on Erlang B table, the

maximum number of users on a sector with a 35-Erlang capacity at 2% blocking is 45. At

a 35-Erlang capacity simulation shows that a 70-ms delay is experienced when an average

packing of four multi-user packets is transmitted in each time slot.

Both mobile-to-landline and wireline-to-mobile yield the same delay (about 185 ms); that

allows a 100-ms delay budget for the IP network (see Figure 2-19, “Landline to Mobile

End-to-End Delay Budget” (p. 2-64)).

Figure 2-18 Mobile to Wireline End-to-End Delay Budget

Air

Interface

Air

Interface

Base Station RNCBackhaul PDSN

35ms 10ms

IP

N etwork

IP

N etwork

MGWClass 5

Switch &Local Loop

25ms 10 ms

44

70ms 10ms 8ms 7ms

Total Delay =175* ms

Radio Access Network (RAN) Architecture Rev A Network ChallengesDelay budget

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

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

401-614-323Issue 16 October 2009

2-63

Page 142: 1xev-Do Rf Engineering

Landline to Mobile End-to-End Delay Budget

Mobile to Mobile End-to-End Delay Budget

For mobile-to-mobile communication, the total delay is estimated to be about 225 ms. A

credit of 20 ms is estimated in this case because the total air interface delay for forward

and reverse links can be modeled as the convolution of the two delays, which result in 20

ms less than the summation of the two delays. The delay budget for the IP network in this

case becomes 35 ms.

Figure 2-19 Landline to Mobile End-to-End Delay Budget

AirInterface

AirInterface

Base Station

RNC BackhaulPDSN

25ms

IPNetwork

IPNetwork

MGW

Class 5Switch &

Local Loop

44

70ms5ms

10ms35ms10 ms 7ms 8ms

Total Delay =170* ms

Radio Access Network (RAN) Architecture Rev A Network ChallengesDelay budget

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

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

2-64 401-614-323Issue 16 October 2009

Page 143: 1xev-Do Rf Engineering

Other delays

FID 13682.1 introduces UATI compression for dormant ATs. The affect on the delay

budget is considered negligible at less than half a millisecond. In addition, this feature

targets the least active ATs for compression in order to minimize the number of

uncompressions that have to be done.

Figure 2-20 Mobile to Mobile End-to-End Delay Budget

AirInterface

AirInterface

Base Station

Backhaul TrFO- 5ESS

25ms

IPNetwork

IPNetwork

44

40ms5ms

10ms35ms

10 ms

25ms

44

AirInterface

AirInterface

TrFO-5ESS Backhaul

Base Station

40ms 10ms

25ms

Total Delay =225* msAn average of 113ms per air link

Radio Access Network (RAN) Architecture Rev A Network ChallengesDelay budget

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

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

401-614-323Issue 16 October 2009

2-65

Page 144: 1xev-Do Rf Engineering

Session Transfer Between 1xEV-DO and 3G-1XSystems

Overview

Purpose

This section discusses the process of transferring a session between 1xEV-DO and 3G-1X

systems.

Contents

Hybrid Access Terminal (AT) 2-67

3G-1X Priority Over 1xEV-DO System 2-69

Access State 2-70

Maintenance of PPP Sessions 2-71

Location Update Protocol 2-72

Mobile IPAssignment 2-73

PPP Reconfiguration Trigger 2-74

Location Tracking Value 2-75

Location Update Protocol Procedure 2-76

Location Update Feature (FID 10696.1) 2-77

Handoffs 2-79

Location Update Service Measurement 2-82

Radio Access Network (RAN) Architecture Session Transfer Between 1xEV-DO and 3G-1X SystemsOverview

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

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

2-66 401-614-323Issue 16 October 2009

Page 145: 1xev-Do Rf Engineering

Hybrid Access Terminal (AT)

Description

A hybrid AT, which is a mobile unit with 1xEV-DO and 3G-1X capabilities, is capable of

session transfer between 1xEV-DO and 3G-1X systems. Because the air interface

between the two systems is very different, when the AT is moved in or between the RF

coverage areas of the two systems, the AT mobile must be in idle mode to perform the

session transfer. In idle mode, the AT is not currently uploading or downloading data from

the Internet site(s) being accessed, and its RF channel assignment is removed.

Hybrid AT State

The hybrid AT can be configured to register and receive pages in either the hybrid mode

(register on both systems), or in its most preferred (service provider) system only. When

the hybrid-mode preference is enabled the hybrid AT attempts to acquire both an IS-2000

and IA-856A systems, and maintains registration and overhead information on both

systems concurrently to provide service from both two systems.

When the hybrid mode preference is selected, the AT can operate using AMPS, CDMA,

and 1xEV-DO technologies. The technology used at any one time is a function of the RF

resources available at that time. For data transmission 1xEV-DO is preferred over

CDMA2000, providing that the 1xEV-DO signal strength is adequate. For voice

transmission, CDMA2000 is preferred over CDMA IS-95. When CDMARF resources

are unavailable, AMPS is used for voice calls. Upon power turn-on, the hybrid AT

sequences through 3G-1X and 1xEV-DO initialize states to acquire the 3G-1X and

1xEV-DO systems, respectively (seeFigure 2-21, “Hybrid AT State Diagram” (p. 2-68)).

When initially powered-up, the AT initializes on a 3G-1X system, and then looks for a

1xEV-DO system. Both searches are based on the preferences from a preferred roaming

list (PRL) stored in nonvolatile memory. After the AT performs 3G-1X initialization, it

goes into 3G-1X idle mode. In this mode, the hybrid AT will respond to a 3G-1X

message, call origination or page. If the AT is in an area that does not provide adequate

CDMA coverage, the AT can jump in and out of analog mode to service calls. To avoid

missing a page on the 3G-1X paging channel, the AT schedule attempts to acquire a

1xEV-DO system between paging slots on the 3G-1X system.

Radio Access Network (RAN) Architecture Session Transfer Between 1xEV-DO and 3G-1X SystemsHybrid Access Terminal (AT)

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

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

401-614-323Issue 16 October 2009

2-67

Page 146: 1xev-Do Rf Engineering

Hybrid AT State Diagram

Figure 2-21 Hybrid AT State Diagram

Radio Access Network (RAN) Architecture Session Transfer Between 1xEV-DO and 3G-1X SystemsHybrid Access Terminal (AT)

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

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

2-68 401-614-323Issue 16 October 2009

Page 147: 1xev-Do Rf Engineering

3G-1X Priority Over 1xEV-DO System

Description

Because voice communication is in real time, 3G-1X voice communication is given a

higher priority over 1xEV-DO data. If a 3G-1X call origination or page occurs while

acquiring a 1xEV-DO system, acquisition of the 1xEV-DO base station is suspended, the

AT jumps into the 3G-1X access state, and then waits for traffic channel assigned to

respond to the call origination or page. During this time, 1xEV-DO radio interface is not

available to acquire a 1xEV-DO base station. After responding to this action and

performing what is required, the AT continues to acquire an 1xEV-DO base station; then

the AT rests in the 3G-1X and 1x-EV-DO idle states.

Idle states

In the idle states, the AT performs slotted operation on both systems. To avoid collisions

in time between the 3G-1X paging channel slots and the 1xEV-DO control channel slots,

the AT determines a preferred 1xEV-DO control channel cycle offset that will not overlap

in time with the 3G-1X paging channel slot scheme that the AT is required to use. The

1xEV-DO preferred control channel cycle offset is negotiated between the AT and the

R�C in accordance with the IA-856A standard.

Voice call

If a voice call is originated or terminated, the AT leaves the slotted mode to acquire a

traffic channel on the 3G-1X/CDMA system. After the call is completed, the AT returns to

the idle modes. Any requests for 1xEV-DO service during the voice call would be

ignored.

If a connection request is received for 1xEV-DO service, dual-mode terminals would

establish the 1xEV-DO connection, and then periodically jump to the 3G-1X frequency to

check for pages in the assigned slots. During this time, the AT sends a zero-DRC value to

indicate that it does not want to receive data on the forward link and simply buffers the

reverse link data, similar to what it does when in a deep fade.

Radio Access Network (RAN) Architecture Session Transfer Between 1xEV-DO and 3G-1X Systems3G-1X Priority Over 1xEV-DO System

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

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

401-614-323Issue 16 October 2009

2-69

Page 148: 1xev-Do Rf Engineering

Access State

Description

When a message, call origination or page occur on either system, the AT enters the access

state for that system to connect service on the applicable traffic channel. The access state

is initially required whenever the AT sends data to the base station, where the distance

between the AT and the closest base station is indeterminate. The access state avoids the

generation of unnecessary RF interference in the environment by determining the

minimumAT power required to reach the base station. When either state is entered to

service either the 1xEV-DO or 3G-1X/CDMA system, RF resources are denied to the

other system. However, if a 3G-1X origination occurs while in the 1xEV-DO access state,

the AT goes into the 3G-1X access state to service the call origination. The AT resumes

1xEV-DO access state after the 3G-1X message is done. After the distance between the

AT and closest base station is determined, the AT acquires the appropriate traffic channel

to service the call.

Elimination conditions

The 1xEV-DO access mode may be eliminated when AT is aware of its distance from the

closes base station such as when the RA� sends a TrafficChannelAssignment message

based on the last RouteUpdate received from the AT. At this time, a Fast Connect signal is

generated, causing the AT to bypass the 1xEV-DO access state. When in the 1xEV-DO

traffic state, the AT periodically tunes to the 3G-1X frequency to receive the 3G-1X

paging channel slot and perform 3G-1X idle state procedures. If 3G-1X services are

required, the AT will jump to the 3G-1X access state to perform the service on the 3G-1X

traffic channel.

Radio Access Network (RAN) Architecture Session Transfer Between 1xEV-DO and 3G-1X SystemsAccess State

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

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

2-70 401-614-323Issue 16 October 2009

Page 149: 1xev-Do Rf Engineering

Maintenance of PPP Sessions

Description

During 1xEV-DO data transmission a point-to-point protocol (PPP) session (tunnel) is

maintained between the AT and the Internet site being accessed. When data transfer goes

dormant for a prescribed period, the AT RF channel assignment is removed and the AT

goes into the idle mode. Even though its RF channel assignment is removed, the R�C

maintains 1xEV-DO session parameters and the PDS� maintains PPP session

information. If the session parameters are not maintained, when the AT moves between

1x-EV-DO and 3G-1X coverage areas, service is interrupted and the AT must reestablish

new connections with the Internet site accessed subsequent to the 1x-EV-DO to 3G-1X,

or 3D-1X to 1xEV-DO system transfer. If the session parameters are maintained, after

system transfer and RF channel reassignment, the AT user may resume data

communication with the current Internet site as if the transfer had not occurred.

Session transfer between systems

The seamless session transfer between systems using different PDS�s is contingent that

the AT maintain the same IP address in both systems. Because the IP address is assigned

by the PDS�, transfer between 1xEV-DO and 3G-1X systems fall into two scenarios

where the R�C in each system uses either the same or different PDS�s. In the first

scenario, where the same PDS� is used, because the session PPP tunnels exist through a

common PDS�, the session transfer only occurs in the air interface (hard handoff from

one carrier to the other). However, for the second scenario, in addition to switching

carriers, the session PPP tunnels must be re-synchronized (reconfigured) from the source

(current) PDS� to the target (new) PDS�.

Radio Access Network (RAN) Architecture Session Transfer Between 1xEV-DO and 3G-1X SystemsMaintenance of PPP Sessions

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

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

401-614-323Issue 16 October 2009

2-71

Page 150: 1xev-Do Rf Engineering

Location Update Protocol

Description

�ote: The Location Update feature as provided in IA-856A and is not implement and

cannot be enabled at this time.

The following description is presented here to support the discussion of the hybrid AT.

When the Location Update feature is available, a location update procedure is performed

following successful AT authentication, and subsequently, each time a color code change

is detected by the AT, signaling an inter-PCF handoff. This is done to determine if the AT

is entering the domain of a different PDS�. The Location Update protocol, which is

optional and is implemented at the Application layer, is only applicable for mobile IP

(M-IP) registration. The purpose of this protocol is to determine when the PPP connection

servicing the AT through a PDS� must be reconfigured through another PDS�. This

protocol is performed each time the AT moves between service areas, as distinguished by

inter-PCF handoff (detection of different color codes). The inter-PCF handoff may, but do

not always, indicate PDS� border crossing between 3G-1X and 1xEV-DO technologies.

The Location Update protocol allows a potential target PDS� in the 1xEV-DO system to

determine if the AT in inter-PCF handoff is crossing its border.

Radio Access Network (RAN) Architecture Session Transfer Between 1xEV-DO and 3G-1X SystemsLocation Update Protocol

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

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

2-72 401-614-323Issue 16 October 2009

Page 151: 1xev-Do Rf Engineering

Mobile IP Assignment

S-IP

When an M-IP address is requested by the AT, the AT is assigned an IP address, which is

held by the AT for the duration of the call session. Unless the AT presents its own static IP

address or requests an M-IP address, the AT will be assigned a simple IP address (S-IP) by

the servicing PDS�. In contrast, when an S-IP address is used, the IP address assigned to

the AT is subject to change when the AT is moved from the domain of one PDS� to

another PDS�. This is because the S-IP is assigned by the servicing PDS� that acts as an

Internet gateway which, when an RF channel is assigned, provides the AT with a PPP

connection through the wireless service provider IP network to the Internet. If the AT

moves out of the PDS� domain, the PPP sessions establish through the PDS� is

interrupted and the AT user must re-establish the PPP session with another PDS�.

M-IP

When an M-IP address is requested, the PDS� advertises for a Home Agent that will

provide a dynamic or static IP address that the AT may use for the life of the data session.

Rather than using the PDS� as a gateway to the Internet, this task is relegated to the

Home Agent (HA) that will establish an M-IP tunnel connection for the AT traffic data

from the current PDS� to the Internet. At this time, the PDS� serves as a Foreign Agent

(FA) to the Home Agent.

Radio Access Network (RAN) Architecture Session Transfer Between 1xEV-DO and 3G-1X SystemsMobile IP Assignment

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

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

401-614-323Issue 16 October 2009

2-73

Page 152: 1xev-Do Rf Engineering

PPP Reconfiguration Trigger

Description

Even though its RF channel assignment is removed after the AT stops transmitting and

receiving Internet data, causing the AT to go into idle mode, the PPP session (tunnel) with

the Internet is still maintained from the R�C to the PDS�, and between the PDS� (FA)

and the Home Agent (HA). Each session exists as table entries and binding contexts in the

1xEV Controller, PDS�, Home Agent, and AAA Server. Each time, when in the idle

mode, the AT crosses the coverage border serviced through different PDS� servers, each

PPP tunnel between the HA and the FAs must be switched from the current PDS� to the

target PDS�. Two methods trigger this switch:

• Alternative Location �otification (AL�) - Used when Location Update protocol is not

supported. If the Location Update protocol is supported, AL� is only used to trigger

PPP session transfers from 1xEV-DO to 3G-1X systems. This method relies on the

idle-mode AT to initiate PPP reconfiguration when it detects a change in the R�C

coverage, which may or may not indicate a PDS� border.

• Unsolicited Location �otification Message (UL�M) - Except for PPP session

transfers from 1xEV-DO to 3G-1X systems, used when the Location Update protocol

is supported. Allows the potential source PDS� to determine if an AT has entered

over its border.

Difference between notification methods

The important difference between the two is that when the AL� method is used, a PPP

reconfiguration is triggered each and every time an idle inter-PFC handoff is detected

regardless of whether PPP reconfiguration is required or not. If reconfiguration is not

required, the system will perform a reconfiguration procedure to synchronize to the same

PPP connection, resulting in no PPP connection change. When the UL�M method is

used, PPP reconfiguration is triggered only when required. The UL�M method improves

system performance by limiting PPP reconfiguration to only when necessary.

Radio Access Network (RAN) Architecture Session Transfer Between 1xEV-DO and 3G-1X SystemsPPP Reconfiguration Trigger

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

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

2-74 401-614-323Issue 16 October 2009

Page 153: 1xev-Do Rf Engineering

Location Tracking Value

Access Node ID

The Location Update protocol tracks the ATs movement from one PDS� to another with

an Access �ode ID (A�ID) tracking value, which is stored in the PDS� for 3G-1X and

1xEV-DO systems. Initially the A�ID is the location designation of a group of cells

within PCF region in a PDS� (or group of PDS�s) domain where the PPP is first set up.

Subsequently the source locations involved in inter-PCF handoffs serve this purpose. The

A�ID is comprised of three values: the system ID (SID), packet zone ID (PZID), and

network ID (�ID).

Assignment of ANID values

�ote:When implementing the Location Update protocol, all the cells within the

domain of a PDS� should have the same unique A�ID value.

The assignment of A�ID values is chosen by individual wireless service provider's as a

function of its identification and coverage strategy. To achieve the maximum benefit of

the location update protocol all the cells within the domain of a PDS� should have the

same unique A�ID value.

Process

After the session is established, the PPP connection is negotiated, and the AT user is

authenticated, the R�C initiates the Location Update protocol by causing the base station

to transmit its serving sector A�ID within a LocationAssignment message. At this time,

the A�ID value identifies the cell group in which the original UATI request was received.

The A�ID is also sent to the PDS� and stored as a location record in association with the

AT and the established PPP connection. The A�ID value will remain unchanged in the

PDS� throughout the lifetime of the R-P (A11) session in the 1xEV-DO system. Should

the AT leave and subsequent return to the domain of a PDS� within the lifetime of its R-P

(A11) session, the same R-P (A11) session is used as if the AT has never left the PDS�

domain.

Radio Access Network (RAN) Architecture Session Transfer Between 1xEV-DO and 3G-1X SystemsLocation Tracking Value

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

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

401-614-323Issue 16 October 2009

2-75

Page 154: 1xev-Do Rf Engineering

Location Update Protocol Procedure

Initiating the Location Update protocol

When an AT crosses the technology border from 3G-1X to 1xEV-DO and an inter-PCF

handoff is performed, the Location Update protocol is initiated. At this time, the location

update protocol procedure determines if the AT is also entering the domain of a different

PDS�. If this is the case, PPP synchronization must be triggered to reconfigure the PPP

connection through the target PDS� that becomes the new foreign agent.

LocationNotification message

When going from 3G-1X to 1xEV-DO systems, the crossing of PDS� domains is

determined by comparing the A�ID value received from the AT in its Location�otifica-

tion message with the A�ID value stored in the PDS�. Actually two A�ID values are

received in the Location�otification message; one is the previous A�ID (PA�ID),

indicating the AT's previous location before inter-PCF handoff, and the other is the

current A�ID (CA�ID), indicating the PCF that is currently serving the AT.

Continue to service

If the PDS� can match the PA�ID with the stored A�ID value for the AT, this indicates a

PPP session already exists and that the PDS� can continue to service the AT through that

PPP connection. At this time, the PDS� replaces its stored A�ID value for the AT with

the CA�ID value extracted from the Location�otification message for subsequent use if

another inter-PCF handoff occurs. If the A�ID record for the AT is not stored by the

PDS�, a match cannot be obtained. In this case, the PDS� triggers PPP reconfiguration.

1xEV-DO A13Interface message

When an inter-PCF handoff occur within a 1xEV-DO system, rather than receiving the

A�ID values in a Location�otification message, these values are received via an

A13Interface message from the source PCF. The A�ID values received in the

A13Interface message are the same as those received in the Location�otification. Because

the AT is normally serviced by the same PDS� regardless where the AT is within a

contiguous 1xEV-DO system, the location values received in the A13Interface message

enable the PDS� to associate the AT with its establish PPP connection.

Transmit the ANID value

The R�C transmits its A�ID value to the AT within a LocationAssignment message. This

is done to ensure that if the AT moves to another R�C within the same PDS� domain an

A�ID/CA�ID match will be detected. To indicate that the LocationAssignment message

is received, the R�C waits for a LocationComplete acknowledgment from the AT.

Radio Access Network (RAN) Architecture Session Transfer Between 1xEV-DO and 3G-1X SystemsLocation Update Protocol Procedure

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

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

2-76 401-614-323Issue 16 October 2009

Page 155: 1xev-Do Rf Engineering

Location Update Feature (FID 10696.1)

Overview

The Location Update Feature (FID 10696.1) provides the SID/�ID/PZID information to

the AT in the Location Assignment message sent to the AT after a new session has been

established or after an Inter-PCF Idle handoff has been performed. This feature also

allows the AT to send unsolicited SID/�ID/PZID information to the A�.

Description

This feature is optional in IS-856 standard. When this feature is disabled, the trigger for

Mobile IP handoff will be done via the so-called “Alternative Location �otification”

method (pure mobile method), which is exclusively done by the AT, without explicit A�

involvement (besides setting the traffic channel for this AT). The AT will initiate a PPP

reconfiguration.

When this feature is enabled, the A� will negotiate the RA�Handoff attribute to 0x01

and send a Location Assignment message to the AT infoming the SID/�ID/PZID of this

system. The AT will store the SID/�ID/PZID received and may send an unsolicitated

Location �otification message in the following conditions:

• When the AT does an idle handoff from 1X to DO

• When the AT does a prior session transfer from one DO subnet to another DO subnet.

• When any attribute is re-negotiated.

It is possible that at the time a Location �otification is received, the A� does not have an

A10 connection for this AT. In this case, Call Processing should select a TP and PDS�

using the current selection algorithms to open an A10 connection. The PDS� will

determine (based on the SID/�ID/PZID information) if a PPP-re-sync is needed. If not,

the PDS� will just update its stored SID/�ID/PZID. If it is needed, the PDS� will initiate

a PPP re-sync by sending the Agent Advertisements to the mobile. (The A� must page the

AT and set up a traffic channel first.) The mobile may send a Mobile IP Registration

Request (RRQ) to the PDS� using the existing assigned IP address and the PDS� will

forward the MIP RRQ to the Home Agent. The Home Agent recognizes that AT has an IP

address and that session exists, so it will respond with Mobile IP RRP message asking the

AT to maintain the same IP address and session continues. AT has a new care-of-address,

and the IPsec tunnel is switched back to the DO PDS� and Home Agent.

Simple IP advantages

The advantage of LUP feature in Simple IP is that it helps the AT to be in synch with

PDS� by initiating a PPP re-synch whenever there is a mismatch between A�ID in AT

and stored A�ID in PDS� and helps the AT to be reachable regardless of the air

interfaces and helps A� to send data to AT when the AT moves from 3G1X to EVDO.

Radio Access Network (RAN) Architecture Session Transfer Between 1xEV-DO and 3G-1X SystemsLocation Update Feature (FID 10696.1)

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

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

401-614-323Issue 16 October 2009

2-77

Page 156: 1xev-Do Rf Engineering

Protocol initiation

The Location Update protocol is triggered when there is prior session handoff and 3G1X

to 1XEVDO handoff. The PDS� compares the A�ID value received from the AT in its

current Location�otification message with the CA�ID value previously stored by the

PDS�. If the two values match, the PPP connection does not require reconfiguration. If

they do not match, the target PDS� initiates PPP reconfiguration.

Performance advantage

The advantage of providing this feature rather than using the pure mobile method is

sometimes the pure mobile method may cause some unnecessary PPP resync and MIP

registration. For example, if the PDS� is the same during 1x to DO handoff or prior

session transfer, there is no need to perform the PPP re-synch.

• With LUP

– AT will send Location�otification to A� and A� will send A11 to PDS�.

– PDS� does not need to re-synch the PPP with AT by checking the PA�ID and

stored A�ID at PDS�

– This procedure can be done over air with access/control channel messages without

a connection.

• Without LUP

– AT will initiate PPP re-synch with PDS�

– Setup a connection

– Multiple A11 messages

Advantages of LUP for simple IP

For system using simple IP, LUP feature is required so data can be delivered to AT during

AT inter-technology handoff.

Without LUP, AT will not initiate any message when it moves from 1X to DO so next AT

terminated data call will fail.

With LUP, AT will send Location �otification message to DO when it moves from 1X to

DO and DO R�C will inform the PDS� with A11 RRQ message.

If the PDS� is shared by 1X and DO then PDS� will not initiate PPP re-synch and it will

forward data to DO when next AT terminated data arrives.

If the PDS� is different for 1X and DO then PDS� will initiate a PPP re-synch so later

AT terminated data can be delivered successfully.

Radio Access Network (RAN) Architecture Session Transfer Between 1xEV-DO and 3G-1X SystemsLocation Update Feature (FID 10696.1)

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

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

2-78 401-614-323Issue 16 October 2009

Page 157: 1xev-Do Rf Engineering

Handoffs

Inter-System Handoff

The mechanics of the locate update process is better understood with the aid of Figure

2-22, “Inter-System Handoff” (p. 2-79) that tracks the location of an AT as it moves

between the coverage areas of cells A and B, B and C, and C and A. If the AT, which is in

Cell A, requests a mobile IP to connect to the Internet, PDS�1 will look for a server

within the IP �etwork to operate as a home agent, providing the AT with a mobile IP

address. As a result, a PPP connection from PCF1 through PDS�1 to Home Agent HA1

and an M-IP tunnel from HA1 to the Internet are set up to connect the AT to the Internet.

For systems using mobile IP, LUP feature is used to optimize the inter-technology

handoff.

Without LUP, AT will always initiate PPP re-synch when it moves from 1X to DO. This

procedure involves setting up a connection in DO and many messages between R�C and

PDS�. It is not needed if the PDS� is shared by 1X and DO.

With LUP feature, AT will only send Location �otification on the access channel and

R�C will inform the PDS� through A11 RRQ message. If the PDS� is shared by PDS�

then no PPP re-synch will be performed. This will save resources for the whole system.

Figure 2-22 Inter-System Handoff

3G-1X BTS

1xEV-DO BTS

PacketControl

Function(PCF2)

PacketControl

Function(PCF3)

PacketControl

Function(PCF1)

1xEV-DO BTS

A

C

PacketData Service

Node(PDSN2)

PacketData Service

Node(PDSN1)

HomeAgent(HA1)

Internet

PDSN Border

BWirelessServiceProvider

IP Network

A13 Interface

Radio Access Network (RAN) Architecture Session Transfer Between 1xEV-DO and 3G-1X SystemsHandoffs

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

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

401-614-323Issue 16 October 2009

2-79

Page 158: 1xev-Do Rf Engineering

Inter-PCF Handoff Across PDSN from 3G-1X to 1xEV-DO Systems

If the AT should go back to Cell A, the locate update protocol is used to trigger PPP

reconfiguration. At this time, the PA�ID reported in the Location�otification message

will not match with the A�ID value stored in PDS�1, causing the PDS� to trigger PPP

reconfiguration. As a result, the M-IP tunnel connection from HA1 is switched back from

PDS�2 to PDS�1. Although the M-IP tunnel between HA1 and PDS�1 is torn down, the

A10/A11 connection between PCF1 and PDS�1 remains for a fixed lifetime. Therefore,

if the AT move back to Cell A, or any cell with the domain of PCF2 before the A10/A11

connection lifetime expiries, the same A10/A11 connection is used.

Idle Inter-PCF Handoff from 3G-1X to 1xEV-DO Systems within the same PDSN Border

After an Internet connection is established through a PDS�, the AT can move from cell to

cell within the PDS� coverage area without triggering PPP reconfiguration. This is true

regardless of whether the AT moves between 3G-1X and 1xEV-DO cells. When the AT

goes from Cell B to Cell C, an inter-PCF handoff will occur between PCF2 and PCF3. At

this time, the need for PPP reconfiguration is tested. Because PCF2 and PCF3 are

serviced through the same PDS�, the system does not need PPP reconfiguration. This is

true because the subsequent PA�ID/A�ID comparison performed in PDS� 2 results in a

match to avoid triggering PPP reconfiguration.

Idle Inter-PCF Handoff from 1xEV-DO to 1xEV-DO Systems over Different PDSN Borders

The last scenario to consider is an idle inter-PCF handoff from one 1xEV-DO cell to

another 1xEV-DO cell. This scenario is illustrated in Figure 2-22, “Inter-System Handoff”

(p. 2-79) when the AT is moved from Cell C back to Cell A. When an inter-PCF handoff

occurs between two 1xEV-DO cells, the same PDS� used before the handoff is used after

handoff. Rather than obtaining the AT's PA�ID and CA�ID values from it's

Location�otification message, PCF1 obtains this value via an A13interface message with

PCF3. Subsequently, the PA�ID value obtained through the A13interface message is sent

to PDS�2 for A�ID/PA�ID comparison. Because the PA�ID identifies the PDS�2

domain, a match is obtained. As a result, PPP reconfigure is not triggered and the PPP

session is maintained through from PDS�2.

Handoff between 1xEV-DO to 3G-1X Systems with a single PDSN configuration

Location Update Protocol is used only in 1X-EVDO and not in 3G1X systems. When an

AT moves from 1xEV-DO to 3G1X, in a mobile IP case, the AT triggers a PPP re-synch

through “Alternative Location �otification” method. See “Description” (p. 2-77) for more

information on “Alternative Location �otification”.

Radio Access Network (RAN) Architecture Session Transfer Between 1xEV-DO and 3G-1X SystemsHandoffs

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

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

2-80 401-614-323Issue 16 October 2009

Page 159: 1xev-Do Rf Engineering

When an AT moves from 3G1X to 1xEV-DO the following actions occur. This applies to

either Simple IP or Mobile IP.

• A� and AT configuration negotiation at 1xEV-DO R�C.

• The RA�Handoff attribute is negotiated to 1.

• The AT sends Location �otification to notify the previous access network it visited.

Receipt of the Location �otification triggers A11 RRQ to setup the A10 at 1xEV-DO. The

A�ID information from the location �otification is packed as PA�ID. The A�ID of the

sector where Connection Request was received from the AT is packed as CA�ID and

both are sent in A11 RRQ.

The PDS� then compares the PA�ID in A11 RRQ with its stored A�ID and any

mismatch causes the PDS� to initiate PPP re-synch.

AT

3G1XRNC

EVDORNC

PDSN

If PANID =stored ANID atPDSN, thenthere is noneed of PPPre-synch

PCF

PCF

A new A10 connection is setup after ANreceives Location Notification from AT andAN can reach AT through the A10connection built

AT sends LocationNotification

AT crosses 3G1X and1xEV-DO RNC

AT

Radio Access Network (RAN) Architecture Session Transfer Between 1xEV-DO and 3G-1X SystemsHandoffs

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

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

401-614-323Issue 16 October 2009

2-81

Page 160: 1xev-Do Rf Engineering

Location Update Service Measurement

Description

Six service measurements are pegged in association with the Location Update protocol

• LOC_�OTIFICATIO�_RCVD – This count shall be incremented for each Location

�otification message received from the AT on Access Channel.

• EVDO_SEC_CARR_HDRC_CE_10 – Pegged when Location Complete message

received on Accessl channel.

• EVDO_SEC_CARR_HDRC_CE_9 – Pegged when Location Assignment sent on

control channel

• EVDO_SEC_CARR_TP_HDRC_CE_6 – Pegged when Location �otification received

on Traffic channel

• LOC_ASSIG�MT_MSG_SE�T (CG SECT-CARR-HDRC) – Pegged when Location

Assignment message sent on traffic channel

• EVDO_SEC_CARR_TP_HDRC_CE_7 – pegged when location complete message on

traffic channel

Radio Access Network (RAN) Architecture Session Transfer Between 1xEV-DO and 3G-1X SystemsLocation Update Service Measurement

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

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

2-82 401-614-323Issue 16 October 2009

Page 161: 1xev-Do Rf Engineering

3 3Air Interface

Overview

Purpose

This chapter discusses the makeup and characteristics of the forward (downlink) and

reverse (uplink) channels. These 1xEV-DO characteristics, which are dictated by the

1xEV-DO Physical Layer protocol, vary as a function of channel type and information

data rate. The chapter will introduce the 1xEV-DO scheduling algorithm, which is one of

the main differentiating characteristic between 1xEV-DO systems and IS-95 and 3G-1X

systems.

Unlike IS-95 and 3G-1X, which allow more than one user to simultaneously share a

single carrier, the 1xEV-DO scheduling algorithm permits only one user on the carrier at

any one time. Although the transmission chip rate in 1xEV-DO is the same as in IS-95

and 3G-1X, a larger number of different forward link transmission data rates are offered

in 1xEV-DO. Slower data rates are use to ensure validity of transmission data when the

user is operating in a noisy RF environment. To increase the base station data throughput,

the scheduling algorithm will schedule access to those user devices that report favorable

RF conditions. Knowledge of the physical channel structure and the criteria used by the

scheduling algorithm are helpful in providing an overall understanding of the deployment

of base station cells.

Contents

Introduction to 1xEV-DOAir Interface 3-4

Peak Data Rates 3-5

1xEV-DO Channel Structure 3-6

Forward Link Channels 3-7

Time-Share Sub-Channels 3-8

Transmit Power 3-9

1xEV-DO Frame and Time Slot Structure 3-10

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

401-614-323Issue 16 October 2009

3-1

Page 162: 1xev-Do Rf Engineering

Forward Traffic Channel 3-12

Rev 0 Transmission Formats 3-13

Rev Amultiple transmission format 3-15

Modulation and code rate 3-19

Modulation Type 3-21

Bits Per Packet 3-24

Multi_User packets 3-27

Single User MAC Layer packets 3-29

Multiple User MAC Layer packets 3-32

MAC index 3-33

Preamble Data 3-34

Control and Pilot channels 3-36

Control Channel 3-37

Pilot Channel 3-39

MediumAccess Control (MAC) Channel 3-40

Data transmission factors 3-44

Incremental Redundancy 3-45

Packet Transmission termination 3-47

Dynamic Rate Control 3-49

Rev AData Source Control (DSC) Channel 3-51

Virtual Soft Handoff 3-54

Rev-0 Scheduling 3-56

Rev 0 Scheduling Algorithm 3-57

Flexible Scheduler (FID 8948.0) Feature 3-58

Minimum and Maximum Throughput Target Service Measurements 3-61

G-Fair and RandomActivity Factor 3-63

Rev A Scheduler Algorithm 3-64

Quality of service 3-65

Flows 3-66

Multi-user packet 3-68

Reverse Link Traffic Channel 3-70

Introduction 3-71

Rev 0 Reverse Link Channel 3-72

Air Interface Overview

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

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

3-2 401-614-323Issue 16 October 2009

Page 163: 1xev-Do Rf Engineering

Reverse Traffic Channel 3-74

Pilot/RRI and Ack channels 3-76

Data channel 3-77

Packet size and interleaver 3-79

Spreading 3-80

Reverse Link - Rev 0 limitations 3-81

Changes introduced in Rev A 3-83

Sub-frames 3-84

Reverse link incremental redundancy 3-87

Maximum 4 sub-frame duration 3-89

Reverse link payload size and modulation 3-90

Reverse link data rate selection 3-92

T2P Target Level Request and Grant 3-93

Reverse data rate selection 3-95

MAC subtype 3 3-96

Low-latency power boost transmission 3-97

Auxiliary Pilot channel 3-98

Rev 0 Access and Data channels 3-99

Rev A Enhanced Access Channel 3-101

Data rates and pilot channel 3-103

Test Application Feature 3-105

Introduction 3-106

Issuing commands 3-107

Commands 3-108

Air Interface Overview

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

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

401-614-323Issue 16 October 2009

3-3

Page 164: 1xev-Do Rf Engineering

Introduction to 1xEV-DO Air Interface

Overview

Purpose

This section provides an introduction to the 1xEV-DO air interface.

Contents

Peak Data Rates 3-5

1xEV-DO Channel Structure 3-6

Air Interface Introduction to 1xEV-DO Air InterfaceOverview

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

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

3-4 401-614-323Issue 16 October 2009

Page 165: 1xev-Do Rf Engineering

Peak Data Rates

Rev 0 Peak Data Rates

1xEV-DO is a high data rate air interface providing high speed, high capacity packet data

service for wireless users. This service employs the IP protocol (Internet Protocol) for

seamless data transfer over the Internet or any private IP network. Users access the

system with a hand-held Access Terminal (AT). Because experience with the Internet

indicates asymmetrical data flow, where downlink data flow is higher than uplink data

flow, downlink and uplink data flow between the AT and base transceiver station (base

station) are asymmetrical.

In Rev 0 the forward link data flow is much higher than reverse link data flow. The peak

data rates for Rev 0 are:

• 2, 457.6 Kbps, forward link (downlink)

• 153.6 Kbps, reverse link (uplink).

Rev A Peak Data Rates

Farther study in user experience show an increase need in reverse link data rates due to an

increase use of ftp and email transmission with large attachments. As a result, in Rev A

the gap between forward and reverse link data rates decreased with peak data rates of:

• 3,072.0 Kbps, forward link (downlink)

• 1,843.2 Kbps, reverse link (uplink).

Although a 1xEV-DO base station can be collocated with an IS-95 or a 3G-1X system,

1xEV-DO requires a separate CDMA carrier that cannot be used by either IS-95 or

3G-1X. This is because the 1xEV-DO air interface that defines the forward and reverse

link data traffic channels is not compatible with the IS-95 and 3G-1X forward and reverse

link data traffic channels.

Air Interface Introduction to 1xEV-DO Air InterfacePeak Data Rates

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

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

401-614-323Issue 16 October 2009

3-5

Page 166: 1xev-Do Rf Engineering

1xEV-DO Channel Structure

1xEV-DO Channel Structure diagram

The channel structure defined in the 1xEV-DO Physical Layer is shown in Figure 3-1,

“1xEV-DO Channel Structure” (p. 3-6). The following is an overall description of the

forward and reverse data link traffic channels as defined by the 1xEV-DO air interface. In

Rev A, an Automatic Repeat Request (ARQ) logical channel is added to the forward

MAC channel to support incremental redundancy in the reverse channel. In addition, a

Data Source Channel and an Auxiliary Pilot Channel is added to the reverse link channel.

Frame/Slot

Forward link data is transmitted in successive 26.67-ms frames, which are divided into

sixteen 1.667-ms slots in which packets of data are transmitted.

• The transmission duration of a single packet may vary from 1 to 16 slots as a function

of the data transmission rate.

• Pilot and control information are inserted (punctured) within each frame at fixed

intervals for AT extraction.

• The packet AT destination is specified within the packet.

• Upon receiving the packet, the AT transmits an acknowledge (ACK) signal, indicating

that the packet is received and its data is uncorrupted.

Figure 3-1 1xEV-DO Channel Structure

ForwardChannels

PilotMediumAccessControl

Traffic ControlChannel

TrafficChannel

ReverseChannels

AccessChannel

ReverseActivity

ReversePowerControl

PilotChannel

AuxiliaryPilot

Channel*

MediumAccessControl

DataChannel ACK

PilotChannel

DataChannel

ReverseRate

Indicator

DataRate

Control

1xEV-DOChannels

DRCLock

AutomaticRepeatRequest*

* Rev A only

Data SourceChannel*

Air Interface Introduction to 1xEV-DO Air Interface1xEV-DO Channel Structure

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

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

3-6 401-614-323Issue 16 October 2009

Page 167: 1xev-Do Rf Engineering

Forward Link Channels

Overview

Purpose

A single forward link channel, which is divided into four time-share sub-channels, is used

on each of the CDMA carrier designated for 1xEV-DO operation, which are:

• Data traffic

• Control Channel

• Pilot

• MediumAccess Control (MAC)

Contents

Time-Share Sub-Channels 3-8

Transmit Power 3-9

1xEV-DO Frame and Time Slot Structure 3-10

Air Interface Forward Link ChannelsOverview

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

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

401-614-323Issue 16 October 2009

3-7

Page 168: 1xev-Do Rf Engineering

Time-Share Sub-Channels

Data Channel Usage

In Rev 0, each active user is assigned one of 59 Walsh codes from a 64-ary set, where

four codes are pre-assigned. Due to the VoIP feature in Rev A, an increase in the number

user is expected. In anticipation of this increase the number of active users assigned to

Walsh codes is increased to 113 from a 128-ary set. Therefore, a single carrier can be

time-shared by 59 (113 in Rev A) active data traffic channel users. This means that

although at any one time, only one user is actively receiving data over the data traffic

channel, 59 (113) users are assigned logical channels on the carrier. A traffic channel

assignment indicates the air resources are assigned to the user. The actual number of

channels that can be assigned is determined aMaximum �umber of Users Supported on

the Service Nodes/General Instance Page - Section 2, which can be adjusted

between 0 and 59 (31). Considering that data transfer occurs for a small fraction of the

time during a typical web session, high volume users will pause for reading and think

time between downloading pages, causing the AT to enter in and out of a dormant mode

at which time the AT surrenders its channel assignment. Therefore, the number users that

can be served during busy hour periods may be greater thanMaximum �umber of Users

Supported value.

Air Interface Forward Link ChannelsTime-Share Sub-Channels

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

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

3-8 401-614-323Issue 16 October 2009

Page 169: 1xev-Do Rf Engineering

Transmit Power

Transmit Power

Because the data channel is time-shared, transmit power sharing is unnecessary as in

IS-95 and 3G-1X. Therefore, the base station can transmit traffic data at full power to

produce the highest carrier to noise (Eb/�o) ratio possible, allowing high data rate

transmission.

In contrast, the 3G-1X base station transmit power must be shared with the pilot, paging,

and sync channels as shown in Figure 3-2, “Comparison of 3G-1X and 1xEV-DO base

station Transmit Power Sharing” (p. 3-9). Although in 1xEV-DO data transmission is

time-shared with small bursts of MAC and pilot pulses, the total transmit power is

devoted to the traffic data for single users.

Comparison of 3G-1X and 1xEV-DO base station Transmit Power Sharing

Figure 3-2 Comparison of 3G-1X and 1xEV-DO base station Transmit Power Sharing

Pilot Channel

Paging Channel

Sync Channel

Traffic Channel

Total Data

Contr

ol C

hannel

Contr

ol C

hannel

3G-1X Forward Channel Structure

Time

1xEV-DO Forward Channel Structure

Time

TransmitPower

TransmitPower

MaximumPower

MaximumPower

Air Interface Forward Link ChannelsTransmit Power

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

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

401-614-323Issue 16 October 2009

3-9

Page 170: 1xev-Do Rf Engineering

1xEV-DO Frame and Time Slot Structure

Description

Forward data traffic channel is transmitted within 26.6-ms frames, as opposed to 20-ms

frames in IS-95. Each frame, which consists of 32,768 chips, is divided into 16 1.66-ms

2048-chip time slots as shown in Figure 3-3, “1xEV-DO Frame and Time Slot Structure”

(p. 3-10). The time slots are, in turn, divided into two 1024-chip half slots in which the

transmission of the traffic data, pilot pulses, and MAC channels are time-shared.

1xEV-DO Frame and Time Slot Structure graphic

Frame structure

The frame structure shown in Figure 3-3, “1xEV-DO Frame and Time Slot Structure”

(p. 3-10) represents an active time slot where traffic data is being transmitted to an AT

user. When no traffic or control data transmitted, an idle time slot is transmitted as shown

in Figure 3-4, “Idle Time Slot” (p. 3-11). Even though data is not transmitted during idle

time slots, the MAC and pilot channels are transmitted during their correct timing

sequence within the idle time slot. The forward MAC Channel is composed of up to 64

(128 in Rev A) code channels, which are orthogonally covered and BPSK-modulated on a

particular phase of the carrier. Each code channel is identified by a MAC index, which

Figure 3-3 1xEV-DO Frame and Time Slot Structure

Air Interface Forward Link Channels1xEV-DO Frame and Time Slot Structure

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

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

3-10 401-614-323Issue 16 October 2009

Page 171: 1xev-Do Rf Engineering

has a value of between 2 and 63 (127) and defines a unique 64-ary (128-ary) Walsh cover

and a unique modulation phase.The three sub-channels on the forward link MAC channel

are shown below:

1. Reverse Activity Channel (RAC),

2. DRC Lock

3. Reverse Power Control Channel (RPC).

In Rev A, a fourth sub-channel, Automatic Repeat Request, is added to the forward link

MAC channel.

Idle Time Slot

Figure 3-4 Idle Time Slot

Air Interface Forward Link Channels1xEV-DO Frame and Time Slot Structure

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

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

401-614-323Issue 16 October 2009

3-11

Page 172: 1xev-Do Rf Engineering

Forward Traffic Channel

Overview

Purpose

User data is transmitted in two 400-chip bursts during each half slot period on the forward

traffic channel (FTC). To maximize data throughput, AT users sharing the carrier are

serviced in any time slot order. Depending on the scheduler algorithm, AT users with

reporting a good RF environment will have a better chance to be allotted the time slot to

receive data. In Rev A, time slot allotment is also contingent on QoS and latency

considerations. Other AT users will have to wait until their RF environment improves. In

this way, the Rev 0 base station is always transmitting at the highest rate possible to

maximize its data throughput. In addition to maximizing throughput, the Rev A scheduler

algorithm is also sensitive latency intolerant data such as VoIP.

Contents

Rev 0 Transmission Formats 3-13

Rev Amultiple transmission format 3-15

Modulation and code rate 3-19

Modulation Type 3-21

Bits Per Packet 3-24

Multi_User packets 3-27

Single User MAC Layer packets 3-29

Multiple User MAC Layer packets 3-32

MAC index 3-33

Preamble Data 3-34

Air Interface Forward Traffic ChannelOverview

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

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

3-12 401-614-323Issue 16 October 2009

Page 173: 1xev-Do Rf Engineering

Rev 0 Transmission Formats

Description

The different data rate available in 1xEV-DO is achieved by varying the transmitted

signal modulation scheme via forward link adaptive modulation and other Physical Layer

characteristics, such as turbo code rate and preamble chips. Although the term

transmission format is introduced in Rev A, it also applies in Rev 0. In Rev 0, each DRC

value defines a specific data rate and transmission format in which the data is transmitted

to the AT. As shown in Table 3-1, “Rev 0 Transmission Formats” (p. 3-13), the

transmission format identifies the packet size in bits, the span, which is the maximum

number slots in which the packet is transmitted and preamble chip length. For example,

when complying with an AT requesting service at a transmission format specified by a

0x7 DRC value, the sector in which the DRC value is directed transmits forward link data

to the AT in 2048-bit packets at a 614-Kbps rate. The data in each packet, which is the

physical layer payload size, including CRC and tail bits, is preceded by a 64-chip

preamble and, barring early termination, is transmitted over a two-slot period. This

transmission format is designated in a triplet from identifying Packet Size (bits), Span

(slots), and Preamble (chips). Therefore, the transmission format for a DRC value of 0x7

is designated 2048, 2, 64.

Rev 0 Transmission Formats

Table 3-1 Rev 0 Transmission Formats

Characteristics

DRC Value 0x1 0x2 0x3 0x4 0x5 0x6 0x7 0x8 0x9 0xA 0xB 0xC

Data Rate (kbps) 38.4 76.8 154 307 307 614 614 922 1229 1229 1843 2458

Bits per Packets 1024 1024 1024 1024 2048 1024 2048 3072 2048 4096 3072 4096

Preamble Chips 1024 512 256 128 64 128 64 64 64 64 64 64

Span(Number of Slots) 16 8 4 2 4 1 2 2 1 2 1 1

Data Rate (kbps)

Air Interface Forward Traffic ChannelRev 0 Transmission Formats

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

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

401-614-323Issue 16 October 2009

3-13

Page 174: 1xev-Do Rf Engineering

Data rates

The data rates start at 38.4 kbps and double in value up to 2.457.6 kbps, and as in the case

for data rates 307.2 kbps, 614.4 kbps, and 1228.2 kbps, can be achieved through different

turbo code rates or modulation schemes.

As indicated previously, in Rev 0 the data rates used for a particular transmission are

determined by the current channel conditions experienced at the AT receiver. Each data

rate is associated with a particular packet bit size and modulation type.

Air Interface Forward Traffic ChannelRev 0 Transmission Formats

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

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

3-14 401-614-323Issue 16 October 2009

Page 175: 1xev-Do Rf Engineering

Rev A multiple transmission format

Multiple transmission format

One of the most profound differences between Rev 0 and Rev A is the introduction of the

multiple transmission format governed by the Enhanced Forward Traffic Channel MAC

Protocol. Multiple transmission formats refer to the variety of transmission formats that

the BTS may use, when responding to a single DRC. The transmission format is

represented by an ordered triplet of packet size (bits), span (slots) and preamble length

(chips).

Nominal Data Rate

The �ominal Data Rate of a transmission format may be computed by dividing the

Physical Layer packet size by the nominal transmit duration expressed in the maximum

number of slots over which the packet is transmitted. For example, the transmission

format represented by the ordered triplet (512, 4, 256) has a �ominal Data Rate of 76.8

kbps. Because the duration of one slot is 1.67 ms, to calculate this data rate, 512 is

divided 4 x 1.67 ms or 6.66 ms. Due to early termination, actual transmit duration of a

packet may be smaller than its �ominal Transmit Duration; as a result, the actual data rate

of a packet may be higher than its �ominal Data Rate.

DRCs and Rev A transmission formats

The Rev A transmission formats (Packet Size, Span, Preamble Chip Length) for DRC

values 0x0 through 0xe are shown in Table 3-2, “Rev A transmission formats” (p. 3-16).

Each DRC value is associated with a canonical single user transmission format, which is

shown in bold. For DRC values 0x1 through 0xC, the canonical format for a DRC is its

associated Rev 0 transmission format. Thus, the canonical format for DRC 0x7 is 2048, 2,

64. �on-canonical transmission formats associated with each DRC value are defined as

compatible transmission formats and are selected due to their compatibility with the

canonical format. With minor exceptions, this compatibility ensures that if the AT could

successfully decode canonical format, it would also be likely to successfully decode

packet data transmitted using any compatible non-canonical single-user or compatible

multi-user transmission formats. This exception applies to the multi-user transmission

formats for DRC values 0x0, 0x1 and 0x2, which are not used. The difference between a

single-user and multi-user transmission is discussed in the following paragraphs.

Air Interface Forward Traffic ChannelRev A multiple transmission format

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

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

401-614-323Issue 16 October 2009

3-15

Page 176: 1xev-Do Rf Engineering

Rev A transmission formats

Table 3-2 Rev A transmission formats

DRC

Index

Rate

Metric

(Kbps)

Span

Slots

List of Associated Single User

Transmission Formats

List of Associated Multi

User Transmission

Formats

0x0 0 16 (128, 16, 1024), (256, 16, 1024),

(512, 16, 1024), (1024, 16, 1024)

(128, 4, 256), (256, 4,

256), (512, 4, 256), (1024,

4, 256)

0x1 38.4 16 (128, 16, 1024), (256, 16, 1024),

(512, 16, 1024), (1024, 16, 1024)

(128, 4, 256), (256, 4,

256), (512, 4, 256), (1024,

4, 256)

0x2 76.8 8 128, 8, 512), (256, 8, 512), (512, 8,

512), (1024, 8, 512)

(128, 4, 256), (256, 4,

256), (512, 4, 256), (1024,

4, 256)

0x3 153.6 4 (128, 4, 256), (256, 4, 256), (512, 4,

256), (1024, 4, 256)

(128, 4, 256), (256, 4,

256), (512, 4, 256), (1024,

4, 256)

0x 307.2 2 ((128, 2, 128), (256, 2, 128), (512, 2,

128), (1024, 2, 128)

(128, 4, 256), (256, 4,

256), (512, 4, 256), (1024,

4, 256)

0x5 307.2 4 (512, 4, 128), (1024, 4, 128), (2048,

4, 128)

(128, 4, 256), (256, 4,

256), (512, 4, 256), (1024,

4, 256),

(2048, 4, 128)

0x6 614.4 1 (128, 1, 64), (256, 1, 64), (512, 1,

64), (1024, 1, 64)

(128, 4, 256), (256, 4,

256), (512, 4, 256), (1024,

4, 256)

0x7 614.4 2 (512, 2, 64), (1024, 2, 64), (2048, 2,

64)

(128, 4, 256), (256, 4,

256), (512, 4, 256), (1024,

4, 256), (2048, 4, 128),

(3072, 2, 64)

0x8 921.6 2 (1024, 2, 64), (3072, 2, 64) (128, 4, 256), (256, 4,

256), (512, 4, 256), (1024,

4, 256), (2048, 4, 128),

(3072, 2, 64)

0x9 1228.8 1 (512, 1, 64), (1024, 1, 64), (2048, 1,

64)

128, 4, 256), (256, 4, 256),

(512, 4, 256), (1024, 4,

256), (2048, 4, 128)

Air Interface Forward Traffic ChannelRev A multiple transmission format

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

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

3-16 401-614-323Issue 16 October 2009

Page 177: 1xev-Do Rf Engineering

Table 3-2 Rev A transmission formats (continued)

DRC

Index

Rate

Metric

(Kbps)

Span

Slots

List of Associated Single User

Transmission Formats

List of Associated Multi

User Transmission

Formats

0xA 1228.8 2 (4096, 2, 64) (128, 4, 256), (256, 4,

256), (512, 4, 256), (1024,

4, 256), (2048, 4, 128),

(3072, 2, 64), (4096, 2, 64)

0xB 1843.2 1 (1024, 1, 64), (3072, 1, 64) (128, 4, 256), (256, 4,

256), (512, 4, 256), (1024,

4, 256), (2048, 4, 128),

(3072, 2, 64)

0xC 2457.6 1 (4096, 1, 64) (128, 4, 256), (256, 4,

256), (512, 4, 256), (1024,

4, 256), (2048, 4, 128),

(3072, 2, 64), (4096, 2, 64)

0xD 1536 2 (5120, 2, 64) (128, 4, 256), (256, 4,

256), (512, 4, 256), (1024,

4, 256), (2048, 4, 128),

(3072, 2, 64), (4096, 2,

64), (5120, 2, 64)

0xe 3072 1 (5120, 1, 64) (128, 4, 256), (256, 4,

256), (512, 4, 256), (1024,

4, 256), (2048, 4, 128),

(3072, 2, 64),64), (5120, 2,

64)

Schedulers

Multi-user transmission formats are used for multi-user packets where data for one or

more users is transmitted in a single packet. Except for multi-user transmission formats

for DRC values 0x0, 0x1 and 0x2 compatibles, the span values for the compatible for

every DRC value is equal to or greater than its canonical format. Because the four-slot

span of the multi-user transmission formats for the first three DRC values are one quarter

of the 16-slot canonical format, the reliability of the transmitted data is downgraded. For

this reason, the scheduler does not use the multi-user transmission formats for DRC

values 0x0, 0x1 and 0x2.

In Rev 0, ATs use the DRC index (value and cover) to request a data rate from a specific

sector. Upon receiving the request, a sector's scheduler serves the AT at the specified data

rate and format. Amajor change with respect to this was introduced in Rev A. Instead of

Air Interface Forward Traffic ChannelRev A multiple transmission format

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

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

401-614-323Issue 16 October 2009

3-17

Page 178: 1xev-Do Rf Engineering

one to one relationship between the DRC and a single rate, the DRC Index maps to a

group of transmission formats which could be send to the AT. The AT determines the

packet transmission format from the preamble and MAC header information.

The Rev A scheduler has much more flexibility, it can serve the AT on any of the single

user transmission formats or it can decide to pack different users with "compatible" DRC

indexes into a single MAC layer packet.

If multiple DRC requests are bundled into a multi-user packet, special preambles (MAC

Index) lets the AT know a multi-user packet is coming.

Air Interface Forward Traffic ChannelRev A multiple transmission format

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

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

3-18 401-614-323Issue 16 October 2009

Page 179: 1xev-Do Rf Engineering

Modulation and code rate

Description

The modulation and code rate for each transmission format is shown in Table 3-3,

“Transmission Format Code Rate and Transmission Type” (p. 3-19). Rev A uses a more

robust turbo coder than Rev 0. Except for the higher transmission rates starting with 614.4

kbps, a 1 to 5 coding rate is used. The 1 to 5 code rate factor (R) identifies the ratio of the

number of information bits to the total number of information bits plus overhead

correction bits transmitted. An R = 1/5 factor indicates that for every one information bit

transmitted, four correction bits are transmitted to greatly improve the accuracy of the

information being received.

Transmission Format Code Rate and Transmission Type

Table 3-3 Transmission Format Code Rate and Transmission Type

Transmission

Format*

Code Rate Modulation Type Nominal Data Rate

(Kbps)

(128,16,1024) 1/5 QPSK 4.8

(128,8,512) 1/5 QPSK 9.6

(128,4,1024) 1/5 QPSK 19.2

(128,4,256) 1/5 QPSK 19.2

(128,2,128) 1/5 QPSK 38.4

(128,1,64) 1/5 QPSK 76.8

(256,16,1024) 1/5 QPSK 9.6

(256,8,512) 1/5 QPSK 19.2

(256,4,1024) 1/5 QPSK 38.4

(256,4,256) 1/5 QPSK 38.4

(256,2,128) 1/5 QPSK 76.8

(256,1,64) 1/5 QPSK 153.6

(512,16,1024) 1/5 QPSK 19.2

(512,8,512) 1/5 QPSK 38.4

(512,4,1024) 1/5 QPSK 76.8

(512,4,128) 1/5 QPSK 76.8

(512,4,256) 1/5 QPSK 76.8

(512,2,128) 1/5 QPSK 153.6

(512,2,64) 1/5 QPSK 153.6

Air Interface Forward Traffic ChannelModulation and code rate

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

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

401-614-323Issue 16 October 2009

3-19

Page 180: 1xev-Do Rf Engineering

Table 3-3 Transmission Format Code Rate and Transmission Type (continued)

Transmission

Format*

Code Rate Modulation Type Nominal Data Rate

(Kbps)

(512,1,64) 1/5 QPSK 307.2

(1024,16,1024) 1/5 QPSK 38.4

(1024,8,512) 1/5 QPSK 76.8

(1024,4,128) 1/5 QPSK 153.6

(1024,4,256) 1/5 QPSK 153.6

(1024,2,128) 1/5 QPSK 307.2

(1024,2,64) 1/5 QPSK 307.2

(1024,1,64) 1/3 QPSK 614.4

(2048,4,128) 1/3 QPSK 307.2

(2048,2,64) 1/3 QPSK 614.4

(2048,1,64) 1/3 QPSK 1,228.8

(3072,2,64) 1/3 8-PSK 921.6

(3072,1,64) 1/3 8-PSK 1,843.2

(4096,2,64) 1/3 16-QAM 1,228.8

(4096,1,64) 1/3 16-QAM 2,457.6

(5120,2,64) 1/3 16-QAM 1,536.0

(5120,1,64) 1/3 16-QAM 3,072.0

Notes:

1. �ormal text is Rev A only.

2. Italic text items are rates for Rev A and Rev 0.

Air Interface Forward Traffic ChannelModulation and code rate

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

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

3-20 401-614-323Issue 16 October 2009

Page 181: 1xev-Do Rf Engineering

Modulation Type

Quadrature Phase Shift Keying (QPSK) Constellation

With the exception of 921.6 kbps, rates from 38.4 kbps through 1,228.8 kbps are achieved

through quadrature phase shift keying (QPSK) modulation, where transmitted data bits

are distinguished by 90-degree phase separation as opposed to binary phase shift keying

(BPSK) used in IS-95, where transmitted data bits are distinguished by 180-degree phase

separation. The 180-degree phase separation in BPSK in a 360-degree cycle will yield

two states, representing a "0" or "1" bit value. The 90-degree phase separation in QPSK in

a 360-degree cycle will yield four states, representing 00, 01, 10, and 11 2-bit values;

thus, producing a 2-bit symbol per cycle. This modulation scheme can be illustrated by

the constellation drawing shown in Figure 3-5, “Quadrature Phase Shift Keying (QPSK)

Constellation” (p. 3-21). The four points on this drawing are obtained by resolving the (I)

in-phase and quadrature-phase (Q) components.

Figure 3-5 Quadrature Phase Shift Keying (QPSK) Constellation

Air Interface Forward Traffic ChannelModulation Type

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

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

401-614-323Issue 16 October 2009

3-21

Page 182: 1xev-Do Rf Engineering

Phase Shift Keying (8PSK) Constellation

The data rates at 921.6 kbps and 1,843.2 kbps are achieved through 8 PSK, which

produces a 3-bit symbol per cycle. This is done in a manner similar to QPSK. In this case,

the 8 PSK modulation scheme distinguishes 3-bit symbols by 45-degree phase separation

to yield eight states, representing 000, 001, 010, 011, 100, 101, 110, and 111. This

modulation scheme can be illustrated by the constellation drawing shown in Figure 3-6,

“8 Phase Shift Keying (8PSK) Constellation” (p. 3-22). The eight points on this drawing

are obtained by resolving the (I) in-phase and quadrature-phase (Q) components.

Quadrature Amplitude Modulation (16QAM) Constellation

Data rates at 1,228.8 kbps and 2,457.6 kbps are achieved through 16 quadrature phase

shift/amplitude modulation (16-QAM) to produce a 4-bit symbol per cycle.The 16-QAM

modulation scheme uses a combination of QPSK, yielding a 2-bit value and amplitude

modulation, and also yielding a 2-bit value where the combination of both results in a

4-bit symbol. This modulation scheme can be illustrated by the constellation drawing

shown in Figure 3-7, “16 Quadrature Amplitude Modulation (16QAM) Constellation”

(p. 3-23). The 16 points on this drawing are obtained by resolving the (I) in-phase and

quadrature-phase (Q) components.

Figure 3-6 8 Phase Shift Keying (8PSK) Constellation

Air Interface Forward Traffic ChannelModulation Type

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

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

3-22 401-614-323Issue 16 October 2009

Page 183: 1xev-Do Rf Engineering

Figure 3-7 16 Quadrature Amplitude Modulation (16QAM) Constellation

Air Interface Forward Traffic ChannelModulation Type

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

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

401-614-323Issue 16 October 2009

3-23

Page 184: 1xev-Do Rf Engineering

Bits Per Packet

Rev 0 Bit size

The bit size of the transmitted traffic data channel packets is a function of the selected

rate and varies from 1024 (1K) bits to 4096 (4K) bits, as indicated in Table 3-3,

“Transmission Format Code Rate and Transmission Type” (p. 3-19). The bit size of the

traffic data channel packets received from the MAC Layer is fixed at 1002 bits, as shown

in Figure 3-8, “Traffic Data Channel Physical Layer Packet Bit Size” (p. 3-25).

Regardless of the size of the packet to be transmitted, a Frame Check Sequence (FCS) is

performed on the 1002-bit packets received from the MAC layer. The FCS is a cyclic

redundancy (CRC), which is a calculation producing a 16-bit value which is a function of

the distribution of all the "1" bits in the 1002-bit MAC Layer packet. When a 1024-bit

packet is to be transmitted, the 16-bit CRC value is concatenated with the 1002-bit MAC

Layer packet and a 6-bit tail to form the 1024-bit Physical Layer packet. The six bits that

provide the packet tail are tacked to the very end of the Physical Layer packet, and are

always 0-bit values.

CRC Calculation

The AT receiving the packet will perform its own CRC calculation on the 1002-bit MAC

Layer value to validate the correctness of the transmitted Physical Layer packet. If the

16-bit CRC value computed by the AT matches the 16-bit CRC value transmitted in the

Physical Layer packet, the packet received by the AT is probably uncorrupted.

Traffic Data Channel Physical Layer Packet Bit Size

When a 2048-bit, 3072-bit, or 4096-bit packet is transmitted, the 2, 3, or 4 MAC Layer

packets are concatenated together to form a single Physical Layer packet. A single FCS is

calculated regardless of the number of MAC Layer packets encapsulated in the Physical

Layer packet, resulting in one 16-bit CRC value which is tacked onto the end of the

Physical Layer packet, just before the 6 tail bits. To fill the Physical Layer packet to its

appropriate 2K, 3K, and 4K bit sizes, 22-bit padding (pad) is inserted after the 1002-bit

MAC Layer packets, as shown in Figure 3-8, “Traffic Data Channel Physical Layer

Packet Bit Size” (p. 3-25). The 22 bit pad bits are encoded as "0" bits, which are ignored

by the AT.

Air Interface Forward Traffic ChannelBits Per Packet

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

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

3-24 401-614-323Issue 16 October 2009

Page 185: 1xev-Do Rf Engineering

Rev A Bit Packing

In Rev A, the multiple transmission format variety option provides the R�C greater

flexibility in scheduling forward link data flow. This flexibility allows the R�C to

maximize air interface capacity by responding to the DRC requested by the AT with a

number of different transmission formats. Using its knowledge of the type and size of the

data to be transferred, the AT's QoS requirements, data flow and activities required by

other users in the sector, the R�C selects the transmission format that maximizes sector

throughput. In Rev 0, the AT chooses the transmission format and thus the data rate.

Therefore, the AT knows how to detect and process its expected forward link data flow. It

will be shown in the following paragraphs that in Rev A, the R�C may respond to a

single DRC with one of a number of different transmission formats that are compatible

Figure 3-8 Traffic Data Channel Physical Layer Packet Bit Size

Air Interface Forward Traffic ChannelBits Per Packet

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

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

401-614-323Issue 16 October 2009

3-25

Page 186: 1xev-Do Rf Engineering

with the AT's requested DRC. The compatible formats may vary in packet size, span, and

preamble length. Therefore, the AT, not knowing exactly how to detect and process its

expected forward link data, is required to process its forward link data using a number of

transmission formats until the correct transmission format is detected.

Air Interface Forward Traffic ChannelBits Per Packet

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

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

3-26 401-614-323Issue 16 October 2009

Page 187: 1xev-Do Rf Engineering

Multi_User packets

Packet Division Multiplexing

Packet Division Multiplexing is another technique that is used in Rev A to increase air

capacity and reduce system latency for time-sensitive applications. With this technique,

the forward-link data for up to eight users may be combined into a single Physical Layer

packet that is transmitted over the air interface. The decision to combine the upper layer

packets for a number of users into a single Physical layer packet is based on the packet

size, type of packet, and user requested data rate (DRC). Each DRC is mapped to more

than one transmission format at the MAC layer. This mapping allows the scheduler to

chose a data rate (DRC) to ensure that every user AT addressed in the MUP packet is able

to read its data package. When the AT is receiving forward link data that may be

combined within MUP packets, not only must the AT process the preamble data using its

DRC requested transmission format, but must also parallel process the data for all MUP

transmission formats compatible with the AT DRC request. This parallel processing

requires more AT processing power and causes more battery drain.

Forward link multi-user packet reduces latency and improves radio link efficiency, which

is especially useful for VoIP, where voice data parcels are small. The key benefit of

multiple transmission formats is that smaller data parcels allow more redundancy through

better coding rates and a higher repetition rate. In most cases, this allows for early

termination to achieve higher data rates. Voice data for up to eight users may be packaged

in a single physical layer packet. Rather than transmitting eight packets, a single packet is

transmitted.

Forward Channel Data Rate

Because at any one time the R�C responds to a DRC with one of a number of different

compatible transmission formats, unlike Rev 0, no one-to-one relationship exists in Rev A

between DRC and data rate. Table 3-4, “Forward Channel data rate - bit size vs slot

Air Interface Forward Traffic ChannelMulti_User packets

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

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

401-614-323Issue 16 October 2009

3-27

Page 188: 1xev-Do Rf Engineering

duration” (p. 3-28) shows the different rates supported for the forward link as a function

of the transmission format packet size and span. The data rate shown in italics are for

MUP transmission formats.

Table 3-4 Forward Channel data rate - bit size vs slot duration

Packet Size

128 bits 4.8kbps 9.6kbps 19.2kbps 38.4kbps 76.8kbps

256 bits 9.6kbps 19.2kbps 38.4kbps 76.8kbps 153.6kbps

512 bits 19.2kbps 38.4kbps 76.8kbps 153.6kbps 307.2kbps

1024 bits 38.4kbps 76.8kbps 153.6kbps 307.2kbps 614.4kbps

2048 bits 307.2kbps 614.4kbps 1228.8kbps

3072 bits 921.6kbps 1843.2kbps

4096 bits 1228.8kbps 2457.6kbps

5120 bits 1536.0kbps 3072.0kps

16-slot 8-slot 4-slot 2-slot 1-slot

Air Interface Forward Traffic ChannelMulti_User packets

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

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

3-28 401-614-323Issue 16 October 2009

Page 189: 1xev-Do Rf Engineering

Single User MAC Layer packets

Introduction

Three types of MAC Layer packets are defined by the Enhanced Forward Traffic Channel

MAC protocol:

• Single User Simplex

• Single User Multiplex

• Multi-User

Description

Single User Simplex packets and Single User Multiplex packets are collectively referred

to as Single User packets and are shown in Figure 3-9, “Single User MAC Layer packets”

(p. 3-30). A Single User Simplex MAC Layer packet is used to carry one Security Layer

packet in its payload and is addressed to one AT.

The Single User Simplex MAC Layer packet consists of a single Security Layer packet

payload followed by a 2-bit trailer. The trailer value provides two functions: first, it

identifies the MAC Layer packet as a Single User Simplex packet; second, it identifies

the format of the packet payload in terms of the number of Connection Layer packets that

are embedded in the Security Layer packet. The value 01 identifies Format A, which

indicates that a single Connection Layer packet is embedded in the Security Layer packet

payload. The value 11 identifies Format B, indicating that two Connection Layer packets

are embedded in the Security Layer packet payload.

Air Interface Forward Traffic ChannelSingle User MAC Layer packets

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

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

401-614-323Issue 16 October 2009

3-29

Page 190: 1xev-Do Rf Engineering

Single User MAC Layer packets diagram

Figure 3-9 Single User MAC Layer packets

Single User Simplex packets

Single User Multiplex packets

Trailer

Trailer

2-bit trailer

2-bit trailer

MAC Payload

MAC Payload

One single Security Layer Packet

n Security Layer packets addressed to single AT

PadMACLayer

Heading

01 or 11

10where n = 1, 2, ......

m octalswhere m = n

or n + 1

98, 226, 482, 994, 2018, 3042, 4066, or 5090 bits

12, 28, 60, 124, 252, 380, 508, or 636 octets

98, 226, 482, 994, 2018, 3042, 4066, or 5090 bits

12, 28, 60, 124, 252, 380, 508, or 636 octets

Air Interface Forward Traffic ChannelSingle User MAC Layer packets

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

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

3-30 401-614-323Issue 16 October 2009

Page 191: 1xev-Do Rf Engineering

Difference between the two types

The difference between the two types of Single User packets is that the payload of the

Single User Multiplex packet may contain one or more Security Layer packets. The bit

length in 8-bit octets of each Security Layer packet in the payload is identified by an octet

in the MAC Layer header. The sequence of the octets in the header follows the field

sequence of their corresponding Security Layer packets in the payload. Thus, the value of

the first octet in the header indicates the octet length of the first Security Layer packet in

the payload. Therefore, the number of embedded Security Layer packets, "n," is equal to

the number of octet occurrences in the header. This number is equal to "m," where m = n

or m = n + 1. When m = n +1, the mth octet occurrence in the header equals zero.

If necessary, the Pad field is filled with 0 bit values to expand the overall packet length to

fit one of the eight packet bit field lengths shown. Lastly, the 2-bit trailer identifies the

MAC Layer packet as a Single User Multiplex packet where the Security Layer packets

conform with Format A.

Air Interface Forward Traffic ChannelSingle User MAC Layer packets

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

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

401-614-323Issue 16 October 2009

3-31

Page 192: 1xev-Do Rf Engineering

Multiple User MAC Layer packets

Description

User data for up to eight users may be packed in a single Multi-User packet (MUP). Each

user is identified by its assigned 7-bit MAC Index value, which occupies the least

significant bit positions of an 8-bit PackInfo field (see Figure 3-10, “Multiple User MAC

Layer packets” (p. 3-32)). The most significant bit (MSB) position of this field is the

format bit, indicating Format A, when 1, and Format B, when 0. The number of

PacketInfo fields transmitted in the MAC Layer Header, "m" is a function of the number

of users, "n", addressed in the packet, where m = n or n +1. If n equals 8, m is set to equal

n; otherwise m is set to equal n+1, and the mth packet Info field equals zero. The octet

sizes of the Security Layer packets assigned to each user are indicated by the field length

values in the Field length segment. The sequence in which these values appear

corresponds to the sequence in which their associated PacketInfor field appears in the

MAC header. Similarly, the Security Layer packet for each user appears in the MAC

payload in the same sequence.

Multiple User MAC Layer packets diagram

If necessary, the Pad field is filled with 0 bit values to expand the overall packet length to

fit one of the eight packet bit field lengths shown. Lastly, the 2-bit trailer identifies the

MAC Layer packet as a multi-user packet.

Figure 3-10 Multiple User MAC Layer packets

Trailer

2-bittrailer

MAC Payload

n Security Layer packets addressed to n ATs

Pad

MAC Layer Header

00where n = 1, 2, .....8

m octats

m PacketInfo Fieldswhere m = n or n + 1

and 2 m 8

PacketInfo Fields

Format MACIndex

n Field lengths

1 bit 7 bitsField length = Length of each Security Layer packet in octats

98, 226, 482, 994, 2018, 3042, 4066, or 5090 bits

12, 28, 60, 124, 252, 380, 508, or 636 octets

Air Interface Forward Traffic ChannelMultiple User MAC Layer packets

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

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

3-32 401-614-323Issue 16 October 2009

Page 193: 1xev-Do Rf Engineering

MAC index

Description

When the AT is assigned a traffic channel, the system assigns a MAC index for Walsh

code spreading of the MAC and control/traffic channels. In Rev A, the MAC index values

are extended MAC bi-orthogonal code. In Rev 0, 32-ary bi-orthogonal code is used for 64

MAC indexes. A 64-ary bi-orthogonal code is used in Rev A, extending the MAC index

to 128. The use of the MAC indexes is shown in Table 3-5, “Max Index” (p. 3-33).

Max Index table

Table 3-5 Max Index

MAC Index MAC Channel Control/Traffic Channel

0,1 �ot used �ot used

2 �ot used 78.8-kbps Control Channel

3 �ot used 38.4-kbps Control Channel

4 Reverse Activity Channel �ot used

5 �ot used Broadcast/Multimedia Service

6 - 63 User Reverse Power Control,

DRC Lock, ARQ

Single user FTC

64,65 �ot used �ot used

66 -70 �ot used Multi-user FTC

71 �ot used 19.2 kbps, 38.4 kbps or 76.8 Control

Channel

72 -127 User Reverse Power Control,

DRC Lock, ARQ

Single user FTC

Air Interface Forward Traffic ChannelMAC index

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

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

401-614-323Issue 16 October 2009

3-33

Page 194: 1xev-Do Rf Engineering

Preamble Data

Description

To assist the AT in synchronizing to the changing data rates, a sequence of preamble bits

is transmitted prior to each traffic data and control channel packet. The preamble

sequence is covered by a 32-chip bi-orthogonal sequence, which is repeated at least once

depending on the transmit data rate. For example, to provide a 1024-chip preamble length

required for a 38.4-kbps data rate, the 32-chip preamble sequence is repeated 32 times.

The preamble chips are inserted within the data portion of the slot clock period prior to

the start of the packet transmission. If the total number of preamble chips to be inserted

exceeds the 400-chip data portion of the half-slot period, as is the case for data rates of

38.4 kbps and 76.8 kbps, the preamble chips are time-multiplexed with the MAC and

pilot chips as shown in Figure 3-11, “Preamble Bits Insertion for data rates of 38.4 kbps

and 76.8 kbps” (p. 3-35).

Air Interface Forward Traffic ChannelPreamble Data

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

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

3-34 401-614-323Issue 16 October 2009

Page 195: 1xev-Do Rf Engineering

Preamble Bits Insertion for data rates of 38.4 kbps and 76.8 kbps

Figure 3-11 Preamble Bits Insertion for data rates of 38.4 kbps and 76.8 kbps

Air Interface Forward Traffic ChannelPreamble Data

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

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

401-614-323Issue 16 October 2009

3-35

Page 196: 1xev-Do Rf Engineering

Control and Pilot channels

Overview

Purpose

This section covers the following:

• Control Channel

• Pilot Channel

• MediumAccess Control (MAC) Channel

Contents

Control Channel 3-37

Pilot Channel 3-39

MediumAccess Control (MAC) Channel 3-40

Air Interface Control and Pilot channelsOverview

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

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

3-36 401-614-323Issue 16 October 2009

Page 197: 1xev-Do Rf Engineering

Control Channel

Description

The functions of the IS-95 sync and paging overhead channels are combined into a single

control channel. The control channel, which is interlaced with the transmission of traffic

data, is transmitted every 425 ms for a 13.33-ms duration as shown in Figure 3-12,

“Control Channel Timing” (p. 3-37). The control channel is 8 slots wide, and in the same

manner as the traffic data channel, each slot is divided into two 1024-chip half slots in

which the transmission of the control data, pilot pulses, and MAC channels are

time-shared.

Control Channel Timing

Figure 3-12 Control Channel Timing

Slot 2Slot 1 Slot 3 Slot 4 Slot 5 Slot 6 Slot 7 Slot 8

Half Slot

13.33 msData Channels MAC Channels Pilot Channels

Traffic Channel Traffic ChannelControl Channel Control Channel

426.67 ms

Air Interface Control and Pilot channelsControl Channel

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

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

401-614-323Issue 16 October 2009

3-37

Page 198: 1xev-Do Rf Engineering

Control Channel Structure Physical Layer Packet Bit Size

The bit size of the control channel packets transmitted to the ATs is fixed at 1024 bits.

Control channel packet data received from the MAC Layer is fixed at 1002 bits, as shown

in Figure 3-13, “Control Channel Structure Physical Layer Packet Bit Size” (p. 3-38). A

Frame Check Sequence (FCS) is performed on the 1002-bit packets received from the

MAC layer. The FCS cyclic redundancy (CRC) calculation produces a 16-bit value,

which is a function of the distribution of all the "1" bits in the 1002-bit MAC Layer

packet. The 16-bit CRC value is concatenated with the 1002-bit MAC Layer packet and a

6-bit tail to form the 1024-bit Physical Layer packet. The six bits that provide the packet

tail are tacked to the very end of the Physical Layer packet, and are always 0-bit values.

Just as for traffic data, the AT receiving the packet will perform its own CRC calculation

on the 1002-bit MAC Layer value to validate the correctness of the transmitted Physical

Layer packet. If the 16-bit CRC value computed by the AT matches the 16-bit CRC value

transmitted in the Physical Layer packet, the packet received by the AT is probably

uncorrupted.

Figure 3-13 Control Channel Structure Physical Layer Packet Bit Size

Air Interface Control and Pilot channelsControl Channel

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

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

3-38 401-614-323Issue 16 October 2009

Page 199: 1xev-Do Rf Engineering

Pilot Channel

Description

Pilot pulses are transmitted in unmodulated 96-chip bursts, occurring at pre-determined

fixed intervals at the center of each half slot-clock period. Figure 3-14, “Pilot Pulse Burst

Timing” (p. 3-39) shows the pilot pulse burst timing with reference to the MAC and

traffic data channels. The pilot pulse bursts are transmitted at the maximum power that

the cell is enabled to transmit. Using the full power of the cell for the pilot provides the

highest possible pilot Signal-to-�oise Ratio (S�R) so that an accurate estimate can be

obtained quickly, even during dynamic channel conditions.

Pilot Pulse Burst Timing

Figure 3-14 Pilot Pulse Burst Timing

Air Interface Control and Pilot channelsPilot Channel

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

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

401-614-323Issue 16 October 2009

3-39

Page 200: 1xev-Do Rf Engineering

Medium Access Control (MAC) Channel

Introduction

In Rev 0, the forward MAC channel is time divided into three sub-channels:

• Reverse Activity Channel (RAC)

• Reverse Power Control Channel (RPC)

• DRC Lock

A fourth sub-channel, Automatic Repeat Request (ARQ) is added in Rev A. A brief

description of the four sub-channels is given in the following. More detail discussions of

these sub-channels are given later in this chapter or subsequent as part of larger

discussions of the function where the sub-channels are use.

Reverse Activity Channel

Reverse Activity Channel: Indicates to the ATs if they can increase or decrease their data

rates by sending a Reverse Activity Bit (RAB) stream. Seven new reverse channels data

rates were introduced in Rev A, in addition to the five possible reverse link data rates,

from 9.6 kbps to 153.6 kbps in Rev 0. In addition, a new reverse rate control mechanism

introduced in Rev A enables the rate to reach its RF environment potential faster. This rate

control mechanism uses a Traffic-to-Pilot (T2P) parameter in addition to the RAB, and

will be fully discussed later in Chapter 7.

DRCLock Channel

DRCLock Channel: If an AT receives a DRCLock bit on the DRCLock Channel that is set

to '0,' the AT does not point its DRC at that sector.

Reverse Power Control (RPC) Channel

Reverse Power Control (RPC) Channel: Each AT with an active connection is assigned an

RPC Channel. The RPC Channel is used for the transmission of the RPC bit stream

(similar to the Power Control Bits, PCB, in 3G-1X) destined to a particular AT. Which

RPC bit stream value to transmit is determined by the Reverse Power Control algorithm.

Automatic Repeat Request (ARQ) Channel

Automatic Repeat Request (ARQ) Channel: Used only in Rev A to allow the base station

to acknowledge reverse links transmission, and is described in greater detail as part of the

reverse link channel discussion.

Air Interface Control and Pilot channelsMedium Access Control (MAC) Channel

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

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

3-40 401-614-323Issue 16 October 2009

Page 201: 1xev-Do Rf Engineering

Generation of the MAC Channel

In Rev A, All MAC Channels are code division multiplexed (128-ary Walsh code), as

shown in the generation of the MAC channel, Figure 3-15, “Generation of the MAC

Channel” (p. 3-41).

Forward MAC ARQ Channel

The Forward MACARQ Channel is introduced in Rev A to support the sub-packet

transmission of the Physical Layer packet, which is transmitted on the Reverse Traffic

Channel. Each sector transmits a positive acknowledgment (ACK) or a negative

Figure 3-15 Generation of the MAC Channel

MAC Channel RPC bits 150 bps

MAC Channel H-ARQ or L-ARQ bits

MAC Channel P-ARQ bits

MAC Channel DRCLock

(150/DRCLockLength)

Signal PointMaping

0 +11 -1

ARQ SignaPoint

Mapping

RPC ChannelGain

ARQ ChannelGain

Signal PointMapping0 01 -1

Signal PointMapping

0 +11 -1

Signal PointMapping

0 +11 -1

ARQ ChannelGain

Bit Repetition

DRCLockGain

123-ary Walsh Cover forMACIndex i

123-ary Walsh Cover forMACIndex i

TDM

TDM

RAChannel

Gain

RA Bits1 bit per slot

(600 bps)

Walsh Cover W2

128

WalshChip LevelSummer

I

Q

Air Interface Control and Pilot channelsMedium Access Control (MAC) Channel

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

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

401-614-323Issue 16 October 2009

3-41

Page 202: 1xev-Do Rf Engineering

acknowledgment (�AK) in response to a Physical Layer packet using the ARQ Channel.

As shown in Figure 3-15, “Generation of the MAC Channel” (p. 3-41), three different bits

are transmitted on the ARQ Channel.

• An H (hybrid)-ARQ bit is transmitted on the ARQ Channel by a sector following the

reception of the first, second, or third sub-packets of a Physical Layer packet.

• An L (Last)-ARQ bit is transmitted on the ARQ Channel by a sector following the

reception of the fourth sub-packet of a Physical Layer packet.

• A P (packet)-ARQ bit is transmitted on the ARQ channel to indicate to the AT whether

or not the Physical Layer packet that was transmitted was successfully received by

that sector.

I and Q quadrature

The I and Q quadrature in which the ARQ bits are transmitted is a function of the

odd/even MACIndex assigned to the AT user, as shown in Figure 3-16, “MAC Channel

Multiplexing” (p. 3-43). The H/L-ARQ is time-division multiplexed with the RPC bits,

and the P-ARQ is time-division multiplexed with the DRCLock symbols. A sector

transmits the H-ARQ bit to an AT using Bi-Polar Keying, or ACK-oriented O�-OFF

Keying if the sector is part of the serving cell. A sector transmits the H-ARQ bit using

ACK-oriented O�-OFF Keying if the sector is not part of the serving cell. Both L-ARQ

and P-ARQ are transmitted on the ARQ Channel using �AK-oriented O�-OFF Keying.

Air Interface Control and Pilot channelsMedium Access Control (MAC) Channel

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

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

3-42 401-614-323Issue 16 October 2009

Page 203: 1xev-Do Rf Engineering

MAC Channel Multiplexing

Figure 3-16 MAC Channel Multiplexing

RPC H-ARQ orL-ARQ bit

H-ARQ orL-ARQ bit

H-ARQ orL-ARQ bit

RPC H-ARQ orL-ARQ bit

H-ARQ orL-ARQ bit

H-ARQ orL-ARQ bit

RPC H-ARQ orL-ARQ bit

H-ARQ orL-ARQ bit

H-ARQ orL-ARQ bit

RPC H-ARQ orL-ARQ bit

H-ARQ orL-ARQ bit

H-ARQ orL-ARQ bit

Slot T T+1 T+2 T+3

T T+1 T+2 T+3

DRCLock P-ARQbit

P-ARQbit

P-ARQbit

DRCLock P-ARQbit

P-ARQbit

P-ARQbit

DRCLock P-ARQbit

P-ARQbit

P-ARQbit

DRCLock P-ARQbit

P-ARQbit

P-ARQbit

MAC Channel for user with even MAC Index

MAC Channel for user with odd MAC Index

I

I

Q

Q

Air Interface Control and Pilot channelsMedium Access Control (MAC) Channel

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

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

401-614-323Issue 16 October 2009

3-43

Page 204: 1xev-Do Rf Engineering

Data transmission factors

Overview

Purpose

This section discusses the following:

• Incremental Redundancy

• Packet Transmission termination

• Dynamic Rate Control

• Rev AData Source Control (DSC) Channel

• Virtual Soft Handoff

Contents

Incremental Redundancy 3-45

Packet Transmission termination 3-47

Dynamic Rate Control 3-49

Rev AData Source Control (DSC) Channel 3-51

Virtual Soft Handoff 3-54

Air Interface Data transmission factorsOverview

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

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

3-44 401-614-323Issue 16 October 2009

Page 205: 1xev-Do Rf Engineering

Incremental Redundancy

Multi-Slot Packet Transmission

The packet data to be transmitted is redundant-coded by the turbo coder, increasing the

number of bits transmitted by a factor of 3 or 5 in accordance with the code rate specified

by the transmit data rate. To account for the increase in data bits to be transmitted, at most

transmit data rates, multiple slot periods are specified for a single packet transmission.

Incremental redundancy is used, where enough data is transmitted in one time slot period

so that if RF conditions improve during transmission, the receiver is enabled to

reconstruct the complete packet information in less than the number of slot periods

specified for the transmission format. For example, even through the specification allots

four time slots to send a packet when transmitting at a 153.6 kbps using transmission

format 1024, 4,128, enough packet information bits are sent in each time slot to enable

the AT to recover and validate the whole packet in less than the specified four time slots.

When transmitting at this rate, a redundancy factor of five is used. If the packet data

received by the AT cannot be validated after the first slot transmission, the packet

information transmitted in the second time slot provides more and different redundant bits

to complement the data bits sent in the first time slot, providing the AT with a greater

opportunity to validate the packet. If the packet still cannot be validated, different

redundancy bits are transmitted in subsequent time slots to further increase the

opportunity for the AT to validate the packet.

Slot Data Interlacing

When data is transmitted at a data rate that is allotted for multiple-slot packet

transmission, a 1-to-3 slot data interlacing pattern is used. This means that the

transmission of three separate packets is performed in an alternating sequence as shown

in Figure 3-17, “Multi-Slot Data Interlacing with �ormal Termination” (p. 3-46). In this

scheme, each packet allotted for multi-slot transmission is transmitted every fourth slot.

The three time-slot spacing between successive packet slot transmissions is required to

allow the base station to receive confirmation from the AT regarding whether the AT was

successful in validating the correctness of the packet data it received.

Multi-Slot Data Interlacing with Normal Termination

Figure 3-17, “Multi-Slot Data Interlacing with �ormal Termination” (p. 3-46) illustrates

what happens when the base station receives a request from an AT to transmit a packet at

a 153.6-kbps rate, which is allotted four time slots. Transmission is initiated after the base

station receives a data rate control (DRC) request from the AT for packet transmission at

the 156.3-kbps rate. Subsequently, the requested packet is transmitted during next

available time slot "n". During the next three time slots (n+1 through n+3), the base

station will transmit other packets to the same AT, or other ATs at different data rates.

Air Interface Data transmission factorsIncremental Redundancy

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

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

401-614-323Issue 16 October 2009

3-45

Page 206: 1xev-Do Rf Engineering

After the AT receives each slot packet transmission, it performs a frame check sequence

(FCS) computation to validate the correctness of the packet data information is received.

Figure 3-17 Multi-Slot Data Interlacing with Normal Termination

Air Interface Data transmission factorsIncremental Redundancy

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

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

3-46 401-614-323Issue 16 October 2009

Page 207: 1xev-Do Rf Engineering

Packet Transmission termination

Normal Packet Transmission Termination

In a normal packet transmission termination cycle, the transmitted packet data from all

four allotted time slots (n, n+4, n+8, and n+12) are required for the AT to successfully

validate the packet data information; therefore, after each intervening time slot, the AT

will return a negative acknowledgment (�AK) signal on the ACK reverse channel. The

�AK signal indicates that the AT could not validate the correctness of the packet data

information received. In a normal packet transmission termination cycle, a positive

acknowledgment signal (ACK) will be received after the four slot (n+12) packet data

transmission. If at this time a �AK rather than an ACK signal is returned, the complete

packet transmission cycle must be re-initiated at a subsequent time, perhaps at a slower

data rate, or when the AT RF environment improves.

The �AK and ACK signals are 1024 P� binary-phase shift keying (BPSK)- modulated

chips wide, and are transmitted on the first half of the time-slot period. The �AK signal is

identified when all 1 bits are transmitted, and the ACK is identified when all 0 bits are

transmitted.

Early Packet Transmission Termination

If during the packet data transmission cycle the AT RF environment improves, the AT

could validate the correctness of the packet data information after the first, second, or

third time slot (refer to Figure 3-18, “Multi-Slot Data Interlacing with Early Termination”

(p. 3-48)). In this case, an early packet transmission termination occurs where rather than

receiving a �AK signal after the first, second, or third time slot, the base station receives

an ACK signal, indicating that the packet is successfully validated at the AT. At this time,

the base station cancels transmission of the packet during the remaining time slots in the

packet transmission cycle, and in their place initiates the transmission of a new packet or

packets.

Air Interface Data transmission factorsPacket Transmission termination

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

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

401-614-323Issue 16 October 2009

3-47

Page 208: 1xev-Do Rf Engineering

Figure 3-18 Multi-Slot Data Interlacing with Early Termination

Half slot offset

n n+1 n+2 n+4 n+5 n+6 n+7 n+8 n+9 n+10 n+11 n+12 n+13 n+14 n+15n+3Slot

Forward Traffic Dataor Control Channel

ReverseDataRate ControlSub-Channel

Reverse ACKChannel

DRC Requestfor 153.6 kbps

Rate

NAK NAK NAKACK

n n+1 n+2 n+4 n+5 n+6 n+7 n+8 n+9 n+10 n+11 n+12 n+13 n+14 n+15n+3Slot n-1

Initiate firstpacket

Transmission

Initiate secondpacket

Transmission

Air Interface Data transmission factorsPacket Transmission termination

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

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

3-48 401-614-323Issue 16 October 2009

Page 209: 1xev-Do Rf Engineering

Dynamic Rate Control

Data Rate as a Function of RF Environment

The rate at which data is transmitted to the AT is a function of the AT RF environment,

and is subject to dynamic reselection during each 1.66-ms slot-clock period. The AT

continuously monitors the quality of receive pilot pulses from all sectors in the active set

(all neighboring sectors). In response, the AT sends back a data rate control (DRC) report

to the base stations in the active set. The DRC report identifies the sector with the highest

C/I ratio and the highest rate in which the AT can receive quality data from the sector

within a margin to insure a low erasure rate. The sector identified be the DRC code then

resumes transmission at the rate indicated by the DRC report.

Rev A Data Rate Control (DRC) Offset

Rev A provides a mechanism that allows the R�C to down-adjust the DRC value

transmitted by an AT. This happens when the AT overestimates its ability to receive data

in its present RF environment, which is determined using the transmission formats

associated with the transmitted DRC. The R�C may make this determination from a high

�AK frequency, and/or by a high re-transmission rate at the RLP level. If the AT is

overestimating its ability to receive data at a given rate, there might be no instances of

early termination and a high retransmission rate.

DRC Offset lookup table

In Rev A, the DRC value estimated by the AT is a function of determining the sector with

the strongest C/I, as defined as a Tentative DRC value. As part of the Generic Attribute

Update protocol, the R�C and the AT computes a DRC Offset lookup table (see Figure

3-19, “DRC Offset lookup table” (p. 3-50)), which is a two-column table listing a DRC

offset value for each Tentative DRC value. Before transmitting its DRC value, the AT

consults the DRC Offset lookup table and subtracts the DRC offset value corresponding

to the determined Tentative DRC value (from the Tentative DRC value). The result is the

Transmitted DRC value that is sent to the base station.

Air Interface Data transmission factorsDynamic Rate Control

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

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

401-614-323Issue 16 October 2009

3-49

Page 210: 1xev-Do Rf Engineering

Computing DRC offset table

The DRC lookup table is computed based on the R�C experience within a sector. The

ultimate requirement of a non-zero DRC offset value is to derive a more realistic

Transmitted DRC value; this causes the selection of a better transmission format, which

increases the chance of improved data throughput. When computing DRC values two

rules must be maintained:

1. The data rate of the Transmitted DRC canonical format must be less than or equal to

the data rate of the Tentative DRC canonical format. Therefore, the DRC offset value

may or may not cause a reduction in the transmission data rate.

2. The span of the Transmitted DRC canonical format must be greater than or equal to

the span of the Tentative DRC canonical format.

A zero DRC offset value is selected when the data rate and span of the Transmitted DRC

canonical format are equal to the data rate and span of the Tentative DRC canonical

format.

Figure 3-19 DRC Offset lookup table

TentativeDRC

DRC Offset

0x40x50x60x70x80x90xA0xB0xC0xD

1

202102123

From C/I measure, AT determinesa tentative DRC value of 10

10 Tentative DRC

DRC offset of 2 corresponds toTentative DRC value of 10

2 DRC offset

Subtract DRC offset from TentativeDRC value

8 DRC value transmitted

DRC Offset Lookup Table

Air Interface Data transmission factorsDynamic Rate Control

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

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

3-50 401-614-323Issue 16 October 2009

Page 211: 1xev-Do Rf Engineering

Rev A Data Source Control (DSC) Channel

Introduction

The Data Source Control Channel is a new reverse link logical channel, providing

seamless Forward Link cell to cell handoff. Virtual real-time applications in Rev A, such

as VoIP, require virtually uninterrupted forward link handoff.

Unlike soft handoff performed in IS-95/3G1X, during which the mobile may

simultaneously interact with two or more sectors to realize an uninterrupted signal flow,

this uninterrupted signal flow is not achieved with 1xEV-DO during cell-to-cell handoff

because the AT interacts with only one sector at a time. As a result, in Rev 0, AT service

on the forward link may be interrupted during cell switching when the new cell undergoes

the necessary preparation; this interruption may not be acceptable for VoIP service.

VoIP to 1X handoff

The 1xEV-DO system has limited information about the VoIP to 1X handoff. The

performance management strategy for 1xEV-DO system is to provide necessary

measurements to help understand the VoIP to 1X handoff events that either trigger the

handoff or happen during the handoff. The difference between measurements can be used

to understand any potential problem in the system, that is, A21 or RF related issues. To

get an end-to-end view of the VoIP to 1X handoff, operators look at the measurements

from all the network elements involved, DO, 1X, and IMS. Also, the operator can

correlate data from Service Measurements with PCMD and HOM to help troubleshoot

any problems.

Forward Link Handoff with DSC

To minimize this signal flow interruption to acceptable levels for VoIP, in Rev A the AT

transmits over the DSC channel to provide an early indication of the handoff candidate

cell. In this scenario, the handoff switching process can start while the AT is still receiving

data from the old cell. Once the DSC message occurs, the AT would then point its DRC to

the candidate sector in the new cell (see DSC timing diagram Figure 3-20, “DSC Timing”

(p. 3-52)).

Air Interface Data transmission factorsRev A Data Source Control (DSC) Channel

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

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

401-614-323Issue 16 October 2009

3-51

Page 212: 1xev-Do Rf Engineering

DSC selection

Figure 3-21, “DSC Selection” (p. 3-53) illustrates how the DSC signal precedes the DRC

pointer to identify the data source cell and minimize the flow interruption when the AT

moves between cells. Prior to selecting forward link data from sector S1 of Cell 1, the AT

transmits a DSC signal, identifying its desire to receive data from Cell 1. In response, the

R�C is signaled to prepare to switch the flow from its current serving cell to Cell 1. The

actual flow is not switched until the AT points its DRC to Cell 1, Sector 1 (C1S1). After

the flow is switched, the AT may move freely between Sectors 1 and 2 with virtually

limited interruption, because the traffic channel between the R�C and Cell 1 is already

established.

If the AT detects a stronger pilot signal from Sector 1, Cell 2, it switches its pointer on the

DSC channel to Cell 2, preparing the R�C to switch the flow from Cell 1 to Cell 2 when

the DRC signal points to Sector 1, Cell 2 (S1C2).

Figure 3-20 DSC Timing

Forward link serving cellBTS1

Forward link serving cellBTS1

Forward link serving cellBTS2

Forward link serving cellBTS2

DRC Coverchange

DSC Coverchange

DRC detection atBTS1 & BTS2

SCC detection atBTS1 & BTS2

Transferto BTS2

Transferto BTS2

BTS1 sends DSC change indication (DSCI)BTS2 sends Forward Desire Indication (FDI)

BTS1 sends Forward Stop Indication (FSI)DRC Cover changeBTS2 Starts transmission

time

time

DSCLength

Forward Link Handoff in Rev A

Forward Link Handoff in Rev 0

In Rev 0, service may beinterrupted during handofftransfer to the BTS2.

In Rev A, the BTS2 is notifiedof an impending handoff by aDSC value, which isTransmitted slotsbefore the DRC Coverchange.

DSClength

The value of isDSClengthspecified by the EnhancedForward Traffic Channelprotocol.

Air Interface Data transmission factorsRev A Data Source Control (DSC) Channel

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

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

3-52 401-614-323Issue 16 October 2009

Page 213: 1xev-Do Rf Engineering

Figure 3-21 DSC Selection

Cell 1

Cell 2

S1

S1

S2

S2

C1S1

Cell 1

C1S2 C1S2

Cell 2

C2S1 C2S1

DSC

DRC

Directiom oftravel

RNC

Air Interface Data transmission factorsRev A Data Source Control (DSC) Channel

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

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

401-614-323Issue 16 October 2009

3-53

Page 214: 1xev-Do Rf Engineering

Virtual Soft Handoff

Introduction

The selection from one sector to another is called virtual soft handoff. Unlike soft handoff

performed in IS-95 during which the mobile may simultaneously interact with two or

more sectors to realize a signal gain, this signal gain is not achieved during virtual

handoff because the AT interacts with only one sector at a time. The virtual soft handoff

scenario is shown in Figure 3-22, “Virtual Soft Handoff” (p. 3-54).

When the DRC report from an active AT identifies (points to) Sector 1 as its best serving

sector, Sector 1 sends a Forward Data Request to the 1xEV Controller in the FMS. In

response, the FMS sends the requested Data Packets to Sector 1, which are then

transmitted in Frame messages to the AT. Subsequently, if the DRC reports from the AT

point to Sector 2 as its best serving sector for a definable period, Sector 2 will send a

Forward Data Request to the 1xEV Controller in the FMS. Sensing that it has not

received best server pointing DRC reports for a period of time, Sector 1 will send a

Forward Stop Indicator message to the 1xEV Controller. This message also identifies the

last frame ID transmitter to the AT. After receiving indications from both sectors, the

Figure 3-22 Virtual Soft Handoff

AT Sector 1 Sectior 2 RNC

DRC

Data PacketsFrame

DRC

FrameData Packet

Flush Buffer

Forward Data Request

Forward Data Request

Forward Stop Indicator

Air Interface Data transmission factorsVirtual Soft Handoff

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

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

3-54 401-614-323Issue 16 October 2009

Page 215: 1xev-Do Rf Engineering

1xEV Controller directs Sector 1 to flush the remaining un-transmitted data from its

buffer. The Data Packets are then sent to Sector 2 so that transmission to the AT can

continue from Sector 2.

Air Interface Data transmission factorsVirtual Soft Handoff

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

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

401-614-323Issue 16 October 2009

3-55

Page 216: 1xev-Do Rf Engineering

Rev-0 Scheduling

Overview

Purpose

This section discusses the Rev-0 scheduling algorithm and settings.

Contents

Rev 0 Scheduling Algorithm 3-57

Flexible Scheduler (FID 8948.0) Feature 3-58

Minimum and Maximum Throughput Target Service Measurements 3-61

G-Fair and RandomActivity Factor 3-63

Air Interface Rev-0 SchedulingOverview

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

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

3-56 401-614-323Issue 16 October 2009

Page 217: 1xev-Do Rf Engineering

Rev 0 Scheduling Algorithm

Maximizing Sector Throughput

To maximize the overall sector throughput, 1xEV-DO uses a scheduling algorithm that

takes advantage of a multi-user pool vying for time on the carrier. Another primary factor

in determining the data rate service received by an AT user is a function of the C/I

currently experienced by the AT. Based on the DRC reported by each AT, the scheduling

algorithm is weighted to favor data transfer with only the ATs operating in favorable RF

conditions, so that the sector data is transferred at the highest possible rate. Transmission

to ATs operating in less favorable RF conditions may be delayed on the order of

milliseconds; at a time, hopefully, when the ATs' RF conditions improve.

Even though scheduling is weighted to favor the AT with the highest measured C/I value

performance, in fairness to users in less-favorable RF environments, prior to release R22,

scheduling priority was performed by a proportional fair algorithm. This algorithm

performed scheduling based on a combination of the C/I value measured at the AT, which

is determined by the AT requested data rate and the time lapsed since the AT was last

serviced. By delaying service to the ATs until their RF conditions improve, the overall

data throughput to the ATs is higher than if the ATs were served on a first-in, first-out

basis. In release R22, the Flexible Scheduler (FID 8948.0) feature was introduced to add

two new on-line scheduling algorithms along with an off-line scheduling algorithm to

provide performance testing of the system.

Proportional Fair (PF) Scheduling Algorithm

To maximize the AT data throughput in rapidly changing RF environments, proportional

fair (PF) scheduling is used. This is done by maintaining a running average of the data

rate requested by each AT user. The ratio of the DRC report to the running average is used

to identify peak data rate opportunities for data transmission to that AT user. For example,

if the running average data rate computed for an AT user is 307.9 kbps, in a rapidly

changing RF environment, its DRC data rate requests will oscillate above and below this

value. Peak data rate conditions will be identified when the data requests from the AT are

at or above 307.9 kbps; at such times, the base station will service the AT with a higher

throughput probability.

Air Interface Rev-0 SchedulingRev 0 Scheduling Algorithm

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

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

401-614-323Issue 16 October 2009

3-57

Page 218: 1xev-Do Rf Engineering

Flexible Scheduler (FID 8948.0) Feature

Introduction

The Flexible Scheduler (FID 8948.0) feature is a FAF-activated feature introduced in

release R22. This feature provides flexibility in selecting different forward link scheduler

algorithms to meet service providers' requirements according to the needs of particular

markets. Software hooks are provided in this feature to support future Quality of Service

(QoS) requirements. In addition to the PF scheduling algorithm, this feature introduces

three other scheduling algorithms, which are:

• Min/Max Rate Control

• G-Fair

• RandomActivity Factor

Description

The scheduling algorithm is selected on the Service �odes/Flexible Scheduler page in the

Element Management System for all base stations in a service node. This algorithm can

also be selected and modify for individual base stations via the BTS/Flexible Scheduler

page. Parameter left blank on the BTS/Flexible Scheduler page will escalate to the value

of the same parameters on the Service �odes/Flexible Scheduler page.

Prior to this feature, only PF scheduling could be performed. The PF scheduling

algorithm is selected by default. This type of scheduling provides fairness among all the

users by ensuring roughly equal airtime for all the users. However, the throughput that

any user might experience is proportional to the rate at which the data is transmitted, and

that rate is a function of the user's current RF environment. Therefore, proportional fair

scheduling does not make any effort to guarantee a minimum throughput.

Min/Max Rate Control Scheduling Algorithm

Unlike the PF scheduling algorithm, which does not make any effort to guarantee a

minimum throughput, the min/max rate control scheduling algorithm allows the service

provider to specify both a minimum throughput and a maximum throughput. A maximum

limitation may be desirable for a number of reasons. One might be to restrict a user's

maximum throughput rate so that a relatively steady data throughput is experienced.

Another reason is that by limiting maximum throughput targets, more users in

heavy-traffic sectors may access the system with the assurance of a minimum data

throughput system effort. In the future, another reason to limit maximum throughput may

be to offer different QoS levels where only premium users may avail themselves of the

higher-throughput data rates.

The min/max rate control scheduling algorithm is selected by selecting theMin/Max Rate

Control value for the Flexible Scheduler Choice parameter on the Service �odes/Flexible

Scheduler page. The minimum throughput may be selected from 0 to 64 kbps in 4k steps

Air Interface Rev-0 SchedulingFlexible Scheduler (FID 8948.0) Feature

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

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

3-58 401-614-323Issue 16 October 2009

Page 219: 1xev-Do Rf Engineering

via theMinimum Throughput Target (Rmin) parameter, and the maximum throughput may

be selected from 9.6 to 2457.6 kbps in 4.8 k steps via theMaximum Throughput Target

(Rmax) parameter. The Rmax value must be at least twice as large as the Rmin value.

Minimum Throughput Target

In the min/max rate control scheduling algorithm, after the minimum throughput target

rate is satisfied for every user, the algorithm will optimize sector throughput using one of

two optimization schemes. The first is identified as Proportional Fair with Minimum Rate

control (PFMR) and the other is Maximum Throughput with Min Rate control (MTMR).

The optimization scheme is selected by theMin/Max Rate Control Direction parameter

value on the Service �odes/Flexible Scheduler page.

When the PFMR scheme is selected, once all users achieve the minimum throughput

target, the PFMR scheme optimizes throughout by simulating the proportional fair

scheduler. The result is that the remaining system resources are shared by all users in

proportion to their DRC request value.

When the MTMR scheme is selected, once all users achieve the minimum throughput

target, the user with the highest DRC request value will receive all system resources

required to achieve its fullest throughput potential. This potential may be achieved at the

cost of other users that will not receive a proportional share of the resource in accordance

with their DRC request values.

Limitations

Regardless of the optimization scheme selected, the enforcement of a minimum

throughput target for all users may limit the total sector throughput. This is because one

or more users in poorer RF environments may require more base station transmission

time (time slots), limiting higher throughput opportunities for users in good and excellent

RF environments. Therefore, meeting minimum throughput targets and maximizing sector

throughput sometimes may be conflicting goals.

To prevent a user in poor RF environments from hogging system resources while trying to

receive the minimum throughput, the number of time slots dedicated to that user may be

curtailed. This is done by the Rmin Hog Prevention Factor parameter value, which is

inserted via the Service �odes/Flexible Scheduler page. The parameter may be varied

from 1.5 to 2.5 in steps of 0.1. This parameter limits the number of time slots that may be

used to achieve the minimum throughput for poor RF environment users. Users in poor

RF environments may not achieve their minimum throughput targets until their RF

environment improves. The smaller the Rmin Hog Prevention Factor parameter value, the

more closely the scheduling algorithm simulates the PF scheduler.

Air Interface Rev-0 SchedulingFlexible Scheduler (FID 8948.0) Feature

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

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

401-614-323Issue 16 October 2009

3-59

Page 220: 1xev-Do Rf Engineering

Maximum Throughput Target

Users in good and excellent RF reception areas may hog system resources. Consequently,

theMaximum Throughput Target (Rmax) parameter is used to set limits on the maximum

throughput that any user may achieve. The enforcement of the Rmax target value can be

either loosely or strictly controlled using the Restrict Throughput After Reaching Rmax

parameter. When this parameter is set to Strict, the throughput experienced by users is

limited to the Rmax value even if forward link time slots are available to increase a

portion of the users' throughput beyond Rmax. In this case any unused time slots will

remain idle. However, if the Restrict Throughput After Reaching Rmax parameter is set to

�on strict, then after all AT users reaches the Rmax target, the remaining unused time

slots will be used to increase the throughput of the users beyond the Rmax target.

Air Interface Rev-0 SchedulingFlexible Scheduler (FID 8948.0) Feature

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

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

3-60 401-614-323Issue 16 October 2009

Page 221: 1xev-Do Rf Engineering

Minimum and Maximum Throughput Target ServiceMeasurements

Introduction

As discussed in “Minimum Throughput Target” (p. 3-59), enforcement of minimum

throughput targets in a portion of the RF environments may lower overall sector/carrier

throughput. Therefore, a number of service measurements are collected to aid in

optimizing system throughput in different service areas when theMaximum Throughput

Target (Rmax) parameter is used. Descriptions of these service measurements follow.

Average Percentage of Slots Throughput Below Rmin

The average percentage of slots throughput below Rmin service measurement indicates

the average percentage of time slots dedicated to users whose average throughput is 10

percent below the Rmin throughput target for a sector/carrier. The 10 percent tolerance

below the Rmin throughput target is to discount the fluctuation in the average throughput.

This count should be 0 when the Minimum Throughput Target (Rmin) parameter is set to

0.

Although only used for optimizing system throughput when the Maximum Throughput

Target (Rmax) parameter is used, this count is maintained regardless of the Flexible

Scheduler Choice parameter selection. The number of time slots dedicated to users whose

average throughput is 10 percent below the Rmin throughput target is continuously

collected in 10-second intervals. Successive 10-second accumulations are then averaged

with previous accumulations to generate an hourly service measurement report to indicate

the average percentage of time slots that are being used by users in poor RF environments

who throughput are below the Rmin throughput target. A very high value may indicate

that significant amount of sector/carrier throughput is being compromised,

Average Percentage Of Slots Throughput Above Rmax

T he average percentage of slots throughput above Rmax service measurement indicates

the average percentage of time slots dedicated to users whose average throughput is 10

percent above the Rmax throughput target for a sector/carrier. The 10 percent tolerance

above the Rmax throughput target is to discount the fluctuation in the average throughput.

This count should be 0 when the Maximum Throughput Target (Rmin) parameter is set to

2457.6 kbps.

Although only used for optimizing system throughput when the Maximum Throughput

Target (Rmax) parameter is used, this count is maintained regardless of the Flexible

Scheduler Choice parameter selection. The number of time slots dedicated to users whose

average throughput is 10 percent above the Rmax throughput target is continuously

collected in 10-second intervals. Successive 10-second accumulations are then averaged

Air Interface Rev-0 SchedulingMinimum and Maximum Throughput Target Service

Measurements...................................................................................................................................................................................................................................

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

401-614-323Issue 16 October 2009

3-61

Page 222: 1xev-Do Rf Engineering

with previous accumulations to generate an hourly service measurement report indicating

the average percentage of throughput time that is being used by users who throughput are

above the Rmax throughput target.

Average Number of Scheduler Eligible Users

This service measurement records the average number of active users that are eligible for

scheduling throughput data on a sector/carrier. To be eligible, the user must have a valid

DRC pointing to the sector and must receive more than 0 bytes of data. This count is

different from the number of active connections count, because the latter is incremental

when an active traffic channel is allocated to the user and does not indicate that data

transmission occurred. This count is pegged regardless of the Flexible Scheduler Choice

parameter selection.

Total Busy Slots Percentage Used for User Traffic Data Transmission

This service measurement indicates the forward link bandwidth usage. This service

measurement is reported as the percentage of time slots per sector/carrier that are used for

traffic data transmission as opposed to control channel, or no data (idle time slots),

transmission. A count is incremented each time a time slot is used to transmit traffic data.

The count accumulated after each hour is then divided by 2,160,000, which is the number

of time slots in one hour. The quotient is then multiplied by 100 to obtain the percentage

of traffic data time slots in one hour.

Total Percentage of Slots When Rmin Hogging in Effect

This service measurement indicates the percentage of slots that were curtailed by the

Rmin Hog Prevention Factor parameter value. A count is incremented for each time slot

that the Rmin Hog Prevention Factor parameter value prevents a user in a poor RF

environment from achieving the Rmin throughput target. After one hour, this count is

divided by the Average �umber of Scheduler Eligible Users resulting in the Total

Percentage of Slots When Rmin Hogging in Effect service measurement.

Air Interface Rev-0 SchedulingMinimum and Maximum Throughput Target Service

Measurements...................................................................................................................................................................................................................................

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

3-62 401-614-323Issue 16 October 2009

Page 223: 1xev-Do Rf Engineering

G-Fair and Random Activity Factor

G-Fair Scheduling

This scheduling algorithm (G-fair) is the generalization of proportional fair (PF) and

allows flexibility for future QoS implementation. G-fair scheduling will control

individual user's throughput in relation to other users' throughput based on the user's QoS.

This is done while maintaining the proportional fair algorithm advantage of multi-user

diversity. Rather than using the instantaneous DRC value as in the proportional fair

algorithm, the G-fair algorithm uses an average DRC value. When QoS is implemented,

the algorithm will always dedicate the next time slot to the user with the highest DRC X (

) to average throughput ratio, where h ( ) is specified by a translation function. Based

upon QoS each user is assigned an h ( ) function that favor premium users when

everything else is equal. Until the h ( ) function is implemented, the G-Fair algorithm will

behave the same for all the users.

Random Activity Factor

The Random Activity Factor value of the Scheduler Choice parameter is used for

Minimum Performance Standard testing only and should not be used for regular system

operation. When the Random Activity Factor value is selected, the scheduler will

randomly select a user from the active users for transmission.

Air Interface Rev-0 SchedulingG-Fair and Random Activity Factor

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

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

401-614-323Issue 16 October 2009

3-63

Page 224: 1xev-Do Rf Engineering

Rev A Scheduler Algorithm

Overview

Purpose

This section discusses the Rev-A scheduler algorithm.

Contents

Quality of service 3-65

Flows 3-66

Multi-user packet 3-68

Air Interface Rev A Scheduler AlgorithmOverview

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

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

3-64 401-614-323Issue 16 October 2009

Page 225: 1xev-Do Rf Engineering

Quality of service

Introduction

To maximize air capacity, in Rev 0, the users in the most favorable RF environments got

preference. This is because the more favorable the RF environment, the greater the

transmitted data capacity. Even though the Rev 0 scheduler played favorite to those users

in good RF environments, it also maintained a type of proportional fairness to all users in

the sector. In a time average, all users were served, but those in the most favorable RF

environments got more.

Managing Quality of Service

The Rev A scheduler has a tougher job because Quality of Service (QoS) is factored in.

�ow the scheduler is concerned with the user QoS profile and traffic data QoS Class.

Three separate QoS classes are defined:

• Best Effort (BE): High reliability, delay tolerant - this class refers to data flows that

require a low bit error rate (BER) and can tolerate high end-to-end delays. With no

throughput requirement; the size of the data to be transmitted can be small or large.

Examples of BE flows may be text file downloads (ftp) and web surfing.

• Assured Forwarding (AF): Typically the same as BE with a minimum average

throughput requirement. Streaming video may be considered for this class.

• Expedited Forwarding (EF): Delay-intolerant with lower reliability requirements than

BE. This QoS class provides stringent end-to-end delay requirements, and is divided

into five subclasses, distinguished by data flow rate. Examples of such flows are VoIP

and online gaming.

In addition to meeting QoS requirements, as with the Rev 0 scheduler, the Rev A

scheduler must maximize system capacity and maintain fairness across flows in both

throughput and delay.

Air Interface Rev A Scheduler AlgorithmQuality of service

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

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

401-614-323Issue 16 October 2009

3-65

Page 226: 1xev-Do Rf Engineering

Flows

Flows and queues

The Rev A Scheduler schedules the forward link transmission of different flows in

accordance with the QoS propriety of each flow, with respect to all other flows waiting

for transmission. A flow is a data stream, bundled within a packet, and destined to a user.

The source of a flow may be generated by one or more applications, such as ftp when a

file is downloaded, and http when surfing the web. Other applications generate source

flows for email, VoIP, online gaming, streaming video and audio. A flow may also be

generated by the 1xEV-DO system itself, such as SID signaling and overhead message

flows, to initiate and maintain the user sessions, and for 1xEV-DO system test

applications. Each flow may have a set of QoS requirements, defining a target throughput

and/or delay bound. The delay bound is a time value assigned to each flow that indicates

the maximum time the data within a flow can remain in a buffer before the data must be

transmitted and received by the user's AT.

A user may have multiple concurrent flows with different QoS requirements. Each flow

may be generated by either only one application, such as VoIP, ftp, and signaling, or it

may be generated by multiple applications that are aggregated into a single flow and,

thus, appear to the scheduler as a single flow with one set of QoS requirements.

Flow queue

Two queues may be provided to buffer each data flow. One queue, designated as the first

transmission (FTx) queue, holds the data for the first time transmission to the user.

Additional queues may be needed: the RLP retransmission (RTx) queue and the Delayed

Acknowledge Request (DARQ) queue are provided if RPL and/or MAC layer

retransmissions are required.

Octet timestamp

A timestamp is assigned to each packet buffered in the queues so that all octets within the

packet have the same timestamp, even though the octets within the packet may be

generated by different applications at different times. The timestamp enables the

scheduler to determine the current delay incurred by each octet within the packet.

The DelayBound parameter is associated with each time-sensitive flow, and indicates the

maximum delay, relative to the timestamp, that the packet or octets within the packet can

tolerate for successful forward link transmission to the user.

Time sensitive flows are of a nature that data received out of sequence becomes disruptive

to the intelligence of the data flow. Therefore, once the DelayBound of a packet is

reached, and the packet is not transmitted, the packet is taken out of the queue and

discarded.

Air Interface Rev A Scheduler AlgorithmFlows

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

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

3-66 401-614-323Issue 16 October 2009

Page 227: 1xev-Do Rf Engineering

Because BE and AF flows are not time-sensitive flows, these flows are assigned a zero

DelayBound value, representing infinite delay tolerance. �ote that the DelayBound value

is different from the end-to-end delay bound, which would involve delay-budget

components

Flow capacity fairness

The definition of capacity fairness across different flows is a function of the QoS

requirements of individual flows.

For BE flows, capacity fairness refers to data throughput fairness, ensuring that all BE

users receive a portion of the sector throughput proportional to the user's RF environment.

In this case, data throughput degradation due to system load increases is proportionally

spread across all BE flows.

For EF flows, capacity fairness refers to fairness in accordance with the priority of the

flow, where capacity is defined as the number of users that can be supported while

meeting their QoS requirements. For example, the VoIP capacity refers to the number of

VoIP users that can be supported in one sector.

As the system load increases beyond capacity, rather than spreading service degradation

across all users, as in the case of a BE user, an unequal degradation approach is more

desirable. Flows having the lowest priority are degraded first. To maintain the largest

number of EF flows and satisfy their QoS requirements within flows having same priority

level and similar QoS requirements, service degradation will start with the flows of the

users that experience less favorable RF conditions.

Air Interface Rev A Scheduler AlgorithmFlows

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

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

401-614-323Issue 16 October 2009

3-67

Page 228: 1xev-Do Rf Engineering

Multi-user packet

Rev A scheduler flexibility

After identifying the traffic data QoS class, the Rev A scheduler must find the optimum

packet size to be used for every slot, and determine whether a multi-user packet (MUP)

format is permitted.

Unlike Rev 0, where a one-to-one relationship between DRC value and forward-link

transmission format determines the packet size, span (maximum number slots in which

the packet is transmitted), and preamble chip length, the Rev A scheduler is permitted

greater flexibility in determining the packet size, span, and preamble chip length in

response to a DRC value. The transmission format selected in any instance is determined

by factors such as: delay requirement, payload size, traffic class, etc. This flexibility

allows the scheduler to maximize air capacity in accordance with the different QoS

criteria of the various flows vying for forward link transmission.

For each valid DRC index (in Rev A), one or more single-user and multi-user

transmission formats can be transmitted on the forward link. The transmission formats

associated with each DRC value are compatible with the DRC value.

Rev A-compatible ATs must be able to receive forward link transmission in any of the

single and multi-user formations associated with its directed-DRC value.

MUP packing

The scheduler can select up to eight users to share a Multi-User Packet (MUP), and

selects a transmission format common to the DRCs reported from all users. The MAC

Layer Header lists the MAC index for all users in a specific sequence. The data length for

each user is then sent in the same sequence, following a null transmission. Finally the

data is sent in the same sequence for each user. That packet may then be padded, if

necessary, followed by an end-of-packet code. Specific MAC Indexes (66 through 70) are

assigned to identify different MUP formats.

During session setup, the AT reports MUP compatibility. After the AT is assigned, it

begins FTC and DRC reporting, in addition to monitoring its own MAC index (based on

preamble and control channel preambles); it must monitor the MUP preambles that are

compatible with its reported DRC. The AT retrieves and validates all MUP-compatible

preambles from the FTC at the physical level. If the AT detects its MAC index, it extracts

its data from the packet. The R�C requires ACK from all MUP recipients for early

termination.

Changes Introduced by Rev A.AnAuxiliary Pilot Channel is added in Rev A to the Traffic

Channel in addition the Data Source sub-channel for seamless Forward Link cell

switching. Amore profound difference exists between the Rev 0 - Rev A operation of the

reverse link traffic channel than the forward link traffic channel. In the following text, the

Air Interface Rev A Scheduler AlgorithmMulti-user packet

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

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

3-68 401-614-323Issue 16 October 2009

Page 229: 1xev-Do Rf Engineering

Rev 0 reverse traffic channel is described first, followed by a brief discussion of its

limitations lending to the changes made in Rev A to mitigate these limitations. This is

followed by a detailed description of the changes made in Rev A.

Air Interface Rev A Scheduler AlgorithmMulti-user packet

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

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

401-614-323Issue 16 October 2009

3-69

Page 230: 1xev-Do Rf Engineering

Reverse Link Traffic Channel

Overview

Purpose

This section covers the reverse link traffic channel.

Contents

Introduction 3-71

Rev 0 Reverse Link Channel 3-72

Reverse Traffic Channel 3-74

Pilot/RRI and Ack channels 3-76

Data channel 3-77

Packet size and interleaver 3-79

Spreading 3-80

Reverse Link - Rev 0 limitations 3-81

Air Interface Reverse Link Traffic ChannelOverview

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

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

3-70 401-614-323Issue 16 October 2009

Page 231: 1xev-Do Rf Engineering

Introduction

General

The reverse channel structure consists of a Traffic Channel and an Access Channel as

shown in Figure 3-23, “Reverse Channel Structure” (p. 3-72). As in 3G-1X, both

1xEV-DO reverse channels provide uplink pilot sub channels (pulse bursts), permitting

coherent detection by the base station on the reverse link data from the AT. The Access

channel is divided into two sub-channel channels, which are:

• Pilot, for coherent demodulation at the base station

• Data, used by the AT to initiate uplink data transmission.

The traffic channel, which as with the forward channel is divided into four sub-channels,

is used to transmit user data and signaling information to the base station. The

sub-channels are the following:

• Pilot, for coherent demodulation at the base station

• Medium Access Control (MAC), which is further divided into two sub-channels for

transmission data rate control:

– Reverse Rate Indicator (RRI), which indicates to the base station the rate in which

uplink (reverse channel) data is transmitted

– Data Rate Control Data (DRC), which indicates to the base station the rate, and

from which sector downlink (forward channel) data is to be transmitted

• Acknowledge (ACK), acknowledges if downlink data is successfully or unsuccessfully

received.

Changes Introduced by Rev A

AnAuxiliary Pilot Channel is added in Rev A to the Traffic Channel in addition the Data

Source sub-channel for seamless Forward Link cell switching. Amore profound

difference exists between the Rev 0 - Rev A operation of the reverse link traffic channel

than the forward link traffic channel. In the following text, the Rev 0 reverse traffic

channel is described first, followed by a brief discussion of its limitations lending to the

changes made in Rev A to mitigate these limitations. This is followed by a detailed

description of the changes made in Rev A.

Air Interface Reverse Link Traffic ChannelIntroduction

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

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

401-614-323Issue 16 October 2009

3-71

Page 232: 1xev-Do Rf Engineering

Rev 0 Reverse Link Channel

Introduction

Rev 0 reverse link data is transmitted in successive 26.67-ms frames at five different data

rates from 9.6 kbps to 153.6 kbps, as indicated in Table 3-6, “Reverse Link Data Rates for

Traffic Data and Access Channels” (p. 3-72).

Reverse Channel Structure

The base station may allow an AT to transmit at a rate higher than 9.6 kbps. The AT

transmits a Reverse Rate Indicator (RRI) used by the base station to identify the rate in

which the AT is transmitting on the reverse data link. Depending on the total traffic

activity in the sector, the base station may allow an AT to transmit at a rate higher than

19.2 kbps.

Reverse Link Data Rates for Traffic Data and Access Channels

Table 3-6 Reverse Link Data Rates for Traffic Data and Access Channels

Characteristics Data Rate (kbps)

9.61 19.2 38.4 76.8 153.6

Bits per Packets 256 512 1024 2048 4096

Modulation Type BPSK BPSK BPSK BPSK BPSK

Code Rate 1/4 1/4 1/4 1/4 1/2

Figure 3-23 Reverse Channel Structure

TrafficChannel

ReverseChannels

AccessChannel

PilotChannel

MediumAccessControl

DataChannel ACK

PilotChannel

DataChannel

ReverseRate

Indicator

DataRate

Control

Air Interface Reverse Link Traffic ChannelRev 0 Reverse Link Channel

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

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

3-72 401-614-323Issue 16 October 2009

Page 233: 1xev-Do Rf Engineering

Table 3-6 Reverse Link Data Rates for Traffic Data and Access Channels

(continued)

Characteristics Data Rate (kbps)

9.61 19.2 38.4 76.8 153.6

P� Chips/Bit 128 64 32 16 8

Encoded Packet duration

(ms)

26.67 26.67 26.67 26.67 26.67

Notes:

1. This column is also applicable to the access channel

Air Interface Reverse Link Traffic ChannelRev 0 Reverse Link Channel

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

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

401-614-323Issue 16 October 2009

3-73

Page 234: 1xev-Do Rf Engineering

Reverse Traffic Channel

Generation of Reverse Traffic Channel

The generation of reverse traffic channels is illustrated in Figure 3-24, “Generation of

Reverse Traffic Channel” (p. 3-74). This figure is a simplified diagram, and to conserve

space, certain details that will be narrated in text have been omitted.

Figure 3-24 Generation of Reverse Traffic Channel

Air Interface Reverse Link Traffic ChannelReverse Traffic Channel

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

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

3-74 401-614-323Issue 16 October 2009

Page 235: 1xev-Do Rf Engineering

Reverse Traffic Sub-Channels

Unlike the forward channel that uses time multiplexing to separate its four sub-channels,

the four sub-channels that make up the reverse traffic channel are separated by Walsh

code spreading at a fixed chip rate of 1.2288 Mcps. The exceptions to this are the Pilot

and RRI sub-channels, which are time-multiplexed on the same sub-channel as shown in

Figure 3-25, “Reverse Traffic Sub-Channels” (p. 3-75).

Figure 3-25 Reverse Traffic Sub-Channels

Air Interface Reverse Link Traffic ChannelReverse Traffic Channel

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

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

401-614-323Issue 16 October 2009

3-75

Page 236: 1xev-Do Rf Engineering

Pilot/RRI and Ack channels

Pilot/RRI Channel

The Pilot channel, which is all 0 bits, is 7-to1, pilot-to-RRI, time division-multiplexed

(TDM) with a 256-bit value representing the Reverse Rate Indicator (RRI) value. The

actual RRI value is a 3-bit symbol identifying the five reverse traffic data rates. To

provide for the 256-chip spreading of this value, prior to 7-to-1, the 3-bit RRI symbol is

converted to one of five 7-bit values, which is repeated 37 times to generate a 259-bit

pattern. The last three bits of this bit pattern are punctured (truncated) to provide a 256-bit

pattern which is selected by the 7:1 TDM at the start of each slot clock period (see Figure

3-24, “Generation of Reverse Traffic Channel” (p. 3-74)). At the end of the first 256-chip

period, the 7:1 TDM selects all 0 bits from the Pilot channel until the end of the slot clock

period. The pilot/RRI-multiplexed channel is then spread by 16-chip Walsh code function

W0.

ACK Channel

The pilot/RRI-multiplexed channel is summed with the ACK channel to form in-phase (I)

quadrature input for quadrature spreading. A single bit signal is transmitted on the ACK

channel indicating, when 0, that slot data transmitted from the base station is successfully

received. A 1-bit value identifies a negative acknowledge (�AK) to indicate that the data

received by the base station is corrupted.

The ACK signal received by the base station is a 1024-chip burst transmitted during the

first half of the third slot clock period after the slot data is received from the base station.

The ACK signal is generated to acknowledge the validity of only those data packets that

are proceeded by a preamble directed to the AT. If an associated preamble is not detected,

the ACK signal is gated off. To cover 1024-chip burst half slot-clock period, the one-bit

ACK signal is first repeated 128 times by the X128 repeater, producing a 128-bit pulse

burst, which is spread by 16-chip Walsh function code W8 prior to being scaled by the

ACK channel relative gain control. Here, the amplitudes of the ACK pulses are scaled

relative the amplitude of the pilot pulses. The scaling factor for the chip sequence is

specified by gain parameters as a function of the MAC protocol.The output of the ACK

channel relative gain control is then summed with the pilot/RRI channel data to provide

the in-phase I component for quadrature spreading.

Air Interface Reverse Link Traffic ChannelPilot/RRI and Ack channels

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

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

3-76 401-614-323Issue 16 October 2009

Page 237: 1xev-Do Rf Engineering

Data channel

Data Rate Control (DRC) Channel

In response to carrier-to-interference (C/I) measurements of the pilot pulses from all

available sectors that are continuously monitored by active ATs, each AT computes a 4-bit

DRC value. This value, which identifies the highest data rate that the AT can receive data

from a particular sector, is converted to an 8-bit DRC code word and sent to the base

stations to identify the rate in which forward channel data is to be transmitted. The sector

that could best serve the AT at the specified data rate is computed by the MAC layer, and

is indicated by a 3-bit DRC Cover Symbol.

The 8-bit DRC code word is repeated twice by the DRC code word repeater to produce a

16-bit symbol that is spread by the 8-ary Walsh function IW8 , where i is a value between 0

and 7 selected by the 3-bit DRC Cover Symbol at the input of the sector identifier. As a

result, the 16-bit symbol is spread to a 128-bit chip sequence. To cover a 2048-chip time

slot, the 128-chip sequence is further spread to a 2048-chip sequence by the 16-ary Walsh

function W16. The amplitude of the resulting chip sequence is scaled via the DRC channel

relative gain control, by a factor relative to the amplitude of the Pilot chip sequence. The

scaling factor for the chip sequence is specified by gain parameters as a function of the

MAC protocol.

Data Channel

The bit size of the reverse traffic data channel packets transmitted to the base station is a

function of the transmit data rate. The reverse traffic channel information data rate

incrementally doubles from 9.6 kbps to 153.6 kbps (see Table 3-7, “Relationship Between

Physical Layer Packet Bit Size and Code Symbol Bit Size at Different Data Rates”

(p. 3-77)). This is the rate in which information data is sent to the base station and should

not be confused with the transmitted chip rate, which is 1.2288 Mcps.

Table 3-7 Relationship Between Physical Layer Packet Bit Size and Code Symbol

Bit Size at Different Data Rates

Data Rate

(kbps)

Physical

Layer

Packet Bit

Size

Reverse

Rate IndexCode Rate

Code

Symbols

per Packet)

Code

Symbol

Rate (kbps)

Interleave

Repeat

Rate

Modulation

Symbol

Rate (kbps)

PN Chip

per Packet

bit

9.6 256 1 1/4 1024 38.4 8 307.2 128

19.2 512 2 1/4 2048 76.8 4 307.2 64

38.4 1024 3 1/4 4096 153.6 2 307.2 32

76.8 2048 4 1/4 8192 307.2 1 307.2 16

153.6 4096 5 1/2 8192 307.2 1 307.2 8

Air Interface Reverse Link Traffic ChannelData channel

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

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

401-614-323Issue 16 October 2009

3-77

Page 238: 1xev-Do Rf Engineering

Data bit redundancy

It should be remembered that data bit redundancy is used to insure reliable information

transmission. For example, when transmitting at the 9.6 kbps data, which identified as

reverse rate index 1, the 256-bit packet is spread by undergoing the following:

1. Turbo encoding at a 1/4 code rate, producing 1024 (4 X 256) code symbols that are

clocked at a 38.4 kbps (4 X 9.6) code symbol rate

2. Interleave packets are repeated effectively multiplying the 1024 symbols by a factor

of 8 (8,192), producing a modulation symbol rate of 307.2 kbps (8 X 38.4)

3. Spread by 4-chip Walsh code function W4, producing four chips per symbol which is

clocked at the 1.2288-Mcps (4 X 307.2 kbps) chip rate.

In accordance with the information given in Table 3-7, “Relationship Between Physical

Layer Packet Bit Size and Code Symbol Bit Size at Different Data Rates” (p. 3-77), at the

9.6 kbps data rate, the number of P� chips per Physical Layer packet is 128. This number

is obtained by dividing the 1.2288-Mcps chip rate by the 9.6 kbps data rate. This data rate

is the slowest data rate on the reverse channel. Typically, the AT will start out transmitting

at this data rate to ensure that the base station can acquire the AT, regardless of the current

RF environmental conditions. If the conditions are favorable, the AT is permitted to

transmit at a higher data rate. Although the 1.2288 Mcps chip rate remains the same

regardless of the data rate, as shown in Table 3-7, “Relationship Between Physical Layer

Packet Bit Size and Code Symbol Bit Size at Different Data Rates” (p. 3-77) for data rate

index numbers 2, 3, and 4, higher data rates are achieved by reducing packet interleave

repeat rates to 4, 2, and 1, respectively. At the same time, to offset the reduction of

interleave packet repeat rate, the Physical Layer packet doubles for each in increasing

data rates from 512 to 1024, and from 1024 to 2048. Because the data is transmitted at the

1.2288-Mcps rate, as the Physical Layer packet size increases, the number of chips per

bits is reduced, increasing the transmit data rate. At reverse rate index 5, the turbo code

rate is reduced from 1/4 to 1/2 allowing the packet size to be increase from 2048 to 4096,

thereby doubling the data rate.

Air Interface Reverse Link Traffic ChannelData channel

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

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

3-78 401-614-323Issue 16 October 2009

Page 239: 1xev-Do Rf Engineering

Packet size and interleaver

Physical Layer Packet Size

As the transmit data rate incrementally doubles from 9.6 kbps to 153.6, the MAC Layer

packet bit size used to construct the physical traffic data packet also incrementally

doubles from 234 to 4074 as shown in Figure 3-26, “Reverse Traffic Data Channel

Physical Layer Packet Bit Size” (p. 3-79). A single Frame Check Sequence (FCS) is

calculated regardless of the MAC Layer packet bit size used to construct the Physical

Layer packet. The FCS calculation results in a 16-bit CRC value, which is tacked on to

end of the Physical Layer packet just before the 6 tail bits.

Turbo Encoder/Interleaver

Except for when the 153.6 kbps data rate is used, the content of the data channel is

encoded at a 1/4 code rate by the turbo encoder/interleaver. When the 153.6 kbps data rate

is used, the content of the data channel is encoded at a 1/2 code rate. The turbo encoder,

which was introduced for 3G-1X, is a redundant encoder, producing four output bits for

every input bit when operating at a 1/4 code rate.

The redundancy rate is reduced to two output bits for each input bit when operating at a

1/2 code rate. Thus, the turbo encoder will double and quadruple the bit size of the

transmitted data. The relationship between the Physical Layer data packet bit size and the

resulting code symbol bit size for each transmit data rate is given in Table 3-7,

“Relationship Between Physical Layer Packet Bit Size and Code Symbol Bit Size at

Different Data Rates” (p. 3-77). The redundancy provided by the turbo encoder enables

the base station to reconstruct the received data when a small number of bits sporadically

distributed throughout the received bit pattern are corrupted. To minimize the influence of

RF noise spikes or shadow fading that will corrupt large clusters of bits from preventing

bit pattern reconstruction at the base station, the turbo-encoded bit pattern is interleaved.

Interleaving will pseudo-randomly scramble bit patterns at the output of the turbo

encoder/interleaver. Prior to bit-pattern reconstruction at the base station, the received bits

are unscrambled. As a result, if any large cluster of bits was corrupted during

transmission, the unscrambling process will sporadically distribute the corrupted bits

throughout the received bit pattern, enabling the reconstruction of the receive bits.

Figure 3-26 Reverse Traffic Data Channel Physical Layer Packet Bit Size

Air Interface Reverse Link Traffic ChannelPacket size and interleaver

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

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

401-614-323Issue 16 October 2009

3-79

Page 240: 1xev-Do Rf Engineering

Spreading

Walsh Code Spreading

The output of the turbo encoder/interleave (see Figure 3-24, “Generation of Reverse

Traffic Channel” (p. 3-74)) is spread by 4-chip Walsh code function W4, and the

amplitude of the resulting chip sequence is scaled, via the data channel relative gain

control, by a factor relative to the amplitude of the Pilot chip sequence. The scaling factor

for the chip sequence is specified by gain parameters as a function of the MAC protocol.

The output of the data channel relative gain control is summed with the DRC chip

sequence at the output of the DRC channel relative gain control to provide the Q input for

quadrature spreading.

Quadrature Spreading

The I resultant from combining the pilot and the ACK channel chip sequences and the Q

resultant from combining the DRC and data channel chip sequences are

quadrature-spread by providing a 90-degrees phase shift between the I and Q

components. Prior to phase shifting, a complex multiplication operation is performed to

identify the user AT by cross-multiplying the channel I and Q component with the I and Q

components of the long and short P� codes. The product is a complex number, having a

real part and an imaginary part that are 90 degrees apart, as shown below:

The P� I and P� Q chip sequences are generated by multiplying the AT I and Q channel

short code sequences with the I and Q channel user long code sequences. The Q product

of this multiplication is modified by replacing every other bit in the sequence with the

reciprocal of the bit preceding it, and then multiplying the result by P� I. This is done by

decimating ever other chip in Q chip sequences and replacing the decimated chip with the

value of the chip preceding it. Therefore, the decimator provides an output sequence that

is constant for every two consecutive chips. The decimator output is then multiplied by

two factors. First, the sequence is multiplied by Walsh function W2 to invert every other

chip. Then this product is multiplied by the P� I chip sequence to produce the P� Q chip

sequence for complex multiplication. The complex multiplication output I' and Q'

products are then, respectively, multiplied by the cosine and sine functions of the 1.2288

Mcps chip rate (fc) to produce the in-phase and quadrature-phase spreading. The

quadrature-spread products are summed to form the reverse traffic channel which is

modulated and applied to the AT antenna.

Air Interface Reverse Link Traffic ChannelSpreading

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

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

3-80 401-614-323Issue 16 October 2009

Page 241: 1xev-Do Rf Engineering

Reverse Link - Rev 0 limitations

Introduction

1xEV-DO Rev 0 is optimized for data service with a significantly higher forward

throughput than reverse throughput. The peak forward data rate is 2.4 Mbps compared to

a 153.6 kbps reverse data rate. Although experience with Internet usage indicates an

asymmetrical download/upload pattern favoring downloading, as the user of the Internet

matures, greater demands for higher uploading speeds are realized. Certain Internet

activities requiring higher uploading throughput are ftp, email, graphic transmissions,

gaming, etc.

To provide higher reverse data rates, Rev A is designed to overcome the following Rev 0

Limitations.

Long Rate Response Time

When the RF conditions are improved, the Rev 0 AT must wait up to one frame time

(26.67 ms) before the AT can increase its reverse link data rate to take advantage of the

improved RF environment. Conversely, if the RF conditions worsen, it may take up to

26.67 ms before the AT reduces its data rate, possibly causing retransmission delays. Rev

A divides the 16-slot frames into four four-slot sub-frames, reducing the maximum rate

transition time from 26.67 ms to 6.67 ms.

No Early Termination Feature

Unlike the forward link, the Rev 0 reverse link does not use incremental redundancy to

provide early termination. Early termination reduces the time it may take to transmit a

packet of data when RF conditions improve.

Low Number of Fixed Packet Sizes

Rev 0 uses only five different reverse link packet sizes, providing low packing efficiency,

constraining the AT to use the next lager packet size to transmit its message. For example,

if the AT wants to transmit a 90-bit message, the AT would be forced to send the message

in a 256-bit packet, which uses more air-interface capacity than may be required. The Rev

A Physical Layer provides a greater number of packet sizes and new data rates, which

improve the packing efficiency and consequently increase the air-interface capacity in

both the reverse and forward link comparing to Rev 0.

Single MAC Flow

Rev 0 provides only one AT MAC flow, preventing the implementation of intra-QoS

control.

Air Interface Reverse Link Traffic ChannelReverse Link - Rev 0 limitations

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

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

401-614-323Issue 16 October 2009

3-81

Page 242: 1xev-Do Rf Engineering

Implicit Interference Control

The RF conditions at the AT are implied by its reverse rate indication (RRI); however, the

R�C cannot reliably predict the amount of interference created by the AT.

The Rev A reverse channel provides flexible packet length and structure with packet sizes

from 128 bits to 12288 bits, and new Physical Layer packet types and data rates from 4.8

kbps (Rev 0 minimum rate is 9.6 kbps) and up to 1843.2 kbps (Rev 0 highest rate is 153.6

kbps).

Air Interface Reverse Link Traffic ChannelReverse Link - Rev 0 limitations

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

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

3-82 401-614-323Issue 16 October 2009

Page 243: 1xev-Do Rf Engineering

Changes introduced in Rev A

Overview

Purpose

The following is a detailed description of the changes made in Rev A to mitigate the

limitations identified in the previous section.

Contents

Sub-frames 3-84

Reverse link incremental redundancy 3-87

Maximum 4 sub-frame duration 3-89

Reverse link payload size and modulation 3-90

Reverse link data rate selection 3-92

T2P Target Level Request and Grant 3-93

Reverse data rate selection 3-95

MAC subtype 3 3-96

Low-latency power boost transmission 3-97

Auxiliary Pilot channel 3-98

Rev 0 Access and Data channels 3-99

Rev A Enhanced Access Channel 3-101

Data rates and pilot channel 3-103

Air Interface Changes introduced in Rev AOverview

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

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

401-614-323Issue 16 October 2009

3-83

Page 244: 1xev-Do Rf Engineering

Sub-frames

Introduction

One of the more significant changes in the Rev A reverse channel is to divide the 16-slot

frame into four 4-slot sub-frames, as shown in Figure 3-27, “Sub-frame structure”

(p. 3-85). The introduction of sub-frames, which are only implemented in MAC Subtype

3, allows:

• Transmit packets to also be divided into four sub-packets to provide incremental

redundancy, allowing early termination to increase reverse link throughput

• Quicker reverse link data rate transition response to rapid changes in RF conditions

Sub-frame structure

To provide incremental redundancy when more than one packet is to be transmitted, a

three sub-frame interlace pattern is used. This means that the transmission of three

separate packets is performed in an alternating sequence, as shown in Figure 3-27,

“Sub-frame structure” (p. 3-85). In this scheme, each packet allotted for sub-frame

transmission is transmitted every third slot. The two time-slot spacing between successive

packet slot transmissions is required to allow the AT to receive confirmation from the

BTS regarding whether it was successful in validating the correctness of the packet data it

received. In addition to the data channel, the RRI, DRC, DSC, ACK, pilot, and, if

required, the auxiliary pilot channels are also transmitted within the sub-frame. Except for

the DRC channel, these channels are coded on the I quadrature phase, as shown in Figure

3-28, “Reverse link channel coding – I-Phase” (p. 3-86). The packet payload size and the

sub-packet ID is sent to the BTS via the Reverse Rate Indicator (RRI) channel, and the

ACK and DSC channels are time-multiplexed.

Air Interface Changes introduced in Rev ASub-frames

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

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

3-84 401-614-323Issue 16 October 2009

Page 245: 1xev-Do Rf Engineering

Figure 3-27 Sub-frame structure

Frame = 16 Slots, 26.67 ms

4-Slot Sub-Frame6.67 ms

1.67 ms

4-Slot Sub-Frame6.67 ms

4-Slot Sub-Frame6.67 ms

4-Slot Sub-Frame6.67 ms

Sub-Packet 2, Packet 1 Sub-Packet 1, Packet 2 Sub-Packet 1 Sub-Packet 1, Packet 1, Packet 3

RR1

Data Channel

DRC Channel

Auxiliary Pilot ChannelPilot Channel

ACKACKACKACK DSCDSCDSCDSC

1 Slot

66.7 ms

16-Slot Frame26.67 ms

Packet 1

Packet 3 Not Acknowledge

Acknowledge

NAK

ACK

Frame/slotreference

Traffic orAccesschannel

FrowardAutomatic

Repeat Request(H-ARQ)channel

FrowardAutomatic

Repeat Requestchannel(L-ARQ)

FrowardAutomatic

Repeat Requestchannel(P-ARQ)

n n+1 n+2 n+3 n+4 n+5 n+6 n+8 n+9 n+10 n+11 n+12 n+1n+7

Maximum Four Sub-Frame Duration

Air Interface Changes introduced in Rev ASub-frames

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

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

401-614-323Issue 16 October 2009

3-85

Page 246: 1xev-Do Rf Engineering

Reverse link channel coding – I-Phase

Rather than waiting a full 16-slot frame (26.67 ms) before allowing the AT to adjust its

transmit data rate either up or down, the four 4-slot sub-frames allow the AT to adjust its

transmit data rate every 4-slot period (6.67 ms). Quicker reverse data rate transition

response in a rapidly changing RF environment can significantly improve reverse link

throughput.

Figure 3-28 Reverse link channel coding – I-Phase

DSC

RRI

ACK

Pilot

Data ( I )

16

4W

16

0W

32

12W

32

12W

AuxiliaryPilot

32

28W

ACK Gain

DSC Gain

RRI Gain

Data Gain

AuxiliaryPilotGain

TDM

SummingNetwork

I

Air Interface Changes introduced in Rev ASub-frames

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

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

3-86 401-614-323Issue 16 October 2009

Page 247: 1xev-Do Rf Engineering

Reverse link incremental redundancy

Reverse link incremental redundancy diagram

To simplify this discussion, Figure 3-29, “Reverse link incremental redundancy” (p. 3-87)

shows the reverse link transmission of Packets 1, 2, and 3 in every third sub-frame. It

should be noted that other packets are interlaced with Packets 1, 2, and 3, and that

numbering of these packets is for identification and does not indicate the sequence of

transmission.

Figure 3-29 Reverse link incremental redundancy

4-Slot Sub-Frame6.67 ms

16-Slot Frame26.67 ms

Packet 1

Packet 2

Packet 3

Not Acknowledge

Acknowledge

NAK

ACK

Frame/slotreference

Traffic orAccesschannel

FrowardAutomatic

Repeat Requestchannel (H-ARQ)

Early Termination

Air Interface Changes introduced in Rev AReverse link incremental redundancy

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

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

401-614-323Issue 16 October 2009

3-87

Page 248: 1xev-Do Rf Engineering

ACK

The acknowledge signal (ACK), or its negated �ot Acknowledge signal (�AK),

transmitted over the Automatic Repeat Request (ARQ) forward link channel is coded into

three signals:

• Hybrid ARQ (H-ARQ), set by the BTS in response to the first, second, and third

sub-packet transmission

• Last ARQ (L-ARQ), set by the BTS in response to the fourth sub-packet transmission

• Packet ARQ (P-ARQ), set by the BTS in the recovery of the entire physical layer

packet; the L-ARQ and P-ARQ are illustrated in Figure 3-30, “Maximum four

sub-frame duration” (p. 3-89)

After each sup-packet is transmitted (for MAC Subtype 3), the AT receives either an ACK

or �AK response that is transmitted from the BTS via the Automatic Repeat Request

(ARQ) forward link channel. If a �AK signal is received after its associated sub-packet is

transmitted, indicating that the BTS is unable to discern the full packet information, the

next sub-packet is transmitted. If an ACK response is received, the first sub-packet of the

next packet in the transmit sequence is transmitted.

After the first two sub-packets of Packet 1 in Figure 3-29, “Reverse link incremental

redundancy” (p. 3-87) are transmitted, an ACK response is received, resulting in early

termination. Subsequently, an ACK reply is received after the first sub-packet of Packet 2,

resulting in early termination after the first sub-packet is sent.

Air Interface Changes introduced in Rev AReverse link incremental redundancy

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

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

3-88 401-614-323Issue 16 October 2009

Page 249: 1xev-Do Rf Engineering

Maximum 4 sub-frame duration

Description

When the maximum four-sub-frame duration is required, an L-ARQ response is received

in place of the H-ARQ signal. Regardless of if the packet is terminated early, the packet is

transmitted in the maximum for sub-frame period; A P-ARQ acknowledgment status is

transmitted during the occurrence of the twelfth sub-frame (n+12) after the first

sub-packet is transmitted.

Maximum four sub-frame duration diagram

Figure 3-30 Maximum four sub-frame duration

16-Slot Frame26.67 ms

Packet 1

Packet 3 Not Acknowledge

Acknowledge

NAK

ACK

Frame/slotreference

Traffic orAccesschannel

ForwardAutomatic

Repeat Request(H-ARQ)channel

ForwardAutomatic

Repeat Requestchannel (L-ARQ)

ForwardAutomatic

Repeat Requestchannel (P-ARQ)

n n+1 n+2 n+3 n+4 n+5 n+6 n+8 n+9 n+10 n+11 n+12 n+1n+7

Maximum Four Sub-Frame Duration

Air Interface Changes introduced in Rev AMaximum 4 sub-frame duration

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

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

401-614-323Issue 16 October 2009

3-89

Page 250: 1xev-Do Rf Engineering

Reverse link payload size and modulation

Description

The following discussion applies to MAC Subtype 3. Incremental redundancy and the

AQR channel from the BTS is not used in lower MAC subtypes where the highest data

rate is 153.6 kbps.

Reverse link data may be transmitted in one of 12 payload sizes in 1, 2, 3 or 4 four-slot

sub-frames, as shown in Table 3-8, “Reverse link payload size and modulation” (p. 3-90).

The modulation associated with each payload size is identified in Table 3-9, “Modulation

code” (p. 3-91). The more favorable the RF environment, the sooner early termination

occurs (after the third, second, or first sub-frame). This effectively increases the data rate

and reduces the repetition rate.

Support of the first 11 payload sizes, resulting in a maximum reverse link data rate of

1.228 Mbps, is mandatory. Support of the twelfth, 12288 bits, yielding a 1.8432-Mbps

data rate is optional.

Reverse link payload size and modulation diagram

Table 3-8 Reverse link payload size and modulation

Payload

Size

(bits)

Modu-

lation

Effective Data Rate (kbps) Code Rate [Repetition]

After 4

Slots

After 8

Slots

After

12

Slots

After

16

Slots

After 4

Slots

After 8

Slots

After

12

Slots

After

16

Slots

128 B4 19.2 9.6 6.4 4.8 1/5 [3.2] 1/5 [6.4] 1/5 [9.6] 1/5

[12.8]

256 B4 38.4 19.2 12.8 9.6 1/5 [1.6] 1/5 [3.2] 1/5 [4.8] 1/5 [6.4]

512 B4 76.8 38.4 25.6 19.2 1/4 [1] 1/5 [1.6] 1/5 [2.4] 1/5 [3.2]

768 B4 115.2 57.6 38.4 28.8 3/8 [1] 1/5

[1.07]

1/5 [1.6] 1/5

[2.13]

1024 B4 51.2 153.6 76.8 38.4 1/2 [1] 1/4 [1] 1/5 [1.2] 1/5 [1.6]

1536 Q4 230.4 115.2 76.8 57.6 3/8 [1] 1/5

[1.07]

1/5 [1.6] 1/5

[2.13]

2048 Q4 307.2 153.6 102.4 76.8 1/4 [1] 1/5 [1] 1/5 [1.2] 1/5 [1.6]

3072 Q2 460.8 230.4 153.6 115.2 3/8 [1] 1/5

[1.07]

1/5 [1.6] 1/5

[2.13]

4096 Q2 614.4 307.2 204.8 153.6 1/2 [1] 1/4 [1] 1/5 [1.2] 1/5 [1.6]

Air Interface Changes introduced in Rev AReverse link payload size and modulation

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

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

3-90 401-614-323Issue 16 October 2009

Page 251: 1xev-Do Rf Engineering

Table 3-8 Reverse link payload size and modulation (continued)

Payload

Size

(bits)

Modu-

lation

Effective Data Rate (kbps) Code Rate [Repetition]

After 4

Slots

After 8

Slots

After

12

Slots

After

16

Slots

After 4

Slots

After 8

Slots

After

12

Slots

After

16

Slots

6144 Q4Q2 921.6 460.8 307.2 230.4 1/2 [1] 1/4 [1] 1/5 [1.2] 1/5 [1.6]

8192 Q4Q2 1228.8 614.4 409.6 307.2 2/3 [1] 1/3 [1] 2/9 [1] 1/5 [1.2]

12288 E4E2 1843.2 921.6 614.4 460.8 2/3 [1] 1/3 [1] 1/3 [1.5] 1/3 [2]

Modulation code

Table 3-9 Modulation code

ModulationCode Modulation

B4 BPSK modulation with 4-ary Walsh cover

Q4 QPSK modulation with 4-ary Walsh cover

Q2 QPSK modulation with 2-ary Walsh cover

Q4Q2 Sum of Q4 and Q2 modulated symbols

E4 8-PSK modulation with 4-ary Walsh cover

E2 8-PSK modulation with 2-ary Walsh cover

E4E2 Sum of E4 and E2 modulated symbols

RRI channel

A significant change in the MAC subtype 2 should be noted. In Rev 0, the pilot channel is

7 to 1 time-multiplexed within each slot-clock period with the Reverse Rate Indicator

(RRI) value, as shown inFigure 3-25, “Reverse Traffic Sub-Channels” (p. 3-75). The RRI

value is used by the base station to identify the rate in which the AT is transmitting on the

reverse data link.

In Rev A, the RRI Channel is used by the AT to indicate the payload size and sub-packet

identifier of the physical layer packet transmitted on the Traffic Channel. Therefore, this

data identifies the effective transmit data rate, its code rate and repetition rate. The

transmitted payload size is a 4-bit symbol and the sub-packet identifier is a 2-bit symbol.

From this, a combined 6-bit RRI symbol is formed, representing the payload size and the

sub-packet identifier. For backward compatibility, the BTS also supports the Rev 0 RRI

channel configuration.

Air Interface Changes introduced in Rev AReverse link payload size and modulation

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

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

401-614-323Issue 16 October 2009

3-91

Page 252: 1xev-Do Rf Engineering

Reverse link data rate selection

Description

As in Rev 0, the Rev AAT is capable of opening more than one session at a time.

However in Rev 0, the AT had no way of assigning priority to its sessions, and

consequently transmitting the reverse data independently of the session priority at a date

rate solely governed by the current RF conditions at the BTS. The reverse transmission

starts at a low data rate even though the RF conditions at the BTS allow for a higher data

rate. The data rate gradually increases to the full rate allowed by the BTS loading

conditions. When the BTS becomes heavily loaded, the AT receives a Reverse Activity

Bit (RAB) from the BTS, and, based on a probability matrix, may drastically reduce its

transmitting data rate. This gradual increase in data rate to the BTS load capacity

introduces another latency factor that cannot be tolerated in Rev A.

Intra-AT QoS operation

Unlike its predecessor, multi MAC flows, permitted in Rev A, allow intra-AT QoS

operation. Each session conducted through a Rev AAT is a separate MAC flow, having

data rate scheduling commensurate with its QoS. Rather than relying solely on the

instantaneous value of the RAB bit and a probability matrix, the Rev AAT uses a

Traffic-to-Pilot (T2P) ratio to help govern the data rate of each flow. The T2P is a power

budget allocation obtained from the BTS for each flow based on its QoS and the AT's

capabilities. The T2P allocation for each flow is negotiated between the AT and the

Subtype 2 Reverse Traffic Channel MAC protocol running on the R�C.

Air Interface Changes introduced in Rev AReverse link data rate selection

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

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

3-92 401-614-323Issue 16 October 2009

Page 253: 1xev-Do Rf Engineering

T2P Target Level Request and Grant

Description

At call setup, the AT sends a Request message to the R�C via the BTS, identifying its

capability and the QoS requirements for a session being set up (see Figure 3-31, “T2P

Target Level Request and Grant” (p. 3-93)). In this message, the AT includes the

maximum T2P level it can transmit, the amount of data (queue length) to be transmitted,

and an assigned MAC flow identifying (ID) number. The AT can have up to 16

simultaneous flows, each identified by its MAC flow ID. The R�C responds with a Grant

message, allocating a T2PInflow power budget level for the flow, which is its T2P target

value, along with two other parameters to control the flow data rate which are

BucketLevel values and TT2PHold. The BucketLevel is an 8-bit value expressed to a 0.25

dB resolution and indicates the level of accumulated T2P resource. The T2P resource

allows users with bursty traffic to transmit at high data rate when needed. The TT2PHold

is a 4-bit value, indicating the time interval that the AT must wait after the Grant message

is received before the AT is allowed to change the T2PInflow value.

Target Level Request and Grant diagram

Figure 3-31 T2P Target Level Request and Grant

Request Message

Grant Message

MAC Flow ID, Queue Length, Maximum T2P

MAC Flow IDs, TT2P Hold, BucketLevel

Reverse Link Transmit Data

Traffic Channel

Payload Size and Sub-Frame

RRI Channel

Air Interface Changes introduced in Rev AT2P Target Level Request and Grant

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

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

401-614-323Issue 16 October 2009

3-93

Page 254: 1xev-Do Rf Engineering

Grant message

The Grant message uses the AT-assigned MAC flow ID number to identify the flow. If

the AT is currently involved in more than one flow, the Grant message may include

parameters for the other flows. After the first call is set up and the AT remains in the

active state, autonomous transmissions of Grant messages occur. The AT is required to

update its parameter values to the new values received in the most current Grant message.

Air Interface Changes introduced in Rev AT2P Target Level Request and Grant

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

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

3-94 401-614-323Issue 16 October 2009

Page 255: 1xev-Do Rf Engineering

Reverse data rate selection

Description

Data rate selection is performed by the AT; that AT selects a payload size so that its

average transmit power is equal to the level indicated by the T2PInflow level allocation.

In this way the initial transmit power level is within the margin provisioned by the R�C.

After the TT2PHold period expires, the AT is free to adjust the T2PInflow value, and

hence, its transmit data rate, up or down in accordance with the loading conditions at the

BTS. The AT creates two transition parameters: a short-term quick RAB (QRAB) and a

long-term frame RAB (FRAB) from the RAB bit received from each sector in its active

set.

RAB

The reliability of the RAB bit, describe for Rev 0, is improved by filtering. A short-term

filter followed by a threshold detector is used at the AT to generate the QRAB which

indicates instantaneous sector loading. A long-term filter is used to generate the FRAB

which indicates longer-term sector loading.

In the AT, an algorithm is performed to generate a SoflRAB value, which is a

continuously varying value, representing the RAB bit trend from all the sectors in the AT

active set. IIR filters with short-term and long-term constants are then used to determine

the QRAB and FRAB values, respectively.

Flow level adjustment

When BTS loading increases, the T2PInflow level is adjusted downward, and when the

BTS loading decreases, the T2PInflow level is adjusted upward.

Air Interface Changes introduced in Rev AReverse data rate selection

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

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

401-614-323Issue 16 October 2009

3-95

Page 256: 1xev-Do Rf Engineering

MAC subtype 3

Mechanism for T2P power allocation

The mechanism for T2P power allocation in MAC subtypes 2 and 3 are very similar. The

principle difference is that MAC Subtype 3 permits:

• Higher data rates (1.2 Mbps maximum, or 1.8 Mbps optional)

• Two transmission modes (high-capacity, or low-latency)

• H-ARQ incremental redundancy (as previously discussed)

• Auxiliary Pilot channel for higher data rates

The higher data rates are achieved through early termination. As incremental redundancy

is not permitted with MAC Subtype 2, the highest data rate that can be achieved in this

MAC subtype is 153.6 kbps.

T2PInflow values assigned to a MAC flow

Because two reverse link transmission modes (high-capacity, or low-latency) are

available, two T2PInflow values can be assigned to a MAC flow. The transmission mode

used is a function of its driving application. The high capacity mode is similar to the

transmission mode used in MAC Subtype 2 and is used in applications where

high-latency tolerance is permitted. The low-latency mode is used for low-latency tolerant

flow. In this mode, a higher T2PInflow target is used to encourage early termination. The

value set for the T2PInflow is selected for the low-latency mode to achieve a termination

target, which is a value between 1 and 3 and is the number of sub-frames used to transmit

a packet.

Air Interface Changes introduced in Rev AMAC subtype 3

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

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

3-96 401-614-323Issue 16 October 2009

Page 257: 1xev-Do Rf Engineering

Low-latency power boost transmission

Power boost transmission

Power boost transmission is permitted in the low-latency mode to further decrease latency

by encouraging early termination. When power boost is used, transmission of the

four-sub-packet parcel is divided into a pre-transmission and post-transmission periods.

Usually the first two sub-packets are in the pre-transmission period and the last two

sub-packets are in the post-transmission period. To encourage early termination, the T2P

level of sub-packets in the pre-transmission period is boosted. Figure 3-32, “Low-latency

power boost transmission” (p. 3-97) shows the power levels of four sub-packets

transmitted to the BTS. For this illustration, early termination does not occur.

Low-latency power boost transmission diagram

Figure 3-32 Low-latency power boost transmission

4-Slot Sub-Frame6.67 ms

Normal Transmission

Power Boost Transmission

Pre-Transmission PeriodPre-Transmission Period

T2P

T2P

Air Interface Changes introduced in Rev ALow-latency power boost transmission

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

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

401-614-323Issue 16 October 2009

3-97

Page 258: 1xev-Do Rf Engineering

Auxiliary Pilot channel

Description

AnAuxiliary Pilot channel is provided in Rev A to improve coherent detection of the

higher data rates received by the BTS. At higher reverse link data rates, defined by

translation values, the AT transmits an auxiliary pilot along with the regular pilot channel.

The auxiliary pilot signal provides additional reference timing for coherent demodulation.

The gain of the Auxiliary Pilot signal is configurable to the payload size. When the

Auxiliary Pilot signal is used, both pilot signals are transmitted continuously on the I

channel (see Figure 3-33, “Auxiliary Pilot channel” (p. 3-98)).

Auxiliary Pilot channel diagram

Figure 3-33 Auxiliary Pilot channel

Pilot Channel(all 0’s)

Axillary PilotChannel (all 0’s)

Axillary Pilotrelative gain

Signal pointmapping0 +11 -1

Signal pointmapping0 +11 -1

W0

16

W28

32

= (+++++++++++++++++)

= ( )+ + + + - - - - - - - - + + + + - - - - + + + + + + + + - - - -

1.2288 Mcps

1.2288 Mcps

Air Interface Changes introduced in Rev AAuxiliary Pilot channel

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

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

3-98 401-614-323Issue 16 October 2009

Page 259: 1xev-Do Rf Engineering

Rev 0 Access and Data channels

Rev 0 Access Channel

The access channel data is transmitted by the AT to either initiate communication with the

radio access network (RA�) or to respond to a message directed to the AT. The access

channel, which is defined as an access probe, is divided into two sub-channels:

• Data Channel: Consisting of preamble and access message packets

• Pilot Channel: Continuously transmitted to provide uplink coherent demodulation.

Reverse Access Channel Physical Layer Packet Bit Size

Because the access probe is used to acquire the RA�, in Rev 0 the access channel is

always transmitted at a fixed 9.6 kbps data rate. Be reminded that this is the rate in which

information data is sent to the base station and is not the transmitted modulation symbol

rate, which is 1.2288 Mcps. The Physical Layer access message packet is 256 bits wide

and consists of a 234-bit MAC Layer packet followed by a 16-bit frame sequence check

(FSC) value and a 6-bit tail as, shown in Figure 3-34, “Reverse Access Channel Physical

Layer Packet Bit Size” (p. 3-99).

Access Probe

The access probe consists of a preamble followed by one or more access channel Physical

Layer packets. Because the access probe is transmitted at a 9.6 Kbps data rate, a signal

access channel Physical Layer packet is transmitted during a 16-slot frame. Only the pilot

channel is transmitted at a high-power level during the preamble. During the data portion

of the access probe, the amplitude of the data channel is in proportion to the pilot transmit

amplitude so that the sum of the data and pilot channel transmit power is equal the pilot

channel transmit output transmitted during the preamble period, as shown in Figure 3-35,

“Access Probe” (p. 3-100).

Figure 3-34 Reverse Access Channel Physical Layer Packet Bit Size

Air Interface Changes introduced in Rev ARev 0 Access and Data channels

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

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

401-614-323Issue 16 October 2009

3-99

Page 260: 1xev-Do Rf Engineering

Generation of Access Channel

The generation of the reverse access channel is illustrated in Figure 3-36, “Generation of

Reverse Access Channel” (p. 3-102). This figure is a simplified diagram similar to Figure

3-24, “Generation of Reverse Traffic Channel” (p. 3-74), and to conserve space, omits

details that will be narrated in text.

Data Channel

The access Physical Layer is encoded by the turbo encoder at a 1/4 code rate, producing a

1024-bit symbol. Therefore, the code symbol rate, which is the rate that the symbol is

clocked out of the turbo encoder, is four times the 9.6-kbps access channel data rate, or

38.4 kbps. To improve the ability of the base station to restore the turbo coded in the

event of transmission fading and interference, the access channel data is interleaved by

the channel interleaver and the interleaved packet data is repeated eight times, increasing

the modulation symbol rate to (8 X 38.4 kbps) 307.2 kbps.

The output of the turbo interleave packet repeater is spread by 4-chip Walsh code function

W4, and the amplitude of the resulting chip sequence is scaled, via the data channel

relative gain control, by a factor relative to the amplitude of the Pilot chip sequence. The

scaling factor for the chip sequence is specified by gain parameters as a function of the

MAC protocol. Output of the data channel, relative gain control, provides the Q input for

quadrature spreading. Quadrature spreading is performed in the same manner describes

for the reverse traffic channel.

Figure 3-35 Access Probe

Air Interface Changes introduced in Rev ARev 0 Access and Data channels

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

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

3-100 401-614-323Issue 16 October 2009

Page 261: 1xev-Do Rf Engineering

Rev A Enhanced Access Channel

Description

In Rev A, an Enhanced Access Channel is used to provide new data rates at 19.2 kbps and

38.4 kbps in addition to 9.6 kbps is supported in Rev 0. The Enhanced Access Channel

also provides new Physical layer packet sizes of 256, 512 or 1024 bits (in Rev 0 only 256

bits is supported).

In Rev 0, the access channel data is transmitted by the AT to either initiate communication

with the R�C or respond to a message directed to the AT. The access channel, which is

defined as an access probe, is divided into two sub-channels:

• Data Channel: Consisting of preamble and access message packets

• Pilot Channel: Continuously transmitted to provide uplink coherent demodulation

Air Interface Changes introduced in Rev ARev A Enhanced Access Channel

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

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

401-614-323Issue 16 October 2009

3-101

Page 262: 1xev-Do Rf Engineering

Generation of Reverse Access Channel diagram

Figure 3-36 Generation of Reverse Access Channel

Pilot Channel(All 0’s)

QuadratureSpreading

(Complexmultiplication)

Q’

I

Q

I’

ReverseAccessChannel

S

Turboencoder

(1/4 code rate)

Access channelrelative gain

control

W0 = (++++++++++++++++)16

W2 = (++ )4

sin(2 f t)p c

cos(2 f t)p c

Channelinterleaver

Interleavepacket

repeater

I-ChannelShort PN

Q-ChannelShort PN

I-Channel UserLong Code PNSequence

Q-Channel UserLong Code

PN Sequence

W1

= (+ )

PNI

PNQ

2

DecimatorQ

Access CannelPacket Data

1024 symbolsat 38.4 kbps

307.2 kbps

Air Interface Changes introduced in Rev ARev A Enhanced Access Channel

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

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

3-102 401-614-323Issue 16 October 2009

Page 263: 1xev-Do Rf Engineering

Data rates and pilot channel

New date rates and packet sizes

In Rev A, the role of the access channel is expanded to deliver Short Message Services

(SMS) and VoIP to support a push-to-talk (PTT) feature that require a low latency quick

response. To comply with the new functions, the data payload and transmission data rate

is increased (see Figure 3-37, “Enhanced Access Channel MAC” (p. 3-104)) to provide:.

• �ew data rates of 19.2kbps and 38.4 kbps with 4 slot preamble transmission reduce

channel setup delay.

• �ew packet sizes of 512 or 1024 bits permit transmission of short data bursts to avoid

traffic channel setup.

Air Interface Changes introduced in Rev AData rates and pilot channel

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

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

401-614-323Issue 16 October 2009

3-103

Page 264: 1xev-Do Rf Engineering

Enhanced Access Channel MAC

Pilot Channel

Similar to the traffic pilot channel, the access pilot channel is also unmodulated symbols

having a binary 0 bit value. However, unlike the traffic pilot channel that is

time-multiplexed with the RRI channel, the access pilot channel is continuously

transmitted using a 16-chip Walsh code function number 0.

Figure 3-37 Enhanced Access Channel MAC

Transmit Power

Rev 0 Access Channel

1 frameAccess Channel capsule

4 frames

Pilot Channel

9.6 kbps Data Channel

Transmit Power

4slots

Access Channel capsule4 frames

Pilot Channel

9.6 kbps Data Channel

Transmit Power

Access Channel capsule2 frames

Pilot Channel

19.2 kbps Data Channel

Rev A Access Channel

Preamble

PreAmble

4slots

PreAmble

Access Channel capsule1 frame

Pilot Channel

38.4 kbpsData Channel

4slots

PreAmble

TransmitPower

Transmit Power

Rev 0 Access Channel

1 frameAccess Channel capsule

4 frames

Pilot Channel

9.6 kbps Data Channel

Transmit Power

4slots

Access Channel capsule4 frames

Pilot Channel

9.6 kbps Data Channel

Transmit Power

Access Channel capsule2 frames

Pilot Channel

19.2 kbps Data Channel

Rev A Access Channel

Preamble

PreAmble

4slots

PreAmble

Access Channel capsule1 frame

Pilot Channel

38.4 kbpsData Channel

4slots

PreAmble

TransmitPower

Access Channel capsule1 frame

Pilot Channel

38.4 kbpsData Channel

4slots

PreAmble

TransmitPower

Air Interface Changes introduced in Rev AData rates and pilot channel

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

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

3-104 401-614-323Issue 16 October 2009

Page 265: 1xev-Do Rf Engineering

Test Application Feature

Overview

Purpose

This section discusses the test application feature.

Contents

Introduction 3-106

Issuing commands 3-107

Commands 3-108

Air Interface Test Application FeatureOverview

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

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

401-614-323Issue 16 October 2009

3-105

Page 266: 1xev-Do Rf Engineering

Introduction

Description

ATest Application feature is introduced in Release 20.1 to provide a set of procedures to

conduct forward and reverse link AT/RA� performance measurements in a field

environment. These procedures are given in Alcatel-Lucent 9271 EV-DO Radio �etwork

Controller OA&M, 401-614-102. The Test Application feature provides various testing

capabilities for the forward link and reverse link, providing a collection of data statistics

which were not available prior to the introduction of this feature, such as the number of

physical slots used in receiving the forward link packet. In addition, this feature provides

a platform to conduct AT minimum performance tests. To perform such testing, variables

such as data rate, transmitting sector selection, and RLP handshake acknowledgment

responses should be controlled by the tester. Prior to the introduction of the Test

Application feature, this control was not in the tester's domains.

Controlling the functionality

Because forward data rate and transmitting sector are determined by the AT as a function

of its current RF environment, testing involving air interface is made difficult because

data rate and sector are subject to the AT's current RF environment. Also, such control

relies on the AT's internal algorithm, which could vary from one manufacturer's AT to

another. The Test Application feature allows the tester to control the functionality of the

DRC channel transmitted by a designated AT selected for the test. After the tester

specifies a fixed forward data rate and transmitting sector, the Evolution Controller

(EVC) encodes the tester's input, and transmits a message to the designated AT requesting

it to set appropriate testing parameters.

Controllable environment

When using the Test Application feature, the RA� or the tester is able to control the test

variables, such DRC cover, identifying base station, sector and data rate; therefore, testing

is conducted in a controllable environment. For example, without this feature, it will be

difficult to verify that a particular data rate can be supported throughout a base station

coverage area. The ability to ensure that the forward data rate is held constant is necessary

to perform acceptance tests, and also helpful in performing system coverage optimization.

Air Interface Test Application FeatureIntroduction

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

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

3-106 401-614-323Issue 16 October 2009

Page 267: 1xev-Do Rf Engineering

Issuing commands

Test Application Forward Link Functionality

The Test Application provides three tests that can be run:

• Forward Test (TAF)

• Reverse Test (TAR)

• Combined Forward and Reverse Test (TAA).

When a test is run, an open connection is established with the target AT on a separate

stream (refer to “Stream Layer” (p. 2-26)). Subsequently, data transfer occurs between the

target AT and the Evolution Controller (EVC). This allows the EVC to compile statistical

data about the data transfer. In addition to controlling data rate and sector selection, the

Test Application feature allows the tester to enter parameters such as ACK (acknowledge)

to control the value transmitted over the test AT reverse ACK channel. The tester specifies

a 0, and the AT will always respond to the transmitted message with an ACK signal,

regardless of whether the packets were successfully received in one slot. If the tester

specifies a 0, the AT will always respond with a "�AK" indication.

CLI Input Command Syntax

Test procedures for performing each test are given in Alcatel-Lucent 9271 EV-DO Radio

�etwork Controller OA&M, 401-614-102. The forward (TAF), reverse (TAR), and

combined forward and reverse (TAA) are started by entering the appropriate CLI input

command syntax as follows:

TAF:UATI 0x# [, BTS #, SECTOR #] [, DRCRATE #] [, ACK 0|1] [,NOLOOPBACK] [, DATAPKTS][, DURATION #] [, INTERVAL #] [, TAI #]

for forward test, and

TAR:UATI 0x# [, MINRATE #, MAXRATE #] [, DURATION #] [, INTERVAL #]

for reverse test, and

TAA:UATI 0x# [, BTS #, SECTOR #] [, DRCRATE #] [, ACK 0|1][,NOLOOPBACK] [, DATAPKTS][, MINRATE #, MAXRATE #] [, DURATION #] [,INTERVAL #] [,TAI #]

for combined forward and reverse test.

The duration of the test is controlled by the DURATION # link command. However, any

test can be stopped at any time by entering the stop CLI command:

STOP:{TAF | TAR | TAA}; UATI 0x#

The command must specify which of the three tests is to be stopped (TAF,TAR, or TAA)

and the AT UATI address (UATI 0x#).

Air Interface Test Application FeatureIssuing commands

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

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

401-614-323Issue 16 October 2009

3-107

Page 268: 1xev-Do Rf Engineering

Commands

Link Commands

Except for the AT UATI address (UATI 0x#), all other link commands or parameters

used for the three tests are optional. However, to start the forward application test, at least

one of the following optional link commands must be included: [BTS #, SECTOR #]; [,

DRCRATE #]; [, ACK 0|1]; [, NOLOOPBACK]; or [,TAI #]. If none of these link

commands are entered, the software will display the following error message:

COMMAND REJECTED DUE TO INVALID FTAP PARAMETERS

The definition of each parameter is given in the following paragraph.

UATI 0x# Hexadecimal UATI address of the target AT. The UATI can be retrieved

from the AT using the CAIT tool or by using the AT itself, if the AT provides such a

function. The input UATI must be 32 bits long. If the CAIT tool displays only a 24-bit

UATI, the test must also retrieve the Color Code field from the AT, then concatenate

the color code with the displayed 24-bit UATI value.

BTS #, SECTOR # Specifies the base station and sector ID numbers. This input is

decoded into the DRC cover (refer to “Description” (p. 7-30)), causing the AT to

direct its DRC channel to the specified base station and sector. When the test starts,

the AT tries to access the pilot P� offset from the designate sector into its Active Set

(refer to “Description” (p. 7-30)). If the AT is too far from the sector, the AT will not

be able to achieve this. As a result, after waiting two minutes for a positive response

from the AT, the test will be terminated. The software will display the following:

DRC COVER NOT IN ACTIVE SET

In this case the AT must be moved closer to the target sector and restart the test or, if

this option is left blank, the AT will find the best serving sector.

DRCRATE # This parameter identifies the forward data rate encoded sent to the target

for transmission of the DRC channel. The value for this parameter ranges from 0 to 12

to request a forward transmission as shown in Table 3-10, “DRCRATE Values”

(p. 3-108). The duplicated rates that appear DRCRATE# 4 and 5, 6 and 7, and 9 and

10, represent different turbo code rates or modulation schemes as indicated in Table

3-3, “Transmission Format Code Rate and Transmission Type” (p. 3-19).

Table 3-10 DRCRATE Values

DRCRATE # Data Rate(kbps) DRCRATE # Data Rate(kbps)

0 �ull 7 614.4

1 38.4 8 921.6 1

2 76.8 9 1228.8

3 153.6 10 1228.8

4 307.2 11 1843.2

Air Interface Test Application FeatureCommands

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

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

3-108 401-614-323Issue 16 October 2009

Page 269: 1xev-Do Rf Engineering

Table 3-10 DRCRATE Values (continued)

DRCRATE # Data Rate(kbps) DRCRATE # Data Rate(kbps)

5 307.2 12 2457.6

6 614.4

ACK This parameter indicates a fixed desired acknowledge response on ACK

channel: 0 for ACK, 1 for �AK; refer to “�ormal Packet Transmission

Termination” (p. 3-47). If left blank, the AT will set the ACK bit according to the

actual status of the received packet.

NOLOOPBACK Indicates that loopback, which is the returning of forward link data

on the reverse link, will not be performed. When left blank, loopback mode is on.

There should be no other reverse link data frames expected, because the loopback

mode requires the AT to send back every received forward link data packet on the

reverse link, which could occupy the entire reverse link bandwidth and leave no

room for other reverse traffic transmission. The user must explicitly select the

NOLOOPBACK option to turn off the loopback mode.

DATAPKTS Causes data to be transmitted on the forward link, but not to return on

the reverse link. Therefore, this option is mutually exclusive with the loopback

mode. If the NOLOOPBACK command link is left blank, the DATAPKTS

command link must be left blank.

DURATION # Selects the test duration in accordance with Table 3-11, “Test

Duration Code” (p. 3-109). If DURATION # is not present, the Test Application

will run for 30 minutes if the connection is up. If the connection is dropped, unless

the tester/mobile restarts the connection requests, there will be no data collected

during the period when the connection is not up.

Table 3-11 Test Duration Code

DURATION # Test Duration in

Minute

DURATION # Test Duration in

Minute

1 15 9 135

2 30 10 150

3 45 11 165

4 60 12 180

5 75 13 195

6 90 14 210

7 105 15 225

8 120 16 240

Air Interface Test Application FeatureCommands

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

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

401-614-323Issue 16 October 2009

3-109

Page 270: 1xev-Do Rf Engineering

INTERVAL # Indicates the interval for data recording/logging. If not specified,

a two-second default is used, which means the data will be accumulated and

recorded in every two-second interval. Range is 1 to 5 seconds in one-second

steps.

TAI # Collects data while the AT is in the idle mode. When the TAI # option

is selected, an idle test is initiated. At this time, the RA� must initially set up a

connection to send the Idle Test Command to the AT, so that the AT can start to

collect Idle Mode Statistics. Thereafter, the RA� will periodically page the AT

to set up a connection to retrieve the data. When in the idle mode, the AT is not

assigned any dedicated airlink resources and communicates with the base

station.

Start the Idle tests using the forward link test command, TAF:UATI 0x#,

DURATION # and TAI # options. The TAI option specifies the idle state

collect timer. Range is 1 to 15 minutes in steps of 1 minute. �o default exists.

The idle state collect timer is used by the RA� to page the AT and get the idle

statistics via the access channel. The idle statistics data interval can be TAI

plus delta, where delta can vary for each collection interval, depending on the

page response and connection establish time. The DURATION # indicates how

long the entire idle test should run. If not specified, the Idle Test will run for

30 minutes.

�ote, when running the idle test, do not run any other forward link or reverse

link tests, since the mobile collects the idle statistics data only when in the Idle

Mode.

MINRATE #, MAXRATE # These two parameters, which are used for the

reverse test only, indicate the minimum and maximum data rate the mobile can

select during the testing. When MINRATE # and MAXRATE # are not equal to

0, the AT will generate reverse link data packets and send them to the RA�.

Thus, when running reverse link test and forward link test together, ensure that

forward link loopback mode is off if the AT is to send any reverse link data

packets.

Start All Tests Command (TAA)

The TAA command allows the user to start both the forward link and reverse link tests

together. This is used a great deal in the Minimum Performance Standard, where the test

cases are typically run the reverse link test at certain fixed rate, e.g., 9.6kbps, set the

forward link ACK off, or DRCRATE # to 0 for a null DRC cover, etc. For meaningful test

results, caution must be taken not to run the forward link loopback mode when not

needed. In other words, the user must explicitly set the NOLOOPBACK option to turn off

the loopback mode.

Air Interface Test Application FeatureCommands

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

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

3-110 401-614-323Issue 16 October 2009

Page 271: 1xev-Do Rf Engineering

4 4Hardware Components

Overview

Purpose

This chapter provides a high-level discussion of the Alcatel-Lucent equipment that

supports 1xEV-DO deployment. 1xEV-DO technology is designed to protect the

investment of existing CDMA service providers by using the same RF carriers as in IS-95

and 3G-1X. While the Physical Layer of 1xEV-DO, identifying channel encoding, and

channel structure differ greatly from IS-95 and 3G-1X, the RF signal and the 1.25-MHz

bandwidth are compatible with IS-95/3G-1X. Therefore, much of the same base station

RF equipment (amplifiers, filters, etc.) used to provide IS-95/3G-1X service can be used

to provide 1xEV-DO service. This makes it much easier to adapt existing multi-carrier

base station equipment for 1xEV-DO operation.

This chapter will consider all the equipment within the 1xEV-DO Radio Access System

(RAS) which consists of the 1xEV-DO Radio Access �etwork (RA�).

Contents

1xEV-DO Radio Access �etwork (RA�) 4-3

Flexent CDMABase Station Cabinet 4-4

CDMADigital Module (CDM) for IS-95 and 1X-3G 4-6

CDMADigital Module (CDM) for 1xEV-DO 4-8

9218 Macro OneBTS Cabinet 4-10

Multiple-Carrier Feature (FID-8219.1) 4-14

Support for five 1xEV-DO carriers (FID-8219.21) 4-16

Support for six 1xEV-DO carriers (FID-8219.16) 4-18

Support for Three 1xEV-DO Carriers with two URCIIs 4-21

Support for Three 1xEV-DO Carriers 4-22

URC-II improvement supporting 3 DO carriers (FID-12078.44) 4-23

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

401-614-323Issue 16 October 2009

4-1

Page 272: 1xev-Do Rf Engineering

Support For Multiple 1xEV-DO Carriers In Single EVM For The Single Sector

Configuration

4-24

Circuit Pack Location 4-27

Adding 1xEV-DO To AUTOPLEX® Cells 4-29

FMS and AP 4-32

MFFU, RCC and Router 4-36

IP �etwork Elements 4-37

Deployment Scenarios 4-38

Hardware Components Overview

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

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

4-2 401-614-323Issue 16 October 2009

Page 273: 1xev-Do Rf Engineering

1xEV-DO Radio Access Network (RAN)

Introduction

The 1xEV-DO Radio Access �etwork (RA�) consists of 1xEV-DO base stations, and the

1xEV-DO Flexent®Mobility Server (FMS). The 1xEV-DO equipment may be collocated

with IS-95 and 3G-1X equipment to form 1xEV-DO/IS-95 and 1xEV-DO/3G-1X base

stations. This section is divided into two parts. The first part provides a high-level

description of Alcatel-Lucent, existing IS-95 and 3G-1X CDMA base station equipment

and how the equipment is modified for 1xEV-DO collocation deployment. The second

part provides a description of the 1xEV-DO FMS.

Multi-Mode Cells

The Alcatel-Lucent product offering for 1xEV-DO is intended to provide investment

protection for Flexent®Modcell and AUTOPLEX® Series II platforms, 1xEV-DO is

integrated into the Flexent® product line and will have a minimal influence on the

AUTOPLEX® footprint.

This section provides information on how 1xEV-DO capabilities are added to existing

Flexent® and AUTOPLEX® cells.

Hardware Components 1xEV-DO Radio Access Network (RAN)

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

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

401-614-323Issue 16 October 2009

4-3

Page 274: 1xev-Do Rf Engineering

Flexent CDMA Base Station Cabinet

Base Station cabinetsFlexent® CDMA Base Station Cabinet

The Alcatel-Lucent Base Station cabinets can support up to three IS-95 or 3G-1X carriers

per three sectors. A generic outline of the Modular Cell 1, 2, and 3 cabinets is shown in

Figure 4-1, “Flexent® CDMABase Station Cabinet Structure” (p. 4-5). A

1xEV-DO/IS-95/3G-1X mixed-mode Modular Cell 1, 2, and 3 cabinet will support a mix

of 1xEV-DO and IS-95 and/or 3G-1X carriers by allowing the mixing of 1xEV-DO

CDMADigital Module (CDM) with IS-95 and 3G-1X CDM in the same cabinet. Because

1xEV-DO technology uses the same RF footprint as does IS-95 and 3G-1X, the top

portion of the cabinet, containing filters, transmit amplifiers, and other components does

not change for 1xEV-DO. The only hardware modification required for 1xEV-DO

deployment is within the top shelf of the CDM.

CDMs

Up to three CDMs can be located within the digital section (bottom two shelves) of the

Base Station cabinet. Each CDM provides the digital circuit packs for one carrier. In most

cases, when a 3G-1X carrier is deployed, the 3G-1X would be in the first CDM (left) on

the digital section.The CDMs are located in the digital shelf along with two Time

Frequency Units (TFUs), which are driven by the output of the Rubidium oscillator

module (OM) to provide precise CDMA timing to the circuit packs within the digital

shelf. A Crystal OM is located above the Rubidium OM to provide backup in the event

that the Rubidium OM fails.

Hardware Components Flexent CDMA Base Station Cabinet

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

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

4-4 401-614-323Issue 16 October 2009

Page 275: 1xev-Do Rf Engineering

Flexent CDMA Base Station Cabinet structure

Figure 4-1 Flexent® CDMA Base Station Cabinet Structure

RubidiumOM

Digital Shelf

Hardware Components Flexent CDMA Base Station Cabinet

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

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

401-614-323Issue 16 October 2009

4-5

Page 276: 1xev-Do Rf Engineering

CDMA Digital Module (CDM) for IS-95 and 1X-3G

Description

For IS-95 or 3G-1X deployment, the major components of the CDM are (Figure 4-2,

“CDMADigital Module (CDM) for IS-95 and 3G-1X” (p. 4-7)):

• CDMARadio Controller (CRC) - Executes control software for call and traffic

processing, OA&M, and T1/E1 facility control for a single CDMA carrier. Universal

Radio Controller-M (URCm) circuit card is introduced in R22.0 to increase facility

capacity to two T1/E1 lines for Modular 1.0 cabinets and four T1/E1 lines for

Modular 2.0 and 3.0 cabinets. However, CRC and URCm cards cannot be mixed in

the same cabinet

• CDMAChannel Unit (CCU) - Up to six CCUs may be installed in each CDM.

Support for 3G-1X and IS-95 requires a CCU-32 card as opposed to the CCU-20 card,

which supports only IS-95 traffic. The CCU-32 provides 32 Channel Elements to

handle voice and data traffic for IS-95/3G-1X users.

• Power Converter Unit (PCU) - Provides the various DC power for the circuit packs

for the three CDMs within the digital shelf

• CDMABaseband Radio (CBR) - Converts the signal to be transmitted from any CCU

within the CDM to the RF frequency of its assigned carrier/ sector, and sends the

signal to the linear amplifier.

Hardware Components CDMA Digital Module (CDM) for IS-95 and 1X-3G

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

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

4-6 401-614-323Issue 16 October 2009

Page 277: 1xev-Do Rf Engineering

CDMA Digital Module (CDM) for IS-95 and 1X-3G diagram

Figure 4-2 CDMA Digital Module (CDM) for IS-95 and 3G-1X

Hardware Components CDMA Digital Module (CDM) for IS-95 and 1X-3G

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

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

401-614-323Issue 16 October 2009

4-7

Page 278: 1xev-Do Rf Engineering

CDMA Digital Module (CDM) for 1xEV-DO

Description

�o limitation exists on the placement of 1xEV-DO carrier (1xEV-DO CDM, refer to

Figure 4-3, “CDMADigital Module (CDM) for 1xEV-DO” (p. 4-9)). This means that the

1xEV-DO carrier can be equipped in any CDM of the Base Station frames, primary

frame, or growth frame.

The 1xEV-DO Modem contains the functionality required to support the 1xEV-DO

physical layer and is used for all 1xEV-DO Flexent® platforms. Support for Multiple

1xEV-DO Carriers - IFHO, FID 8219.11 (R26.0) permit multiple 1xEV-DO carriers

deployment per Base Station cabinet by modifying more than one CDM. Converting the

CDM hardware for 1xEV-DO deployment is a two-step procedure:

1. All CCU packs are removed and replaced with a single 1xEV-DO Modem (EVM).

Prior to release R26.0, the EVM contains two modem boards, EVTx and EVRx. Two

CCU slots are reserved for a single EVM, where the EVTx transmit board is plugged

in to slot 1 and the EVRx receive board is plugged in to slot 2. The 1xEV-DO modem

boards are pin-compatible with the backplane so that no external wiring or pin

jumping is required.

Subsequent to release R26.0 a Single-Board EVM (SB-EVMm) is available requiring

one plug-in slot. The SB-EVMm, which provides same functionality as the two-board

EVM, is required for 1xEV-DO Rev A deployment in release R27.0.

2. The CRC must be replaced with a 44WW13D or later version. This version

accommodates 1xEV-DO operation and is compatible with IS-95 and 3G-1X.

Hardware Components CDMA Digital Module (CDM) for 1xEV-DO

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

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

4-8 401-614-323Issue 16 October 2009

Page 279: 1xev-Do Rf Engineering

CDMA Digital Module (CDM) for 1xEV-DO diagram

Figure 4-3 CDMA Digital Module (CDM) for 1xEV-DO

Hardware Components CDMA Digital Module (CDM) for 1xEV-DO

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

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

401-614-323Issue 16 October 2009

4-9

Page 280: 1xev-Do Rf Engineering

9218 Macro OneBTS Cabinet

Description

The 9218 Macro cabinet, which is a OneBTS cabinet, is available in three different

frames and a variety of configurations with regard to the number of sectors serviced,

indoor/outdoor and primary/growth deployment, and service bandwidth. A nominal

generic version of this frame is shown in Figure 4-4, “9218 Macro Cabinet” (p. 4-10).

9218 Macro Cabinet diagram

Digital Shelf Signal Flow

Rather than having dedicated CDM hardware to separately process each carrier as in the

Modular Cells 1, 2, and 3, the digital shelf in the 9218 Macro cabinet pools the CDM

function for each carrier in single hardware resource for either 1xEV-DO data or

3G-1X/IS-95 data.

Figure 4-4 9218 Macro Cabinet

Hardware Components 9218 Macro OneBTS Cabinet

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

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

4-10 401-614-323Issue 16 October 2009

Page 281: 1xev-Do Rf Engineering

Universal Radio Controller (URC)

Universal Radio Controllers are used in place of CDMARadio Controller (CRC) to

execute control software for call and traffic processing. In addition, URCs steer the

transmit and receive data for each carrier to either an EVM for 1xEV-DO operation or a

CDMAmodem unit (CMU) for IS-95 and 3G-1X (refer to Figure 4-5, “Digital Shelf

Signal Flow” (p. 4-12)).

Single-Board EVM

Prior to release R26.0, the EVM contains two modem boards, EVTx and EVRx.

Subsequent to release R26.0 a Single-Board EVM (SB-EVM) is available requiring one

plug-in slot. The SB-EVM, which provides same functionality as the two-board EVM, is

required for 1xEV-DO Rev A deployment in release R27.0.

Mixed Mode System

In a mixed-mode system, prior to release R25.0, at least two URCs are required, one for

1xEV-DO data and the other for 3G-1X/IS-95 data. For transmission, the URC will direct

the signal received from the R�C or MSC network to either the 4.0 EVM, for 1xEV-DO,

or CMU for 3G-1X and IS-95, where the signal is modulated. In large cells, a number of

CMUs may be installed to provide a pool of channel elements (CE) to process

3G-1X/IS-95 voice and data signals. The task of the URC is to select the next available

CMU and CE from the pool to process the incoming voice and data signals.

Hardware Components 9218 Macro OneBTS Cabinet

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

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

401-614-323Issue 16 October 2009

4-11

Page 282: 1xev-Do Rf Engineering

Digital Shelf Signal Flow

Functionality

The modulated signal from the 4.0 EVM or CMU is up-converted to its appropriated

carrier frequency by the universal CDMA radio (UCR). The upconverted carrier signal is

then amplified, filtered and routed to the base station transmit antenna. The UCR,

provides the same functionality as the CBR for up to three (1.25 MHz) CDMA carriers

within 5MHz of PCS or Cellular frequency spectrum.

Reverse link signals received through the UCR are down-converted and appropriately

routed to either the 4.0 EVM or the next available CMU designated by the URC for

demodulation. The demodulated signal is then routed through its appropriate URC to its

designation via the RA� or AUTOPLEX® network. The operation of the UCR may be

replaced subsequence to release R24.0 by the multi-carrier radio (MCR) that will handle

up to eleven PCS or eight cellular carriers within 15MHz of contiguous spectrum.

Universal Radio Controller-II (URC-II)

URC-II circuit packs are introduced in R25.0 to increase backhaul efficiency and increase

capacity by up to 40 percent. Each URC II is able to support a maximum of eight T1/E1

lines. Four T1/E1 lines are connected on the circuit front panel and the other four lines are

connected through the backplane. The lines that are connected on the front panel are

protected by secondary lightning protectors. Both T1 Frame Relay Packet Pipe or IP

Figure 4-5 Digital Shelf Signal Flow

Universal RadioController (URC)

Universal RadioController (URC)

Evolution Modem(4.0 EVM)

CDMA ModemUnit (CMU)

Universal CDMARadio (UCR)*

C1

C2, C3

Antennas

RAN

MSC

* Multi-Carrier Radio (MCR) may be used subsequent to Release R24.0

Hardware Components 9218 Macro OneBTS Cabinet

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

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

4-12 401-614-323Issue 16 October 2009

Page 283: 1xev-Do Rf Engineering

backhaul are supported. With the URC II, 9218 Macro and 9218 Macro HD cabinets are

enable to supports a minimum of 12 and a maximum of 20 T1/E1 lines with two Sec-B

installed in the frame.

Prior to this release, one URC must be used exclusively for 1xEV-DO service in a

mix-mode system. This URC exclusivity is removed in release R25.0, where a single

URC or URC II circuit pack can process both 1xEV-DO and 2G/3G carriers. 9218 Macro

cabinets will support a mix of URC and URCIIs in their digital shelves were URC can

support 2 1xEV-DO carriers and URC-II can support 3 1xEV-DO carriers.

Hardware Components 9218 Macro OneBTS Cabinet

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

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

401-614-323Issue 16 October 2009

4-13

Page 284: 1xev-Do Rf Engineering

Multiple-Carrier Feature (FID-8219.1)

Description

The multiple-carrier feature which is also introduced in Release R25.0 supports multiple

1xEV-DO carriers in the following base station types:

• 9218 Macro

• 9216 Compact

• 9218 Macro HD

• Modcells 1.0, 2.0, and 3.0

This feature is supported for 850 MHz Cellular and 1900 MHz PCS for all models.The

Korea 1800 MHz PCS is supported only on 9218 Macro and the 450 MHz operation is

supported on Modcell 2.0 and 3.0 only

1xEV-DO carries supported

Two 1xEV-DO carries are supported on a single classic URC in the 9218 Macro, 9216

Compact, and 9218 Macro HD base stations. This number is increase to three carries

when the URC II circuit pack is used. The URCm circuit pack must be used in the

Modcells 1.0. 2.0. and 3. 0 for multiple carrier operation at a base station. However,

because of the CDM architectural constraint, multiple carrier operation on a single URCm

is not permitted.

�o special restrictions exist on the type of radio used with this feature. Either UCR or

MCR can be used in 9218 Macro. The 1xEV-DO compatible CBR can be used in

Modcells 1.0, 2.0, and 3.0. Shared radio between 3G1x and 1xEV-DO is also permitted.

For best performance, each 1xEV-DO carrier should be put on a separate amplifier. If the

1xEV-DO carriers need to be put on the same amplifier, Alcatel-Lucent recommends that

they be placed adjacent to each other in the frequency spectrum for best performance.

To minimizes the amount of inter-AP communication and to optimize call processing

performance, this feature requires that all carriers of a cell be served by the same AP.

Using the same AP also allows better OA&M correlations. This, however, may require

moving cells associated with the AP to a different AP in the growth procedure, making

room for the additional carrier(s).

Backhaul

The classic URC supports up to four T1s/E1s and a URC-II can have up to 8 T1s/E1s.

The base station must be provision with the optimum carrier/facility line ratio to insure

maximum data throughput that will make full use of air-interface resources. Using the

existing loading data on a single carrier, estimates are that the downlink data throughput

for multiple-carriers per URC will be about 550 kbps/sector-carrier when two carriers and

Hardware Components Multiple-Carrier Feature (FID-8219.1)

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

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

4-14 401-614-323Issue 16 October 2009

Page 285: 1xev-Do Rf Engineering

four T1/E1 lines are provisioned. This throughput may be increase to about 850

kbps/sector-carrier when three carriers and eightT1/E1 lines are provisioned used an URC

II circuit pack.

When the Ethernet backhaul feature (FID-8213.1) is enabled Ethernet backhaul

supporting 10/100 BaseT can be used. Ethernet backhaul running at 100 Mbps signaling

rate (100 BaseT) has enough bandwidth to accommodate three 1xEV-DO carriers. The

bandwidth to accommodate two 1xEV-DO carriers running at a 10-Mbps signaling rate

(10 BaseT) is marginal. Generally, multiple variables can affect the data throughput over

an Ethernet interface (e.g., operation mode, topology, packet size, overhead), making the

throughput performance over Ethernet less deterministic.

Overload Protection

For supporting multiple carriers per URC, Alcatel-Lucent recommends that 1X EV DO

Cell Processor Overload Control feature (FID 10519.0) be enabled. This to ensure

overload control for the base station processors and helps the system performance by

providing protection algorithm against that takes care of overloading issues before they

result in performance degradation.

The overload protection render by this feature is in addition to two other overload control

mechanisms that have been in place since the initial release of 1xEV-DO. The first is the

TP (Traffic Processor) Overload Control that handles processor overload for the TP.

When the TP occupancy or the traffic arrival rate exceeds a certain customer definable

threshold, the TP is said to be in overload and multiple actions are taken for overload

abatement. The second overload control feature is known as Reverse Link Overload

Control (FID-8048.0) where the purpose is to handle the RF Overload in the reverse link.

This is done through reducing the data rate in the reverse link and admission control.The

overload control mechanisms for the cell processors can range from slowing down the

data rate, to blocking users, and also forcing users into dormancy.

Hardware Components Multiple-Carrier Feature (FID-8219.1)

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

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

401-614-323Issue 16 October 2009

4-15

Page 286: 1xev-Do Rf Engineering

Support for five 1xEV-DO carriers (FID-8219.21)

Description

Important! For R32 and later Alcatel-Lucent recommends using the procedures for

FID 8219.16. See “Support for six 1xEV-DO carriers (FID-8219.16) ” (p. 4-18) for

more information.

This feature supports 5 carrier 3-sector configuration in 1xEV-DO. See “4 carrier/3 sector

configurations” (p. 4-16) and “5 carrier/3 sector configurations” (p. 4-17) for the URCm

and URC-II requirements in the BTS frame configurations.

The frame configurations could be part of a larger multi-frame lineup. For example, a 3

frame configuration that has two frames equipped with 1xEV-DO carriers can use this

feature.

Band classes

This feature supports 5 1xEV-DO carriers operating in BC0 and BC1 in both single band

and dual band configurations.

Hardware requirements

URCm is used in mixed frame configurations on Modcell 1.0/2.0/3.0. URC-II is used in

the BTS types 9218 and 9228 and can support up to 3 1xEV-DO carriers with the

performance improvements provided in “URC-II improvement supporting 3 DO carriers

(FID-12078.44)” (p. 4-23).

As in previous multiple-carrier features, all 1xEV-DO carriers of a cell must be served by

the same AP. In order to configure the 4th and 5th carriers, the AP with 2GB memory

must be installed. The R1SR R�C frame can have a mix of 1GBAPs and 2GBAPs, but

only the 2GBAP pairs can be grown with more than 3 carriers in a cell.

4 carrier/3 sector configurations

Base station frame configuration for 4c-3s are shown in the following table:

Frames URC & URCIIequipage

Carrierconfiguration

FeatureDependency

Single frame URCII 2c n/a

URCII 2c

Two frames URCII 2c n/a

URCII 2c

Hardware Components Support for five 1xEV-DO carriers (FID-8219.21)

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

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

4-16 401-614-323Issue 16 October 2009

Page 287: 1xev-Do Rf Engineering

Frames URC & URCIIequipage

Carrierconfiguration

FeatureDependency

Two frames URCm 1c n/a

URCm 1c

URCII 2c

5 carrier/3 sector configurations

Base station frame configuration for 5c-3s are shown in the following table:

Frames URC & URCIIequipage

Carrierconfiguration

FeatureDependency

Single frame URCII 3c FID-12078.44

URCII 2c

Two frames URCII 3c FID-12078.44

URCII 2c

Two frames URCm 1c FID-12078.44

URCm 1c

URCII 3c

Platforms supported

This feature will support for the following BTS platforms combined with the legacy

Modcell 1.0/2.0/3.0 frames:

• 9218 Macro

• 9228 Macro

• 9218 Macro HD

• 9228 Macro HD

• 9228 Macro MCPA-D (BTS 8440D)

Hardware Components Support for five 1xEV-DO carriers (FID-8219.21)

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

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

401-614-323Issue 16 October 2009

4-17

Page 288: 1xev-Do Rf Engineering

Support for six 1xEV-DO carriers (FID-8219.16)

Overview

This feature supports six 1xEV-DO carrier configuration as extension of FID-8219.21.

This feature enables the service provider to equip six carriers in a cell to meet the

increasing demand of 1xEV-DO traffic.

Description

This feature provides support for single band as well as dual band configurations on BC0

and BC1. Both Rev A and Rel 0 carriers are supported. Supported services include BE,

QoS and BCMCS. BTS Controllers primarily use URC-IIs supporting up to 3 1xEV-DO

carriers. Backhaul support includes T1s/E1s and Ethernet. SB-EVMs are supported.

FID-8219.16 also provides full OA&M support of 6 carriers including the use of

OMC-RA� and Prospect. R�C support includes R1SR and U�C. AP with 2GB memory

is required to grow more than 3 carriers in a cell.

The feature supports six 1xEV-DO carriers configuration

• Up to 6 1xEV-DO carriers with 3 sectors in a cell

– Cell can have a mix of 3G1x and 1xEV-DO carriers or 1xEVDO carriers only

– �umber of carriers in six-sector cell remains to be one from FID 8882.3

• Rev A and Rel 0 Carriers

• BC0 and BC1

• Single and Dual Band configurations

• Support BE, QoS and BCMCS services

• Provides full-scale OA&M functions including OMC-RA� and

• Prospect support which was deferred from FID-8219.21

BTS Support Configurations and Hardware

The following subsections cover the hardware and configurations that support FID

8219.16.

Configurations

This feature supports 6 carriers over the following BTS platforms combined with the

legacy Modcell 1.0/2.0/3.0 frame(s):

• 9218 Macro

• 9228 Macro

• 9218 Macro HD

• 9228 Macro HD

Hardware Components Support for six 1xEV-DO carriers (FID-8219.16)

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

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

4-18 401-614-323Issue 16 October 2009

Page 289: 1xev-Do Rf Engineering

• 9228 Macro MCPA-D

• 9228 Macro LP (formerly BTS 8420 and/or "Digital Host")

Hardware

This FID works with the following controllers:

• URC-II,

URC-II supports up to three carriers with FID 12078.44 (Rev A and Rel 0, BE)

• URC,

• URCm

These modem cards support FID 8219.16:

• SB-EVM

• Single Carrier per modem board

Backhaul is accomplished on the following

• T1/E1 (URC-II supports up to 8 T1s/E1s under FID 8973.10)

• Ethernet

The feature works on the following radios:

• UCR

• MCR

RNC Support and Hardware

Following is the list of hardware needed to support this feature.

• U�C and R1SR

• Following are the AP requirements:

– 2GBAP is required for configuring more than 3 carriers in a cell

– Amix of 2GBAPs and 1GBAPs in the R1SR R�C is allowed

– All carriers of a cell need to be served by the same AP (same as previous

multiple-carrier features)

• The following traffic processors are supported:

– UTP

– 752i

– 690

• �o reduction in R�C session and carrier capacities

Hardware Components Support for six 1xEV-DO carriers (FID-8219.16)

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

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

401-614-323Issue 16 October 2009

4-19

Page 290: 1xev-Do Rf Engineering

OA&M Support of Six Carriers

The OMC-RA� treates the 4th qnd 5th carriers in a different manner than the first three

carriers.

• 8219.21 configures the 4th and 5th carriers via Bulk Provisioning using scripts and

does not show status of 4th and 5th carriers on OMC-RA�

• 8219.16 provides the OMC-RA� support on parameter provisioning for the 4th, 5th,

and 6th carriers (e.g., channel number, neighbor cell information) plus showing status

of the 4th , 5th and 6th carriers

Prospect support of this feature is also limited as follows:

• 8219.21 does not have Prospect support the 4th and 5th carriers. SM data on 4th and

5th carriers is available in SM data files stored in OMP-FX

• 8219.16 includes Prospect support of the 4th , 5th and 6th carriers

Base station frame configuration for 6c-3s

The following table shows the base station frame configuration for 6c-3s

Frames URC & URCIIequipage

Carrierconfiguration

FeatureDependency

Single frame URCII + URCII 3c + 3c FID-12078.44

Two frames URCII + URCII 3c + 3c FID-12078.44

URCm +URCm +

URCII + URCII

[1c + 1c] + [3c + 1c] FID-12078.44

[1c + 1c] + [2c + 2c] FID-12078.44

Hardware Components Support for six 1xEV-DO carriers (FID-8219.16)

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

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

4-20 401-614-323Issue 16 October 2009

Page 291: 1xev-Do Rf Engineering

Support for Three 1xEV-DO Carriers with two URCIIs

Introduction

This feature supports three 1xEV-DO carriers with two URCII equipage. This feature is

supported on the 9218 Macro/9228 Macro only.

�ote: The feature requires sufficient hardware to support the additional carriers and

bands. This hardware includes URCII, SBEVM, CBRs, AMP, Filter, etc.

Description

Because of performance limits on the URCII supporting two fully-loaded 1xEV-DO

carriers, this feature requires two URCII equipage to support fully-loaded three 1xEV-DO

carriers. When a BTS is equipped with two URCIIs, one URCII supports two 1xEV-DO

carriers while the other URCII supports one 1xEV-DO carrier. This feature supports

single frame as well as multiframe configurations.

Configuration support

The following configurations are valid only for platform type 9218 Macro/9228 Macro

Frame configurationsupport

URC Configurationsupport

Dual band support in theURCII

Single frame URCII + URCII:

2 carriers + 1 carrier

URCII: two BC0

URCII: one BC1

URCII: one BC0, one BC1

URCII: one BC0

Multi-frames URCII + URCII: 2 carriers +

1 carrier

URCII: two BC0

URCII: one BC1

URCII: one BC0, one BC1

URCII: one BC0

Hardware Components Support for Three 1xEV-DO Carriers with two URCIIs

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

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

401-614-323Issue 16 October 2009

4-21

Page 292: 1xev-Do Rf Engineering

Support for Three 1xEV-DO Carriers

Overview

Support for Three 1XEV-DO Carriers (FID-8219.8) provides the following:

• Up to 3 1xEV-DO carriers in a cell with variety of frame configurations. The 3

1xEV-DO carriers can be equipped all in one BTS frame or distributed among

multiple BTS frames in the cell.

• Backward compatibility supporting dual band configurations

Performance Impact of three carriers

�one

Applicable BTS Platform type with feature dependency

The following BTS platforms support this feature:

• 9218 Macro, 9218 Macro HD - Single or multiple frame configurations support 3

1xEV-DO carriers

• 9216 Compact/9226 Compact

• 9228 Macro MCPA - D, 9228 Macro LP

�ote that 9228 Macro LP digital host with 2W composite option may need PAD tuning to

maintain the same coverage.

Example of Support for Three 1xEV-DO Carriers

The following table provides examples of support for three 1xEV-DO carriers.

Platform type Frame configuration support URC/URCII configuration

9218 Macro/9228

Macro

Single frame URC w/ 1c + URCII w/ 2c

Multi-frame URC w/ 1c + URCII w/ 2c

9218 Macro

HD/9228 Macro

HD

Single frame URC w/ 1c + URCII w/ 2c

Multi-frame URC w/ 1c + URCII w/ 2c

9216

Compact/9226

Compact

Single frame URC w/ 1c + URCII w/ 2c

Multi-frame URC w/ 1c + URCII w/ 2c

9228 Macro LP Single frame URC w/ 1c + URCII w/ 2c

9228 Macro

MCPA - D

Single frame URC w/ 1c + URCII w/ 2c

Multi-frame URCII /1c + URCII w/2c

Hardware Components Support for Three 1xEV-DO Carriers

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

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

4-22 401-614-323Issue 16 October 2009

Page 293: 1xev-Do Rf Engineering

URC-II improvement supporting 3 DO carriers (FID-12078.44)

Overview

URC-II provides performance enhancement that supports 3 1xEV-DO Rev. A carriers.

One URC-II supports three 1xEV-DO RevA carriers with 100% Best Effort traffic model

With 3 1xEV-DO Rev. A carriers configured, URC-II can limit the DO traffic under the

extreme traffic conditions due to the PO limit.

For system stability, the LIU PO overload control will regulate the DO traffic.

Applicable BTS

This feature supports the following BTSs:

• 9218 Macro

• 9218 Macro HD and 9216 Compact/9226 Compact

• 9224 Sub-Compact

• 9224 Sub-Compact E�

• 9228 Macro MCPA - D

• 9228 Macro LP

Feature Dependencies

FID-12267.0: Ethernet backhaul

Hardware Components URC-II improvement supporting 3 DO carriers(FID-12078.44)

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

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

401-614-323Issue 16 October 2009

4-23

Page 294: 1xev-Do Rf Engineering

Support For Multiple 1xEV-DO Carriers In Single EVM For TheSingle Sector Configuration

Overview

FID 8219.14 enables the support for a combination of 1x carriers and more than one

1xEV-DO carrier for up to three carriers total in small cells. It also supports up to three

(3) 1xEV-DO carriers and no 1x carrier in these cells. It also allows for the deployment of

these configurations on the 9234 BTS d2U Distributed with one Baseband Unit (BBU).

Description

This feature enables multiple carriers in a one-sector cell configuration supported by one

SB-EVM, one radio (or two radios for dual band) and one URC/URC-II (or 2 for mixed

configurations of 1x and 1xEV-DO Rev A) . It provides physical pooling of Traffic

Channels across three carriers of a one-sector cell which allows all three carriers of the

cell to be supported by a single SB-EVM card.

The SB-EVM is served by one URC or URC-II for control and backhaul. A cell can be

configured for 1-sector or 3-sector carriers but not both. However, a radio must be added

for each additional sector.

Band classes and BTS types

The following frequency bands are supported:

• Band Classes: Single Band BC0 (800 MHz/Sub-Class 2)

• Single Band BC6 (2100 MHz)

• Dual Band BC0/BC6.

The following BTS types are supported for the multiple carriers/one sector feature:

• BTS: 9222 BTS CDMAMicro,

• 9224 BTS CDMASub-Compact,

• 9234 BTS d2U Distributed with 2 daisy-chained RRHs.

Hardware requirements

The following hardware requirements apply for the cells that use this feature:

• One URC-II (for 1xEV-DO)/1 URC (or URC-II) for 1x

One URC supports the three (3) 1x carriers/1 sector. However, a URC-II is required to

support three (3) fully loaded VoIP 1xEV-DO Rev A carriers/1 sector. Mixed 1x and

1xEV-DO Rev A carrier configurations require two URC-IIs (or URCs depending on

the carrier types and carrier loading), one for each technology.

• One SB-EVM (for up to 1S/3C DO) - Either the One-Tile version (B�J82) or the

Two-Tile version (B�J85) of the SBEVM is supported.

Hardware Components Support For Multiple 1xEV-DO Carriers In Single EVM ForThe Single Sector Configuration

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

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

4-24 401-614-323Issue 16 October 2009

Page 295: 1xev-Do Rf Engineering

• One CMU-IVB/V (for up to 1S/6C 1x).

• One MCR - Each cell requires an MCR version matching the Band Class it supports.

That is, a BC0 MCR or BC6 MCR.

• Amplifiers and Filter panel.

Dual band

The Dual Band configuration is offered only on the 9234 BTS d2U Distributed with 2

RRHs, each supporting a single band.

Mixed mode

The feature is applicable for both mixed mode cells (3G-1x and 1xEV-DO) and 1xEV-DO

only cells in a mixed mode network.

Mixed mode cells require the following for the 1x processing

• URC or URC-II (in addition to the URC-II that supports the 1xEV-DO Rev A carriers)

• CMU card

Both 1x and 1xEV-DO Rev A carriers for up to a total of three carriers are supported by

the same radio for each band.

Feature dependencies

FID 8219.14 depends on the following features:

• FID-12078.23: Support of a second tile in the SB-EVM..

• FID-13019.19: ALU 9234 BTS With Daisy Chaining of RRHS, User Alarms, and

Security Improvements.

• FID-14049.1: Initial Support For Dual Band BC0 SC2 and BC6

Customer control of power

Amplifiar power provisioning, controlled through software licensing, is maintained as

defined in FID-8022.2 (for BC0) and FID-13222.1 (for BC6). The following is a

summary of the power control:

• In the BC0 version of the supported one-sector cells, power is provisioned per

increment of 10 W/carrier from an initial 20 W/carrier.

• In the BC6 version of these cells, power is provisioned per increment of 8 W/carrier

from an initial 16 W/carrier.

The power enabling is part of one license that is issued per band class for the total power

of all the sector-carriers of the cells of the MSC/DO-R�C.

Hardware Components Support For Multiple 1xEV-DO Carriers In Single EVM ForThe Single Sector Configuration

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

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

401-614-323Issue 16 October 2009

4-25

Page 296: 1xev-Do Rf Engineering

References

For procedures on reassigning cells see CDMA2000 1xEV-DO Feature Provisioning

Guide, 401-614-413.

Hardware Components Support For Multiple 1xEV-DO Carriers In Single EVM ForThe Single Sector Configuration

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

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

4-26 401-614-323Issue 16 October 2009

Page 297: 1xev-Do Rf Engineering

Circuit Pack Location

Description

The digital card shelf backplane (Figure 4-6, “9218 Macro Digital Shelf Card Location”

(p. 4-27)) is functionally divided into four sections, where each section is dedicated to

receive circuit packs of a specific type. Except for the first section, which is dedicated for

URC, circuit packs may be placed in any slot within their dedicated sections.The first

section is a four-slot location where URCs can be placed in the first three slots. The fourth

slot is reserved for a redundant URC that will be available in a future release. The URC

provides T1/E1 facility interface via the I/O unit (IOU) for the digital card shelf (see

Figure 4-4, “9218 Macro Cabinet” (p. 4-10)).

9218 Macro Digital Shelf Card Location

Figure 4-6 9218 Macro Digital Shelf Card Location

Evolution Modem(4.0 EVM)

EVTx

EVRx

Part ofCDMA Modem

Unit (CMU) Section

Common TimingUnit (CTU) Section

Universal CDMARadio (UCR)* Section

Universal RadioControllers (URC)

Section

Part ofCDMA Modem

Unit (CMU) Section

Slot 1

Reserve forredundantURC

* Multi-Carrier Radio (MCR) may be used subsequent to Release R24.0

Hardware Components Circuit Pack Location

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

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

401-614-323Issue 16 October 2009

4-27

Page 298: 1xev-Do Rf Engineering

URC location

If the Ethernet Backhaul feature introduced in R24.0 is enabled, the T1/E1 line going to

the URC for 1xEV-DO is replaced a copper line Ethernet cable.

Modem or radio location

The second section is divided into two six-slot groupings, where the first group is

immediately after the URC section, occupying slots 5 through 10, and the second group is

the last six slots on the digital shelf, occupying slots 17 through 22. Generally, the first

two of the 12 slots are occupied the 4.0 EVM EVTx and EVRx modem boards and the

remaining slots may be occupied by CDMAmodem units (CMU) in base stations that

also provide IS-95 or 3G-1X service. The CMUs contain a number of the channel

elements (CE) that perform the signal spreading and de-spreading required by CDMA

baseband processing for IS-95 and 3G-1X.

CTU location

The third section is a two-slot position occupied by the common timing unit (CTU). The

CTU receives the timing signal from the GPS to maintain base station synchronization

with the other base stations in the CDMA network. Two CTU are generally installed

where the second CTU provides backup. Lastly, the fourth section is a six-slot position to

be occupied by Universal CDMARadio (UCR). The UCR provides radio processing

including peak limiting, overload control, and upbanding/downbanding for the

appropriate RF frequency.

Hardware Components Circuit Pack Location

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

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

4-28 401-614-323Issue 16 October 2009

Page 299: 1xev-Do Rf Engineering

Adding 1xEV-DO To AUTOPLEX® Cells

Description

1xEV-DO capabilities can be provided on the AUTOPLEX® Series II Double Density

Growth Frame (DDGF) and PCS CDMAMinicell via the collocation feature and antenna

sharing with a Flexent® cell. Adding a new 1xEV-DO carrier can be done by growing a

Flexent® cell (Modular cell) and using antenna sharing. The extent of antenna sharing is

limited by multiple factors and must be evaluated on a case-by-case basis. Factors to be

considered include:

• Existing antenna configuration

• Carrier frequency assignment

• Use of adjacent frequencies.

Two configurations of adding 1xEV-DO to AUTOPLEX® cells are discussed here:

• Duplex configuration

• Double Duplex configuration.

Duplex Configuration

Figure 4-7, “Collocation of 1xEV-DO Base Station with PCS CDMAMinicell” (p. 4-30)

shows the duplex configuration for adding the 1xEV-DO-configured Flexent® Base

Station to a CDMAMinicell. Three antennas are used for each section in a CDMA

Minicell/1xEV-DO Base Station collocation configuration. The first and second antennas

are connected to the CDMAMinicell cabinet transmit output port and to the received

input port for a duplex antenna connection. The first antenna is connected to the Tx0/Rx0

output/input ports and the second antenna is connected to the Tx1/Rx1 output/input ports.

The second antenna provides the receive diversity inputs for the CDMAMinicell and

1xEV-DO Modular cell cabinets as shown in Figure 4-7, “Collocation of 1xEV-DO Base

Station with PCS CDMAMinicell” (p. 4-30). Lastly, the third antenna is connected to the

Tx2/Rx0 output/input ports of the 1xEV-DO Modular Cell.

A Flexent® Base Station is required as an adjunct cabinet with an 1xEV-DO modified

CDM, as described in “Base Station cabinetsFlexent® CDMABase Station Cabinet”

(p. 4-4) for each 1xEV-DO carrier to be added to the base station. If the 1xEV-DO carrier

is to replace existing IS-95/3G-1X carrier(s), be sure to remove the carrier(s) from the

existing AUTOPLEX® base station equipment. In this configuration, duplex transmit and

receive is performed on separate antennas, and the two antennas are shared for diversity

operation.

Hardware Components Adding 1xEV-DO To AUTOPLEX® Cells

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

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

401-614-323Issue 16 October 2009

4-29

Page 300: 1xev-Do Rf Engineering

Double Duplex Configuration

A double duplex operation is achieved by connecting the transmit output for each sector

to both receive diversity antennas. Figure 4-8, “Collocation of 1xEV-DO Base Station

with CDMA AUTOPLEX® Series II DDGF Cells” (p. 4-31) shows the double duplex

configuration for adding 1xEV-DO capability to AUTOPLEX® cells. An additional

transmit antenna must be added for each service by each 1xEV-DO carrier. The receive

diversity antenna for each sector is shared with the Rx antennas on corresponding sector.

Figure 4-7 Collocation of 1xEV-DO Base Station with PCS CDMA Minicell

Tx0

Rx0

Rx1

Tx1

Rx0

Rx1

Tx2

Rx0

Rx1

CDMA Minicell 1xEV-DO Modular Cell

Tx0/Rx0 Tx1/Rx1 Tx2/Rx0

Hardware Components Adding 1xEV-DO To AUTOPLEX® Cells

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

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

4-30 401-614-323Issue 16 October 2009

Page 301: 1xev-Do Rf Engineering

Figure 4-8 Collocation of 1xEV-DO Base Station with CDMA AUTOPLEX® Series IIDDGF Cells

Tx0 Tx2

AUTOPLEX DDGF orPCS Minicell

Alcatel-LucentModular Cell

Tx0/Rx0 Tx1/Rx1 Tx2

Tx1

Rx0

Rx1

Rx0

Rx1

Rx1Rx0

Hardware Components Adding 1xEV-DO To AUTOPLEX® Cells

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

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

401-614-323Issue 16 October 2009

4-31

Page 302: 1xev-Do Rf Engineering

FMS and AP

AUTOPLEX® Mobility Server (FMS)

The AUTOPLEX®Mobility Server (FMS), which is show in Figure 4-9, “1xEV-DO

Flexent®Mobility Server (FMS) Cabinet” (p. 4-33), is central to the Radio Access

�etwork (RA�). The FMS frame contains four primary Sun™ �etra™ 400S servers and

four backups Sun™ �etra™ 400S servers. Each server provides the hardware platform

with a 1xEV-DO Application Processor (DO-AP) running the Sun™ Solaris™ Operating

System (OS) Version 9. Each AP is operated to perform the functionality of the 1xEV-DO

Controller and Packet Control Function (PCF). In addition the DO-APs, the FMS frame

includes the following:

• One Modular Filter and Fusing Unit (MFFU) shelf

• One Reliable Cluster Computing (RCC) shelf

• Two routers (Ethernet switches -one active, one standby).

1xEV-DO Application Processor (AP)

The four primary and backup DO-APs are mounted in the upper and lower universal

chassis as shown in Figure 4-9, “1xEV-DO Flexent®Mobility Server (FMS) Cabinet”

(p. 4-33). If any of the primary APs malfunction the AP is electrically removed from the

network, and its functions are automatically resumed by the backup AP located at its

corresponding position in the lower universal chassis.

Hardware Components FMS and AP

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

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

4-32 401-614-323Issue 16 October 2009

Page 303: 1xev-Do Rf Engineering

Figure 4-9 1xEV-DO Flexent® Mobility Server (FMS) CabinetModular Fuse/Filter

Unit (MFFU)(Front panel flipped up)

Reliable ClusterController (RCC)

Application Processor (DO-AP)(Netrl 400S Server)

Application Processor (DO-AP)(Netra 400S Server)

Maintenance InterfacePanel (MIP)

Router(EthernetSwitch)

Router(EthernetSwitch)

Upper Universal Chassis

Lower Universal Chassis

Hardware Components FMS and AP

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

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

401-614-323Issue 16 October 2009

4-33

Page 304: 1xev-Do Rf Engineering

Components of the DO-AP

The FMS requires a minimum of a primary and a backup DO-AP. Each DO-AP consists

of the following (refer to Figure 4-10, “1xEV-DOApplication Processor (400S Server)”

(p. 4-35)):

• One system disk drive to provide a local boot disk

• One Sun™ Ultra Sparc™ Central Processing Unit (CPU) card running the Solaris™ 9

operating system. Essentially, the CPU functions as the 1xEV-DO application

processor to perform Overhead Channel Management signaling processing and

OA&M control functions.

• Two Traffic Processes (TPs) that run on the VxWorks operating system to perform

signaling and traffic processing

• One alarm card:

– Support for reset, power up, and power down commands issued from the

Watchdog

– Integrated with the Modular Filter and Fusing Unit (MFFU) to provide alarm

indication such as temperature, power, and fan failures, in addition to providing

alarms for its associated server

• One Maintenance Interface Panel (MIP); allows connection of links to the Local

Maintenance Terminal (LMT) and external router components.

1xEV-DO Controller

The 1xEV-DO Controller is the Alcatel-Lucent computing platform modified to

accommodate 1xEV-DO requirements. This controller connects to multiple base stations

and provides call control and RLP functions including frame selection for the 1xEV-DO

RA�. The OA&M interface for the entire 1xEV-DO RA� is also provided as part of the

1xEV-DO Controller.

Packet Control Function (PCF)

The Packet Control Function (PCF) terminates the radio network and implements the

dormant mode. The PCF maintains a PPP connection with the base station to provide the

open R-P (A10-A11) interface with the PDS�. The PCF also maintains the re-connection

information to the AT for the PDS�, and buffers data from the network to the AT until

airlink resources can be allocated. In addition, the PCF collects and forwards

airlink-related accounting information to the PDS�.

Hardware Components FMS and AP

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

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

4-34 401-614-323Issue 16 October 2009

Page 305: 1xev-Do Rf Engineering

Figure 4-10 1xEV-DO Application Processor (400S Server)

Hard Drive (hidden)

CPU Card

Traffic Processors (TP)

Alarm Card

System Status Panel

Power Supply Unit

Power Supply UnitAir Filter

Hardware Components FMS and AP

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

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

401-614-323Issue 16 October 2009

4-35

Page 306: 1xev-Do Rf Engineering

MFFU, RCC and Router

Modular Fuse/Filter Unit (MFFU)

The Modular Fuse/Filter Unit (MFFU) provides independent fusing and -48 VDC power

distribution. The fuses are exposed under a flip-up cover panel. A chart under the panel

cover maps and identifies the circuit associated each fuse. The fuses are divided into two

banks. One bank fuse the primary circuits and other banks fuse the backup circuits. A

blown fuse is indicated by a red indicator at the upper right -hand corner of the fuse.

Reliable Cluster Computing (RCC)

The Reliable Cluster Computing (RCC) provides the software and hardware components

for increased reliability, availability, and maintainability. The RCC includes theWatchdog

hardware, a dedicated recovery and maintenance processor. The Watchdog connects to

each 400S server through two RS-232 lines; one to the AP computer, the other to the

alarm card.

Router (Ethernet Switch)

Two routers (Ethernet switches) are provided, one switch is active, and the other is on

standby. The router provides the physical and logical communication data links between

the network base stations and the components within the FMS, and also provides the

network links between the FMS components and the Packet Data Serving �ode (PDS�)

via 100baseT (Ethernet) interface specified for the R-P interface (also known as IOS

A10-A11 interface). The router also provides a data link between the OMC-RA� on the

OMP-FX, and to other servers within the FMS.

Hardware Components MFFU, RCC and Router

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

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

4-36 401-614-323Issue 16 October 2009

Page 307: 1xev-Do Rf Engineering

IP Network Elements

Introduction

This section briefly describes the functionality of the following network elements:

• PDS�

• IP network

• AAA Server.

Packet Data Service Node (PDSN)

The PDS� function is part of the packet data system that maintains the link layer to the

AT. The PDS� resides in the visited network and is allocated by the visited network

where the AT initiates a session. The PDS� terminates the PPP link protocol with the

mobile. The PDS� serves as a Foreign Agent in the Mobile IP network.

The PDS� maintains link layer information to the PCF and routes packets to external

packet data networks or to the Home Agent (HA) in the case of Mobile IP tunneling to the

HA. The PDS� is connected to the PCF by the R-P interface. The PDS� maintains either

a 100 Mbps Ethernet interface or an ATM interface to the service provider backbone IP

network.

The equipment may be provided by third-party vendors. For more information on the

PDS� and any other third-party vendor hardware, refer to the documentation provided by

the vendor.

IP Network

The IP network is comprised of routers, firewalls, and associated equipment needed to

connect the PCF to the customer network which, allows connection to the public Internet

or private networks, or both. The service provider supplies the IP network equipment.

Authentication, Authorization, and Accounting (AAA) Server

The AAA Server is required to authenticate terminal equipment users when they attempt

to establish a connection. In addition, the AAA Server stores information from the PDS�,

which is provided as input to the customer's billing system.

Hardware Components IP Network Elements

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

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

401-614-323Issue 16 October 2009

4-37

Page 308: 1xev-Do Rf Engineering

Deployment Scenarios

Introduction

This topic discusses two deployment scenarios for 1xEV-DO:

• Overlay deployment (mix system)

• Stand-alone deployment.

Overlay Deployment

1xEV-DO deployment is relatively straightforward when evolving from IS-95 and 3G-1X

networks. This is because 1xEV-DO utilizes the same carrier bandwidth as IS-95 and

3G-1X. Furthermore, 1xEV-DO has a similar coverage footprint (see Chapter 5, “RF

Coverage and Capacity”). Therefore, Alcatel-Lucent recommends that 1xEV-DO be

overlaid on 3G-1X (or IS-95) in a 1:1 fashion.

The coverage footprint in a stand-alone environment is determined by the operator's target

data rate at the cell edge. Higher user channel rate targets at the cell edge require smaller

cells, and correspondingly more cells.

1xEV-DO requires that a network operator have a good understanding of the demand for

data services. 3G-1X has the advantage that the carrier can support both data and voice.

1xEV-DO has the advantage of having higher data capacity (i.e., average sector

throughput) and higher peak channel rates.

In the overlay or mixed cell environment, the footprint of the existing network being

overlaid determines the footprint of the 1xEV-DO carriers. The design engineer can

determine both reverse and forward data rates that can be expected at the cell edge by

examining the link budgets. If the design engineer has traffic maps and customer input

about traffic patterns of subscribers (e.g., data calls during the busy hour, length of those

calls, data downloaded, etc.), they could deduce conclusions about the throughput per

subscriber, based on the sector capacity.

Stand-Alone Deployment, Coverage Design

In the case of a greenfield design or stand-alone deployment in which the fewest number

of base stations is desirable, the design engineer would start by determining the data rate

desired at the cell edge in both the uplink and downlink directions. The design engineer

would then examine the link budgets to see what maximum allowable path loss can be

supported for the desired rate. The smaller value is the limiting link, which determines the

cell footprint. As in the case with overlay deployment, if the design engineer has traffic

maps and customer input about traffic patterns of subscribers, they can deduce

conclusions about the throughput per subscriber, based on the sector capacity.

Hardware Components Deployment Scenarios

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

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

4-38 401-614-323Issue 16 October 2009

Page 309: 1xev-Do Rf Engineering

In the case of a greenfield design which the customer wants to ensure meets certain

capacity, the design engineer would start with traffic maps and customer input about

traffic patterns of subscribers (e.g., data calls during the busy hour, length of those calls,

data downloaded, etc.). The design engineer utilizes enough cells to meet the customer

demand. At the end of the design the design, the engineer must also check that all

geographic areas meet certain minimum link budget constraints.

Hardware Components Deployment Scenarios

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

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

401-614-323Issue 16 October 2009

4-39

Page 310: 1xev-Do Rf Engineering
Page 311: 1xev-Do Rf Engineering

5 5RF Coverage and Capacity

Overview

Purpose

The design for RF coverage and capacity for stand-alone deployment begins with the

calculation of the Reverse link (uplink) and forward link (downlink) budgets to determine

the base station coverage area for a desirable data rate at the cell forward edge. If the

1xEV-DO base station is being overlaid in a mixed 3G-1X/IS-95 environment,

Alcatel-Lucent strongly recommends that the 1xEV-DO base station coverage be aligned

to the 3G-1X/IS-95 coverage area, thereby greatly simplifying the link budget task

associated with base station deployment.

The objective of reverse link budget analysis is to calculate the maximum path loss value

permitted that will result in a quality signal at the receiver. The result of this calculation is

a dB value that represents the maximum amount of attenuation the AT signal is permitted

to encounter as the AT user travels away from the base station. If the AT user continues to

travel away from the base station, assuming that no candidate sectors are able to accept a

handoff, the maximum path loss value is exceeded, and the signal quality will be

diminished to a point at which the call is dropped.

Although link budget calculation and analysis for 1xEV-DO is similar to those performed

in 3G-1X and IS-95, a number of differences must be considered.

As in all RF technologies, coverage estimates for planning purposes can be obtained

through the use of link budget tools. This section will examine the link budgets for the

reverse link. Reverse link budget analysis is used to establish the cell footprint for a given

data rate.

Contents

Reverse Link Budget Analysis 5-3

Reverse link description 5-4

Maximum Path Loss 5-6

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

401-614-323Issue 16 October 2009

5-1

Page 312: 1xev-Do Rf Engineering

Reverse Link Budget 5-9

Radiated power, antenna gain and losses 5-14

Total Effective �oise plus Interference Density 5-15

Receiver Sensitivity 5-19

Required Eb/�t, Item l 5-21

Soft Handoff Gain 5-24

Path loss 5-25

Forward Link Budget Analysis 5-28

Forward link description 5-29

Forward Link factors 5-31

Link Budget Calculation 5-34

Forward Link Budge Spreadsheet 5-36

Transmit Power Calculation 5-42

Total Interference 5-44

Capacity Overview 5-48

Rev A and Rev 0 Sector capacity 5-49

Capacity/Coverage Trade-off 5-50

Pole Capacity 5-52

Reverse Link Capacity 5-54

Spectral �oise Density 5-55

Pole Capacity Calculation 5-57

Channel Gain 5-59

Interference ratio and channel activity 5-62

Increased capacity in the reverse link 5-64

Traffic Model 5-65

Rev A performance 5-67

Pole Point Based Capacity Calculation 5-69

Capacity Objectives 5-71

Data Traffic Load in Erlangs 5-72

Determining Average �umber of Reverse Link Channels Required 5-75

Forward Link Capacity 5-78

Geometry 5-79

Sector Throughput 5-80

RF Coverage and Capacity Overview

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

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

5-2 401-614-323Issue 16 October 2009

Page 313: 1xev-Do Rf Engineering

Reverse Link Budget Analysis

Overview

Purpose

A link budget analysis is a series of mathematical calculations, signal gains, and losses as

it travels from transmitter to receiver. In a typical duplex wireless system, two link budget

calculations exist: a forward link or downlink from the base station to the AT or mobile

unit, and a reverse link or uplink from the AT or mobile unit to the base station. Link

budgets are used to derive maximum path losses for forward and reverse wireless

communication links that meet a design criteria for reliability and performance.

Contents

Reverse link description 5-4

Maximum Path Loss 5-6

Reverse Link Budget 5-9

Radiated power, antenna gain and losses 5-14

Total Effective �oise plus Interference Density 5-15

Receiver Sensitivity 5-19

Required Eb/�t, Item l 5-21

Soft Handoff Gain 5-24

Path loss 5-25

RF Coverage and Capacity Reverse Link Budget AnalysisOverview

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

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

401-614-323Issue 16 October 2009

5-3

Page 314: 1xev-Do Rf Engineering

Reverse link description

Introduction

A link budget calculation is a full accounting of the RF signal level gains and losses as the

signal travels from transmitter to receiver. This accounting is a budget of signal gains and

losses with respect to interference and noise levels to obtain the maximum path loss

permitted that will result in an acceptable signal quality at the receiver. A balance must be

achieved between gains and losses so that the transmit signal received by the base station

from an AT at the edge of the coverage area is minimally above the total noise and

interference experienced at its receiver to ensure acceptable quality.

CDMA systems trade-off between signal quality, coverage (cell radius), and capacity

(data throughput). Traditionally, in IS-95 and 3G-1X systems, voice quality is the ultimate

criterion to consider when determining the link budget. Once a voice quality objective is

defined, this trade-off is narrowed between coverage and capacity. However, because

1xEV-DO eliminates voice transmission and the real-time restriction associated with high

voice signal, high quality associated with voice is also eliminated, essentially reducing the

trade-off between coverage and capacity. As capacity increases, coverage decreases. For

data, capacity is measured as the data throughput on a carrier.

Reverse Link Similarity with 3G-1X

The reverse link of a 1xEV-DO carrier is similar to the reverse link of a 3G-1X carrier.

Unlike the forward link, which is time-shared with each active user, the 1xEV-DO reverse

link is CDMA code-shared with embedded pilot pulses for coherent detection, and has

similar power control and data rate (9.6 to 153.6 kbps) schemes with 3G-1X. In addition,

the 1xEV-DO reverse link enables soft handoff similar to 3G-1X.

However, the 1xEV-DO reverse link differs from 3G-1X in that 1xEV-DO does not have

fundamental and supplemental channels, and that the reverse link data rate is dynamically

controlled by the base station based on sector loading. The AT initiates its transmission

data rate at 9.6kbps and may incrementally increase or decrease its data rate after every

26.67-ms frame following a transition probability based on RAB (Reverse Activity Bit)

set by the base station. The data rate selected by the AT is reported to the base station via

a data rate control (DRC) channel. The 1xEV-DO reverse link data rate is indicated by an

RRI (Reverse Rate Indicator) channel on the reverse link that is used to inform the base

station of the rate that the AT is transmitting.

Forward and Reverse Link Limitations

Depending upon the market strategy, environment, and/or cost, sector coverage may be

either reverse (uplink) -or forward (downlink)-limited. Generally, the limiting factor for

uplink-and downlink-limited designs is the limitation of the transmitted power. In

1xEV-DO, the cell radius is essentially limited by the AT transmit power. Therefore, an

RF Coverage and Capacity Reverse Link Budget AnalysisReverse link description

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

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

5-4 401-614-323Issue 16 October 2009

Page 315: 1xev-Do Rf Engineering

uplink-limited design approach is recommended where reversed link budget analysis is

conducted first to determine the reverse link maximum path loss for a given data rate at

the cell perimeter. When considering the reverse link budget, the signal power level

received at the base station from an AT located anywhere throughout over 90% of the

sector coverage area must be sufficient to provide an acceptable quality. Subsequently, a

forward link budget analysis is required to determine if the footprint of coverage

established by the reverse link budget can be supported. When considering the forward

link budget, the transmit signal power level at the cell perimeter must be sufficient to

provide an acceptable signal quality at a predefined data rate over 90% of the sector

coverage perimeter.

RF Coverage and Capacity Reverse Link Budget AnalysisReverse link description

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

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

401-614-323Issue 16 October 2009

5-5

Page 316: 1xev-Do Rf Engineering

Maximum Path Loss

Maximum Path Loss Components

The reverse link budget analysis is performed to compute the maximum allowable path

loss between the Access Terminal (AT) transmit antenna and the cell site receive antenna.

If forward link analysis indicates that the forward link can support performance at the

same loss, the maximum path loss can be used on a market-by-market basis in the RF

design. This design process employs algorithms that map loss into cell radii via

consideration of local variables such as tower height, terrain, and clutter.

The allowed point-to-point path loss is determined by considering the terms that dictate

net loss from the AT to the cell. Components of the net loss are indicated in Figure 5-1,

“Components of �et Path Loss fromAT to Base Station” (p. 5-6).

Maximum Path Loss Calculation

The terms characterizing the net loss are captured in the following relation:

Figure 5-1 Components of Net Path Loss from AT to Base StationAntenna

Gain

Vegetation

Buildings

Penetration Loss

Access TerminalEIRP

ReceiverSensitivity

(S )min

Maximum Path loss

Cable Loss

RF Coverage and Capacity Reverse Link Budget AnalysisMaximum Path Loss

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

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

5-6 401-614-323Issue 16 October 2009

Page 317: 1xev-Do Rf Engineering

where:

• Xmax = MaximumAT transmit power (EIRP) out of the antenna (in dBm)

• HL = Head and body loss (in dB)

• BL+VL = Building and vegetation (and other) penetration loss (in dB)

• PL = Average path loss between AT antenna and cell site antenna (in dB)

• fade = Fade at AT location (in dB)

• AG = Cell site antenna gain (in dBi)

• CL = Cell site cable loss (in dB)

• Smin = Base station receiver sensitivity (in mW, converts to dBm).

The maximumAT transmit power (Xmax) must be sufficient to overcome the maximum

path loss so that the signal power received at the base station transmit I/O port J4 port

(antenna connector) is equal to or exceeds the base station receiver sensitivity, Smin.

The above expression is rewritten for the allowed maximum dB path loss. This value

dictates the edge (boundary) of the cell coverage.

The above expression can be viewed as constructing the allowed maximum path loss as a

dB sum of credits (e.g., AT transmit power) and deficits (e.g., cable loss). This dB process

is captured in the reverse link budget.

Maximum AT Transmit Power

The Effective Isotropic Radiated Power (EIRP) or Effective Radiated Power (ERP) is the

power out of the antenna and equals the sum (in dB) of the AT transmit power and the AT

antenna gain. The difference between EIRP and ERP is 2.15dB. Table 5-1 shows the

maximum transmit power for 850 MHz and 1900 MHz as defined by the standard.

Table 5-1 Maximum AT Transmit Power

Frequency Band [MHz] Maximum AT EIRP [dBm]

850 25

1900 23

Figure 5-2 Equation 1Xmax PL– –HL fade– BL VL+( ) + ( )– AG CL– 10log Smin

Figure 5-3 Equation 2

PL Xmax HL– fade– BL VL+( ) ( )+≤ – AG CL– – 10log Smin

RF Coverage and Capacity Reverse Link Budget AnalysisMaximum Path Loss

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

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

401-614-323Issue 16 October 2009

5-7

Page 318: 1xev-Do Rf Engineering

Shadow Fading

The uplink maximum path loss is the maximum loss in signal strength permitted as an AT

signal is propagated outward in space. As illustrated in Figure 5-1, “Components of �et

Path Loss fromAT to Base Station” (p. 5-6), in an actual application, the AT signal does

not always travel in free space, and the propagation path between transmitter and receiver

will be obstructed. Losses attributed to obstructions in the signal propagation path are

referred to as shadow fading or slow fading losses, which result in the dispersion of the

received signal strength at a fixed distance from the cell site.

The obstructions, primarily from tall buildings and heavy vegetation, cast RF shadows on

the paths leading away from the AT. Other losses are body losses; the user may be

positioned between the AT and base station antenna. �ormally, the shadow paths are not

completely darkened due to RF signal reflection from other surrounding buildings. Signal

reflection from a large number of buildings, which is typical in an urban environment,

causes random in-phase reinforcement and interference with the RF signal. Reflected

signals may reinforce each, producing a gain. As a result, the actual path loss or gain at

any point in such an environment will vary as a function of the predictable path loss and

unpredictable shadow fading loss.

RF Coverage and Capacity Reverse Link Budget AnalysisMaximum Path Loss

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

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

5-8 401-614-323Issue 16 October 2009

Page 319: 1xev-Do Rf Engineering

Reverse Link Budget

Introduction

The objective of reverse link budget analysis is to calculate the maximum uplink path loss

value permitted that will result in a quality signal at the receiver. The result of this

calculation is a dBi value that represents the maximum path loss attenuation (with respect

to an isotropic antenna) an AT transmitted signal is permitted to encounter as the AT user

travels away from the base station. If the AT user continues to travel away from the base

station, assuming that no candidate sectors are able to accept a handoff, the maximum

path loss value is exceeded, and the received signal quality will be diminished to a point

that the call is dropped.

Typical link budget analysis

A typical link budget analysis form for 90% area coverage at different data rates is shown

in Table 5-2, “PCS Reverse Link Budget Spreadsheet” (p. 5-9) , in Rev 0 and Tables 5-3

and 5-4, in Rev A. By accounting for sources of path loss, noise interference, and margins

for specified signal quality and loading, which is the amount of traffic on a carrier, as well

as sources for signal gains, the maximum allowable path loss for the reverse link can be

determined.

After the maximum allowable path loss is determined, its value is inserted into a

propagation model or propagation tool to determine the cell radius for a given

quality.Multiple propagation models and tools are available, which address a variety of

environmental and geographic situations and base station antenna heights.

PCS Reverse Link Budget Spreadsheet

Table 5-2 PCS Reverse Link Budget Spreadsheet

Line Item Units 3G-1X

(for com-

parison)

1xEV-DO Traffic Channel Rate (kbps) Comments

9.6 19.2 38.4 76.8 153.6

a Maximum

Transmitted

power per traffic

channel at

antenna port

dBm 21 21 21 21 21 21

b Transmitter

Antenna Gain

dBi 2 2 2 2 2 2

c Transmitter EIRP

per traffic

channel

dBm 23 23 23 23 23 23 c = a+b

d Body/head loss dB 2 0 0 0 0 0 �o body loss for data

RF Coverage and Capacity Reverse Link Budget AnalysisReverse Link Budget

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

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

401-614-323Issue 16 October 2009

5-9

Page 320: 1xev-Do Rf Engineering

Table 5-2 PCS Reverse Link Budget Spreadsheet (continued)

Line Item Units 3G-1X

(for com-

parison)

1xEV-DO Traffic Channel Rate (kbps) Comments

9.6 19.2 38.4 76.8 153.6

e Receiver

Antenna Gain

dBi 18 18 18 18 18 18 Assuming three sector

antennas

f Receiver Cable

and Connector

Losses

dB 3 3 3 3 3 3 Typical value

g Receiver �oise

Figure

dB 4 4 4 4 4 4 See “Receiver �oise

Figure” (p. 5-16)

h Receiver �oise

Density

dBm/Hz -174 -174 -174 -174 -174 - 174 See “Receiver �oise

Density” (p. 5-17)

I Receiver

Interference

Margin

dB 5.5 5.5 5.5 5.5 5.5 5.5 Assume 72% loading

j Total Effective

�oise plus

Interference

Density

dBm/Hz -164.5 -164.5 -164.5 -164.5 -164.5 -164.5 j =g+h+I

k Information Rate

(10log(Rb)

dB 39.8 39.8 42.8 45.8 48.9 51.9 See “Information Rate

(10logRb), Item k”

(p. 5-19)

l Required Eb/�t dB 4 6 4.5 3.6 3.2 6 See “Description”

(p. 5-21)

m Receiver

sensitivity

dBm -120.9 -118.9 -117.3 -115.3 -112.8 -108.0 m=j+k+l+correction

n Soft Hand-off

Gain

dB 4 4 4 4 4 4 95% area coverage case,

only applicable to soft

handoff regions

o Explicit diversity

Gain

dB 0 0 0 0 0 0

p Log-normal fade

margin

dB 10.3 10.3 10.3 10.3 10.3 10.3 Assuming 8 dB

standard deviation of

fading, 90% edge

coverage = 95% area

coverage

q Building/Vehicle

Penetration Loss

dB 0.0 0.0 0.0 0.0 0.0 0.0 Customer input, 0 here

for comparison of ”on

street” coverage

r Maximum Path

Loss w/respect to

isotropic

antennas

dBi 150.6 150.6 149.0 147.0 144.5 139.7 r=c-d-m+e-f+o+n-p-q

RF Coverage and Capacity Reverse Link Budget AnalysisReverse Link Budget

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

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

5-10 401-614-323Issue 16 October 2009

Page 321: 1xev-Do Rf Engineering

PCS 1xEV-DO Rev A reverse link budget (first 6 lower data rates)

Except for the first line item, Effective Data Rate with HARQ, the reverse link analysis

form presented in Table 5-3, “PCS 1xEV-DO Rev A reverse link budget (first 6 lower data

rates)” (p. 5-11) and Table 5-4, “PCS 1xEV-DO Rev A reverse link budget (last 6 upper

data rates)” (p. 5-12) is a standard form used for IS-95/3G-1X and 1xEV-DO Rev 0. A

closer look at the link budget analysis form shows 18 items, numbered a through r. These

are all of the items that should be accounted for when computing the maximum allowable

path loss, which is listed as Item r. Except for Item l, the values entered for each item are

much the same values that can be entered, regardless of whether the link budget is

prepared for IS-95, 3G-1X, or 1xEV-DO Rev 0 or Rev A. Because Rev A introduces new

data new values for these data rates will appear for line item k, Information Rate

(10log(Rb)).

The data rate given does not allow for hybrid-ARQ early termination and only considers a

full 16-slot frame transmission. The first line item, Effective Data Rate with HARQ

(Hybrid-ARQ), does provide for early termination, which is assumed to average between

the second (8 slots) and third (12 slots) sub-frames.

Table 5-3 PCS 1xEV-DO Rev A reverse link budget (first 6 lower data rates)

Line Item UnitsData rate (kbps) in 16-slot period

Comment4.8 9.6 19.2 28.8 38.4 57.6

Effective Data rate with

HARQkbps 8.8 17.5 34.8 51.2 67.1 101.1

a

Maximum Transmitted

power per traffic channel at

antenna input

dBm 21 21 21 21 21 21

b Transmitter Antenna Gain dBi 2 2 2 2 2 2

cTransmitter EIRP per traffic

channeldBm 23 23 23 23 23 23 =a+b+c

d head/body loss dB 0 0 0 0 0 0 �o body loss for data

e Receiver Antenna Gain dBi 18 18 18 18 18 18 Assumed value

fReceiver Cable and

Connector LossesdB 3 3 3 3 3 3 Assumed value

g Receiver �oise Figure dB 4 4 4 4 4 4

h Receiver �oise Density dBm/Hz -174 -174 -174 -174 -174 -174

IReceiver Interference

MargindB 5.5 5.5 5.5 5.5 5.5 5.5

jTotal Effective �oise plus

Interference DensitydBm/Hz -164.5 -164.5 -164.5 -164.5 -164.5 -164.5 =g+h+I

kInformation Rate

(10log(Rb))dB 36.8 39.8 42.8 44.6 45.8 47.6

l Total Required Eb/�t dB 6.8 4.9 3.9 3.4 3.3 2.7

RF Coverage and Capacity Reverse Link Budget AnalysisReverse Link Budget

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

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

401-614-323Issue 16 October 2009

5-11

Page 322: 1xev-Do Rf Engineering

Table 5-3 PCS 1xEV-DO Rev A reverse link budget (first 6 lower data rates)

(continued)

Line Item UnitsData rate (kbps) in 16-slot period

Comment4.8 9.6 19.2 28.8 38.4 57.6

m Receiver sensitivity dBm -121.0 -120.0 -118.1 -116.9 -115.9 -114.8 =j+k+l+correction

n Soft Hand-off Gain dB 4.1 4.1 4.1 4.1 4.1 4.1

95% area coverage case,

only applicable to soft

handoff regions

o Explicit diversity Gain dB 0 0 0 0 0 0

p Log-normal fade margin dB 10.3 10.3 10.3 10.3 10.3 10.3

Assuming 8 dB standard

deviation of fading, 90%

edge coverage = 95% area

coverage

qBuilding/Vehicle Penetration

LossdB 0.0 0.0 0.0 0.0 0.0 0.0 Assumed value

r

Maximum Path Loss

w/respect to isotropic

antennas

dBi 152.9 151.8 149.9 148.7 147.7 146.7

PCS 1xEV-DO Rev A reverse link budget (last 6 upper data rates)

Table 5-4 PCS 1xEV-DO Rev A reverse link budget (last 6 upper data rates)

Line Item UnitsData rate (kbps) in 16-slot period

comment57.6 76.8 115.2 153.6 230.4 307.2 460.8

Effective Data rate with

HARQkbps 101.1 130.2 196.9 257.1 374.6 478.1 717.2

a

Maximum Transmitted

power per traffic channel

at antenna input

dBm 21 21 21 21 21 21 21

b Transmitter Antenna Gain dBi 2 2 2 2 2 2 2

cTransmitter EIRP per

traffic channeldBm 23 23 23 23 23 23 23 =a+b+c

d head/body loss dB 0 0 0 0 0 0 0 �o body loss for data

e Receiver Antenna Gain dBi 18 18 18 18 18 18 18 Assumed value

fReceiver Cable and

Connector LossesdB 3 3 3 3 3 3 3 Assumed value

g Receiver �oise Figure dB 4 4 4 4 4 4 4

h Receiver �oise Density dBm/Hz -174 -174 -174 -174 -174 -174 -174

IReceiver Interference

MargindB 5.5 5.5 5.5 5.5 5.5 5.5 5.5

RF Coverage and Capacity Reverse Link Budget AnalysisReverse Link Budget

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

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

5-12 401-614-323Issue 16 October 2009

Page 323: 1xev-Do Rf Engineering

Table 5-4 PCS 1xEV-DO Rev A reverse link budget (last 6 upper data rates)

(continued)

Line Item UnitsData rate (kbps) in 16-slot period

comment57.6 76.8 115.2 153.6 230.4 307.2 460.8

jTotal Effective �oise plus

Interference DensitydBm/Hz -164.5 -164.5 -164.5 -164.5 -164.5 -164.5 -164.5 =g+h+I

kInformation Rate

(10log(Rb))dB 47.6 48.9 50.6 51.9 53.6 54.9 56.6

l Total Required Eb/�t dB 2.7 2.8 2.1 2.1 1.7 1.8 3.4

m Receiver sensitivity dBm -114.8 -113.7 -112.9 -111.9 -111.0 -110.1 -108.5 =j+k+l+correction

o Soft Hand-off Gain dB 4.1 4.1 4.1 4.1 4.1 4.1 4.1

95% area coverage

case, only applicable to

soft handoff regions

p Explicit diversity Gain dB 0 0 0 0 0 0 0

q Log-normal fade margin dB 10.3 10.3 10.3 10.3 10.3 10.3 10.3

assuming 8 dB

standard deviation of

fading, 90% edge

coverage = 95% area

coverage

rBuilding/Vehicle

Penetration LossdB 0.0 0.0 0.0 0.0 0.0 0.0 0.0 Assumed value

s

Maximum Path Loss

w/respect to isotropic

antennas

dBi 146.7 145.6 144.7 143.8 142.8 142.0 140.3

Explanation of form

The reverse link analysis form presented in Table 5-2, “PCS Reverse Link Budget

Spreadsheet” (p. 5-9) is a standard form used for IS-95 and 3G-1X. A closer look at the

uplink link budget analysis form shows 18 items numbered a through r. These are all of

the items that should be accounted for when computing the maximum path loss, which is

listed as Item r. Except for Items b, k, and l, the values entered for each item are much the

same values that can be entered, regardless of whether the link budget is prepared for

IS-95, 3G-1X, or 1xEV-DO. To illustrate this, the link budget values for 3G-1X voice is

also shown. When used for 1xEV-DO, signal gain and loss may be more apparent in

certain items, such as Items a through f, than others. Item d, Body/head Loss, is only

applicable to voice mobiles which are held against the user's ear, and is used to account

for the possibility that the user may be between the mobile and the base station

transmitting antenna.

RF Coverage and Capacity Reverse Link Budget AnalysisReverse Link Budget

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

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

401-614-323Issue 16 October 2009

5-13

Page 324: 1xev-Do Rf Engineering

Radiated power, antenna gain and losses

Effective Isotropic Radiated Power (EIRP)

Items a through g on the link budget analysis are a function of the equipment used. The

AT effective isotropic radiated power (EIRP) is computed on line c and is equal to AT

maximum transmit, Item a, plus the AT antenna gain, Item b.

Receiver Antenna Gain Minus Cable and Connector Losses

Gains and loses at the base station receiver are accounted for on line Items e through j.

First, the receiver antenna gain, which is relative to an isotropic antenna and the receiver

cable and connector losses, are entered as Items e and f. Ultimately, when the maximum

path loss is computed for Item r, the receiver cable and connector loss are subtracted from

the base station receiver antenna gain.

RF Coverage and Capacity Reverse Link Budget AnalysisRadiated power, antenna gain and losses

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

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

5-14 401-614-323Issue 16 October 2009

Page 325: 1xev-Do Rf Engineering

Total Effective Noise plus Interference Density

Description

�ext, the Total Effective �oise plus Interference Density, Item j, which is referred to as

the receive noise floor, is computed by summing three noise/interference components:

• Receiver noise figure, Item g

• Receiver noise density, Item h

• Receiver interference margin, Item i.

Theoretically, a cell coverage area is primarily limited by the base station receiver

sensitivity; that is, its ability to discriminate the signal from noise and interference. The

noise refers to the noise floor of the base station receiver. Any component that increases

the level of the receiver noise floor effectively reduces the cell radius by requiring a

higher signal input level to the base station receiver, as shown in Figure 5-4, “Path Loss

Slope” (p. 5-16).

RF Coverage and Capacity Reverse Link Budget AnalysisTotal Effective Noise plus Interference Density

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

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

401-614-323Issue 16 October 2009

5-15

Page 326: 1xev-Do Rf Engineering

Path Loss Slope

This figure shows the attenuation of the AT transmit effective radiated power as the

distance increases. The AT transmit affected radiated power must exceed the path loss

slope by a predetermined fade margin over the base station receiver noise floor. The

predetermined fade margin is entered into the link budget form as Item p, and is discussed

in “Shadow Fading” (p. 5-8).

Receiver Noise Figure

The receiver noise figure is the noise generated by the receiver preamplifier. For the

purpose of link budget analysis, this value is set to 4 dB.

Figure 5-4 Path Loss Slope

Receiver noise floor

Receiver input power

Effective RadiatedPower

Mobile

Distance

Po

wer

r = cell coverage radius

Effective transmit power attenuatedby path slope as distance increase

Maximum Path Loss

Required Margin

Receiver noise

RF Coverage and Capacity Reverse Link Budget AnalysisTotal Effective Noise plus Interference Density

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

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

5-16 401-614-323Issue 16 October 2009

Page 327: 1xev-Do Rf Engineering

Receiver Noise Density

The receive noise density of typical base station is derived from Boltzman's constant,

which is 1.38 X 10-23 Joules/° Kelvin (or Watts X Seconds). This value quantifies the

thermo-kinetic energy of particles at a given temperature as a result of the random motion

of its electrons. This random electron motion generates electrical noise that is directly

proportional to the particle temperature; as the temperature increases, the noise level

increases.

Because the electron activity is truly random, the rms electrical noise power level is

equally distributed throughout the frequency spectrum. Typically, the noise is -174

dBm/Hz, which is the internal noise density of a perfect amplifier at room temperature,

assumed to be at 290° Kelvin.

Receiver Interference Margin

The receiver interference margin, which is sometimes referred to as a loading margin or

noise rise, accounts for signal interference from all other CDMA users on the same

carrier. The link budget design must use a receiver interference margin to protect against

too much coverage area shrinkage. Cell shrinkage occurs when, due to an increase in

usage, the ATs in the coverage area must transmit at higher power level or lower data rate

to overcome the increase in receiver interference. Effectively, the AT range is decreased,

causing the cell coverage area to shrink. The receiver interference margin provides a

built-in overlap to avoid the creation of holes resulting from shrinkage. The receiver

interference margin is a function of the percentage of theoretical maximum capacity or

pole capacity for the sector (refer to Figure 5-5, “Determining Receiver Interference

Margin” (p. 5-18)).

RF Coverage and Capacity Reverse Link Budget AnalysisTotal Effective Noise plus Interference Density

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

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

401-614-323Issue 16 October 2009

5-17

Page 328: 1xev-Do Rf Engineering

Determining Receiver Interference Margin

Description

The pole capacity shows the maximum theoretical capacity at a specific quality objective.

At maximum capacity, the coverage is, at its minimum, zero miles. This is because at

maximum capacity, or 100% loading, the noise rise is so high that the AT does not have

enough power to achieve the required signal level. Therefore, to have an appreciable

coverage, a load factor is introduced. The load factor selected is a function of the

percentage of the pole capacity that the service provider is willing to trade off for

coverage.

Figure 5-5, “Determining Receiver Interference Margin” (p. 5-18) shows that as the load

factor increases from zero to 100 percent, the total noise level will increase from zero dB

to infinity. When designing a system, an engineering or policy decision is made in

determining what load factor to use. Whenever a load factor is selected, its associated

interference level must be accounted for in the link budget. If the load factor is too low,

capacity is .If the load factor too high, coverage is sacrificed. A good place to start is in

the fairly linear region between 50 and 75 percent. Because of its faster power control and

uplink pilot channel, 3G systems are tolerant of slightly more noise, and the load factor

can be set closer to the 75 percent region. Typically, 72 percent corresponds to a noise rise

of 5.5 dB.

Figure 5-5 Determining Receiver Interference Margin

The receiver interference margin, sometimes referredto as loading margin, accounts for the interferencecontributed by other users in the environment. Here,the relationship between interference and percentage ofloading is illustrated.

0 10 20 30 40 50 60 70 80 90 100Percent Loading

0

2

4

6

8

10

12

14

16

18

20N

ois

e R

ise (

dB

)

5.5

72%

RF Coverage and Capacity Reverse Link Budget AnalysisTotal Effective Noise plus Interference Density

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

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

5-18 401-614-323Issue 16 October 2009

Page 329: 1xev-Do Rf Engineering

Receiver Sensitivity

Description

As stated in the previous section, the base station receiver sensitivity is the receiver's

ability to discriminate the signal from noise and interference. Specifically, in reference to

the CDMA link budget analysis form, receiver sensitivity, entered as link budget Item m,

can be regarded as a parameter that determines the power (in dBm) required at the input

of the CDMA receiver to maintain a desired frame error rate (FER). This power level is

equal to the power level at the base station antenna plus the antenna gain less the antenna

cable and connector loss:

where:

Smin = Receiver input power level Pant = Base station antenna gain input power level from

a single ATGant = Base station antenna gain Lcab = Antenna cable and connector loss.

Smin Signal Quality

The quality of the Smin signal is determined by its signal-to-noise ratio. In CDMA, this

ratio is expressed as energy per bit divided by the total ambient noise and interference

level (Eb/�t, commonly pronounced as eb-no). The energy per bit is calculated by

dividing the receive power, Smin , which expressed in Joules/second rather than watts, by

the data bit rate, R:

The noise refers to the receiver noise floor calculated for Item j. The receiver sensitivity

must also account for signal bit levels above the RF ambient noise level, which is

computed as energy per bit divided by the total ambient noise and interference level

(Eb/�t) and the receive data rate, and is computed by summing Items j through l.

Information Rate (10logRb), Item k

Item k is an attenuation value to compensate for the various reverse link data rates. The

higher the data, the greater the number of bits transmitted per unit of time, consuming a

greater portion of the AT finite transmit power, and therefore reducing the AT transmit

range. To account for this reduction in range, an information rate attenuation value is

Figure 5-6 Equation 3Smim Pant Gant Lcab–+=

Figure 5-7 Equation 4

Eb = (Joules/bit)= =(bit/ )second

(Joules/ )secondR

Prcv

RF Coverage and Capacity Reverse Link Budget AnalysisReceiver Sensitivity

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

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

401-614-323Issue 16 October 2009

5-19

Page 330: 1xev-Do Rf Engineering

entered for Item k and is computed by taking ten times the log of the data rate. For

example, when designing a cell for a reverse link data rate of 38.4, the information rate

value is 45.8 dB (10 X log 38.4 = 45.8). When designing a new system, one that will not

be overlaid on an existing system, the desired data rate at the cell should be determined at

this time.

RF Coverage and Capacity Reverse Link Budget AnalysisReceiver Sensitivity

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

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

5-20 401-614-323Issue 16 October 2009

Page 331: 1xev-Do Rf Engineering

Required Eb/Nt, Item l

Description

The quality of the signal received at the base station is determined by the strength of the

carrier signal level (that is, its bit energy) above the noise and, more importantly,

interference levels. As stated earlier in this chapter, in CDMA the signal to noise

relationship is measured as the bit energy bit-to-total noise ratio, or Eb/�t. The larger the

Eb/�t value, the higher the signal quality. In 1xEV-DO, the signal quality can be

measured by the packet error rate (PER), which is the percentage of packet that must be

transmitted because its data could not be recovered.The disadvantage of transmitting at a

high Eb/�t value is that it consumes more AT battery power; even worse, it creates a

higher-level of RF interference to other users in the environment. Therefore, the design

objective is to create a system that requires the lowest Eb/�t value for a target PER.

The required Eb/�t for a given AT is a function of its mobility, the multipath

environment, and target packet error rate (PER). The required Eb/�t values listed in Table

5-5, “Reverse Link Required Eb/�t Values” (p. 5-21) are estimates at each data rate

considering all the power the AT radiates. This includes the power from the non-traffic

channels such as DRC, pilot/RRI, and ACK channels. The Eb/�t values are based on link

layer simulations.

Reverse Link Required Eb/Nt Values

Table 5-5 Reverse Link Required Eb/Nt Values

Data Rate (kbps) Required Eb/Nt (dB)

Mobility Stationary

4.8 6.8 5.8

9.6 4.9 3.9

19.2 3.9 2.9

28.8 3.4 2.4

38.4 3.3 2.3

57.6 2.7 1.7

76.8 2.6 1.6

153.6 2.1 1.1

230.4 1.7 0.7

307.2 1.8 0.8

460.8 3.4 2.4

RF Coverage and Capacity Reverse Link Budget AnalysisRequired Eb/Nt, Item l

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

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

401-614-323Issue 16 October 2009

5-21

Page 332: 1xev-Do Rf Engineering

Vehicle Speed Effect on Eb/Nt Value

Higher Eb/�t values are required when the AT is operating from a moving vehicle

because shadow or slow fading, discussed in “Shadow Fading” (p. 5-8), will occur more

frequently when the AT is motion. In 1xEV-DO, the influence of shadow fading is

minimized in two ways: fast power control and bit interleaving. The relationship between

vehicle speed and Eb/�t value is shown in Figure 5-8, “Relationship Between Vehicle

Speed and Eb/�t Value” (p. 5-22).

Consequences of Power Control at Low Vehicle Speeds

At low vehicle speeds, the AT reaction to the base station power control is fast enough to

respond to most shadow fading conditions. In addition, the AT is more likely to remain in

a multipath environment for a longer period to help maintain a low bit error rate (BER).

As the vehicle speed increases moderately, a worst-case condition is approached at speeds

between a narrow range.

Consequences of Bit Interleaving at High Vehicle Speeds

At higher vehicle speeds, the fast fading durations are smaller, enabling better data

recovery from bit interleaving. Bit interleaving is operated in conjunction with the turbo

coder. The turbo coder uses convolution coding, which is very effective for recovering

Figure 5-8 Relationship Between Vehicle Speed and Eb/Nt Value

Speed

E /N Levelb o

RF Coverage and Capacity Reverse Link Budget AnalysisRequired Eb/Nt, Item l

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

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

5-22 401-614-323Issue 16 October 2009

Page 333: 1xev-Do Rf Engineering

from corrupted bits scattered over the received bit stream. However, during a fade, a

cluster of consecutive transmitted bits are corrupted, rendering turbo coding ineffective.

To prevent fading from rendering turbo coding ineffective, bit interleaving is performed

by the AT after turbo coding. As a result, the stream of data bits to be transmitted is

pseudo-randomly scattered out of sequence. If a fade is encountered, resulting in the

corruption of a burst of consecutive transmitted bits, when the bit stream is de-interleaved

at the receiver, rather than being clustered together, the corrupted bits will be scattered

throughout the de-interleaved bit stream, enabling turbo coding recovery of the

transmitted message.

The duration of the fast fade primarily depends on the vehicle speed. If the fade is too

long, a large number of corrupted bits are created so that even after de-interleaving,

consecutive corrupted bits remain in the bit stream to lower the turbo coding efficiency.

The duration of the fade will shorten as the vehicle speed increases, thus increasing the

turbo coder data recovery efficiency. Therefore, at higher vehicle speeds, the required

Eb/�t value will decrease.

Data Rate Effect on Eb/Nt Value

The required Eb/�t includes power from channels other than traffic channels such as

pilot, DRC, and ACK channels, and represents the total amount of power required to

transmit traffic information. The higher data rates have lower Eb/�t requirements because

the Pilot, DRC, and ACK channels occupy a lower percentage of overhead relative to the

traffic channel as the rate increases. However, at the 153.6 kbps rate, the Eb/�t

requirement is higher due to the weaker turbo coding rate used at this data rate. The code

rate identifies the ratio of the number of information bits to the total number of

information bits plus overhead correction bits transmitted. To achieve the higher data rate,

a ½ code rate is used for 153.6 kbps transmission versus the ¼ code rate used for 9.6,

19.3, 38.4, and 76.4 kbps data rates. This means that at the 153.6 kbps data rate, each

information bit is sent twice instead of four times as with the lower data rates. The lower

repetition rate at the 153.6 data rate offers fewer opportunities for turbo bit correction,

therefore requiring transmission at a higher Eb/�t value.

RF Coverage and Capacity Reverse Link Budget AnalysisRequired Eb/Nt, Item l

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

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

401-614-323Issue 16 October 2009

5-23

Page 334: 1xev-Do Rf Engineering

Soft Handoff Gain

Description

Soft handoff occurs in the soft handoff zone, which is the outer edge of two or more cells

as the AT moves from the domain of one base station to the domain of another. In AMPS

and TDMA, the signal received from the cell outer edge is the weakest, and their link

budgets reflect this weakness through the increase in the maximum path loss value, thus

reducing the cell coverage radius. The opposite is true in CDMA. When an AT enters the

soft handoff zone, a signal gain is experienced because the AT is communicating with the

two or more base stations that share the soft handoff zone. The overall result of an AT

operation at the cell outer edge is to reduce the maximum path loss value, allowing a

lower Eb/�t per link value for the same coverage area.

Therefore, an advantage due to soft handoff exists that results in effectively lowering the

fade margin required to obtain a specific probability of edge coverage, as compared to

other technologies. For a CDMA system that admits soft handoff, for any given reverse

frame, the better or alternatively stronger of two or more base stations reception will be

utilized at the frame selector, typically at the switching center.

Example

Assuming an 8 dB standard deviation and 50% partially correlated two-way handoff, the

soft handoff gain numerically works out to about 4 dB when edge coverage probability is

90 percent. Due to the soft handoff feature, the excess link margin requirement has

dropped by 4 dB. This is the advantage due to soft handoff that results in increased

coverage.

RF Coverage and Capacity Reverse Link Budget AnalysisSoft Handoff Gain

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

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

5-24 401-614-323Issue 16 October 2009

Page 335: 1xev-Do Rf Engineering

Path loss

Log-Normal Fade Margin, Item p

The influence of shadow fading is shown in Figure 5-9, “Propagation Loss” (p. 5-26).

The X axis is expressed as 10 times the log of the distance in miles; therefore, the 0 point

on the graph represents a 1 mile (1.6 km) distance from the antenna and the -3 point is

one-half mile (.8 km) from the antenna. The mean value line shows that as the distance

from the antenna increases, the path loss increases. At any given distance, there exists a

significant variation in the path loss about its mean value. A change in receiver position

by a meter can result in a change in path loss by as much as 20 dB. Such large changes in

path loss typically occur when an obstacle (e.g., a building or a hill) obstructs the RF

path. For example, in the data shown in Figure 5-9, “Propagation Loss” (p. 5-26), the path

loss at a distance of 2 miles (3.2 km); that is, at the horizontal axis value of 3 which is the

log of 2, varies from as much as 147 dB to as low as 130 dB. The distribution of the path

loss follows the log-normal distribution, with the standard deviation of typically 8 dB.

As networks are designed using the mean path loss at a certain distance, you must factor

in a margin for this variation in path loss to assure adequate signal strength. In the link

budget, this term is called fade margin.

RF Coverage and Capacity Reverse Link Budget AnalysisPath loss

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

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

401-614-323Issue 16 October 2009

5-25

Page 336: 1xev-Do Rf Engineering

Propagation Loss diagram

Fade Probability

The probability of 90 and 75 percent cell edge coverage vs. fade margin is given in Table

5-6, “Probability Of Edge Coverage vs. Fade Margin” (p. 5-26). These values are derived

from the standard tables of the normal distribution for the extra margin needed to obtain

the desired probability of edge coverage.

Table 5-6 Probability Of Edge Coverage vs. Fade Margin

Probability of

edge coverage

Probability of area

coverage

Margin in terms of

standard deviation

of fading (σ)

Fade Margin forσ =

8dB [dB]

90% 95% 1.28σ 10.3

75% 90% 0.67σ 5.4

Figure 5-9 Propagation Loss

RF Coverage and Capacity Reverse Link Budget AnalysisPath loss

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

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

5-26 401-614-323Issue 16 October 2009

Page 337: 1xev-Do Rf Engineering

The above margin is interpreted in network design in the following way. Let us assume

that 148.1 dB is the maximum median allowable path loss. If the median path loss of

148.1 dB is obtained after using a fading margin of 10.3 dB, then from a design point of

view, such a network would be expected to have a 90% probability of edge coverage,

assuming the standard deviation is 8 dB.

The above calculation of fading margin is independent of technology; it would apply to

CDMA, AMPS, TDMA, and GSM systems.

Building/Vehicle Penetration Loss, Item q

The building/vehicle penetration loss is the amount of attenuation introduced due to

obstacles in the RF line-of-sight path. The AT transmit signal will be attenuated by the

over-the-air attenuation, and also by the building/vehicle penetration loss and fading.

These terms must be added to the reverse link over the air loss to provide the total

attenuation the signal will experience.

Maximum Path Loss with Respect Isotropic Antennas, Item r

The over-the-air maximum allowable path loss for any particular reverse link data rate is

calculated by subtracting and adding the following link budget items:

r = c - d - m + e - f + o + n - p - q

Considering that the maximum allowable path loss for 3G-1X voice service is 150.5 dBi,

about the same value as the lowest data rates for 1xEV-DO, which indicates that a

1xEV-DO cell can be overlaid directly over a 3G-1X cell. Remember that the reverse link

maximum allowable path loss is the maximum “over the air” path loss.

RF Coverage and Capacity Reverse Link Budget AnalysisPath loss

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

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

401-614-323Issue 16 October 2009

5-27

Page 338: 1xev-Do Rf Engineering

Forward Link Budget Analysis

Overview

Purpose

This section covers the process of forward link budget analysis.

Contents

Forward link description 5-29

Forward Link factors 5-31

Link Budget Calculation 5-34

Forward Link Budge Spreadsheet 5-36

Transmit Power Calculation 5-42

Total Interference 5-44

RF Coverage and Capacity Forward Link Budget AnalysisOverview

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

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

5-28 401-614-323Issue 16 October 2009

Page 339: 1xev-Do Rf Engineering

Forward link description

Introduction

Classically, the objective of forward link budget analysis is to ensure that the forward link

has sufficient power to support the performance needed and the desired throughput within

the footprint established by the reverse link. In 1xEV-DO, the forward link budget

objective is to determine the percentage of the coverage area established by the reverse

link maximum allowable path loss that can be achieved at each forward link data rate. As

the data rate increases, the percentage of area covered decreases.

Percentage of Area Covered Vs. Data Rate

The decreasing percentage of area covered at each data rate can be thought of as

ever-smaller concentric rings of coverage, as shown in Figure 5-10, “Percentage of Area

Covered Vs. Data Rate” (p. 5-29). The outer-most (largest) ring represents over 95

percent of the cell footprint established by the reverse link, and is shaded to show the

maximum cell coverage achieved when operating at the lowest forward data rate. The

inner-most ring (closest to the base station) is shaded to represent the highest data rates

that can be achieved in the cell.

Figure 5-10 Percentage of Area Covered Vs. Data Rate

Data Bit Rates

38.4 kbps76.8 kbps

156.6 kbps

614.4 kbps921.6 kbps

1228.8 kbps1843.2 kbps2457.6 kbps

307.3 kbps

RF Coverage and Capacity Forward Link Budget AnalysisForward link description

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

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

401-614-323Issue 16 October 2009

5-29

Page 340: 1xev-Do Rf Engineering

RF Coverage and Capacity Forward Link Budget AnalysisForward link description

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

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

5-30 401-614-323Issue 16 October 2009

Page 341: 1xev-Do Rf Engineering

Forward Link factors

RF Conditions Evaluation by the AT

Unlike 3G-1X and IS-95, in 1xEV-DO the forward link is not code-shared to distinguish

each user within the sector. Instead, the forward link transmit signal is dedicated to one

user (at a time) on a time-shared basis. That is, the base station communicates on the

forward link traffic channel with each user during its dedicated 1.667-millisecond time

slot. To maximize the base station data throughput, the forward link traffic data is then

transmitted at full power to a single AT selected by the scheduler algorithm. The transmit

data rate is varied per user based on feedback from the users on the RF condition that the

AT is experiencing. Essentially, the RF condition experienced by the AT is determined by

how well the AT can recover the turbo-coded packet information. If because the AT

moves away from the base station, the RF conditions deteriorate such that the AT cannot

recover the turbo-coded packet information at the current data rate to maintain low BER,

for the next time slot, the AT might request transmission at lower data rate.

AT Minimum Performance Specification

The minimum performance specifications guide AT manufacturers on the required Eb/�t

values for each forward traffic channel data rate. The Eb/�t values given in Table 5-7,

“Required Traffic Channel Forward Link Eb/�o Value” (p. 5-31) are the values that are

currently used for planning purposes. The minimum performance specifications for the

two highest data rates (1843.2 and 2457.6 kbps) are derived from requirement and

objective values. The Eb/�t values given in this table for the two highest data rates are the

linear average of their requirement and objective values.

Table 5-7 Required Traffic Channel Forward Link Eb/No Value

Data Rate (kbps) Required Traffic Channel Eb/No (dB)

38.4 2.5

76.8 2.5

153.5 2.5

307.2 2.5

614.4 2.5

921.6 3.5

1228.8 5.0

1843.2 7.5 1

2457.6 10.5 1

RF Coverage and Capacity Forward Link Budget AnalysisForward Link factors

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

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

401-614-323Issue 16 October 2009

5-31

Page 342: 1xev-Do Rf Engineering

Notes:

1. Linear average of requirement and objective specification values

Attention: Required S�R can be calculated as (in dB domain)

[Required S�R (dB)] = [Required Eb/�o (dB)] - [Processing Gain (dB)]

Forward Link Signaling Channel

The Eb/�t values given in Table 5-7, “Required Traffic Channel Forward Link Eb/�o

Value” (p. 5-31) are for forward link traffic channels, as opposed to forward link signaling

channels, which are transmitted at the 76.8 kbps data rate. Rather that waiting for

optimum RF conditions to transmit on the traffic channels, data transmission on the

signaling channels occur at fixed schedule intervals. Because the signal channels may not

be transmitted during optimum RF conditions, the required Eb/�t level for signaling

channels may be higher than the level required for traffic channels.

Different Repetition Factors

The Eb/�t values listed in Table 5-7, “Required Traffic Channel Forward Link Eb/�o

Value” (p. 5-31) are kept to minimum levels by relying on the data recovery techniques

defined in the Physical Layer to correct bit errors resulting from the low required Eb/�t

level. In other words, reliable data transmission is not only dependent on meeting the

required Eb/�t value, but is also dependent on bit recovery techniques such as turbo

coding redundancy and the transmission repetition factor that may vary at different data

rates. Even though the required Eb/�t values for data rates 38.4 through 614.4 kbps are

the same (2.5 dB), bear in mind that the Physical Layer specifies different repetition

factors for each data rate in the form of the number time slot periods required to transfer

each data packet. For example, at the 38.4-kbps data rate, 1024-bit packets are

turbo-coded at a 1/5 code rate, producing 5120 bits (1024 X 5). The 5120 bits are

QPSK-modulated, resulting in 2560 2-bit symbols per packet. At the 38.4-kbps data rate,

the information in each packet is transmitted to the AT over 16 time slot periods. Each slot

contains 1600 chips for data, so 16 slots contain 25600 chips for data. At this data rate,

1024 of those chips are used for preamble, leaving 24576 chips for data. Therefore, the

repetition factor is 9.6 (24576/2560), which mean that the 2560-bit data parcel can be

transmitted 9.6 times within the allotted 16 slots.

When transmitting at the 76.8-kbps data rate, a 1024-bit-packet, which is also

turbo-coded at a 1/5 code rate, is also QPSK-modulated, resulting in 2560 symbols to be

transmitted. However, when transmitting at 76.8 kbps, the preamble size is reduced to 512

chips, and the packet is transmitted to the AT over an 8-time slot period. Therefore, at

1600 chips per time slot, 12800 chips less 512 chips are used for data, resulting in a 4.8

[(12800-512)/2560] repetition factor. Therefore, when reducing the transmission data rate

from 76.8 kbps to 38.4 kbps, the repetition factor is doubled, decreasing the AT bit error

RF Coverage and Capacity Forward Link Budget AnalysisForward Link factors

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

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

5-32 401-614-323Issue 16 October 2009

Page 343: 1xev-Do Rf Engineering

rate (BER).

RF Coverage and Capacity Forward Link Budget AnalysisForward Link factors

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

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

401-614-323Issue 16 October 2009

5-33

Page 344: 1xev-Do Rf Engineering

Link Budget Calculation

Percentage of the coverage area

The calculation for the 1xEV-DO forward link budget begins by determining the

percentage of the coverage area, derived from the reverse link, that can be achieved at

each forward link data rate. At any particular forward traffic channel data rate, the Eb/�o

value at the AT receiver antenna port must be equal to or greater than the required traffic

Eb/�o value specified for that data rate in Table 5-7, “Required Traffic Channel Forward

Link Eb/�o Value” (p. 5-31). The value specified in this table for any data rate is

represented as d in the following expression:

Energy per bit

The energy per bit can be expressed in term of the AT receive power from its host or

serving sector (Phost) divided by the bit rate. The total noise and interference is the

product of the receiver noise figure and the thermal noise density, plus the power within

the bandwidth of interest from the neighboring sectors. The expression then becomes:

where:

R = Data rate

P host = Power from serving base station

F = Base station receiver noise figure

N o = Thermo noise density

P other = Power from neighboring sectors

W = Bandwidth which is reduced to account for traffic slots (~75% of total slots).

Deriving forward link budget

If the numerator and denominator are multiplied by W and processing gain g, which is the

bandwidth, W, divided by the data rate R, is substituted, the following is obtained:

Figure 5-11 Equation 5E

N

b

t

------ d≥

Figure 5-12 Equation 6Phost R

F N W+

-------------------------------------------- d≥/

.o

Pother

/

RF Coverage and Capacity Forward Link Budget AnalysisLink Budget Calculation

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

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

5-34 401-614-323Issue 16 October 2009

Page 345: 1xev-Do Rf Engineering

The interference from neighboring sector (Pother ) can be expressed in terms of the

serving cell power (Phost ) by using the forward link interference ratio (βf ) as follows:

Then, Figure 5-13, “Equation 7” (p. 5-35) is rewritten to eliminate Pother by using the

forward link interference ratio. The following expression, which is the essence of forward

link budget analysis, is obtained:

Figure 5-13 Equation 7

W

W-----

Phost R

F N W+×-----------------------------------------------×

g P×

W F× N P+

-------------------------------------------------= ≤

/

Pothero/

host

other×

o

d

Figure 5-14 Equation 8

hostfotherPP =P .

Figure 5-15 Equation 9

dPWFN

Pg

hostfo+

.≥host

ß .

RF Coverage and Capacity Forward Link Budget AnalysisLink Budget Calculation

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

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

401-614-323Issue 16 October 2009

5-35

Page 346: 1xev-Do Rf Engineering

Forward Link Budge Spreadsheet

Overview

A sample of the forward link budgets spreadsheet is given in Table 5-8, “Forward Link

Budget Spreadsheet for PCS Band” (p. 5-36), for Rev 0 and Tables 5-9 through 5-11, for

Rev A. The derivation (and interrelationship) of the item values is each column is given in

the Comment column. The spreadsheet is divided into five categories for the purpose of

the following discussion:

• Transmit Power Calculation

• AT Receive Power

• Total Interference

• AT Receiver Sensitivity

• Coverage.

Description

The values given in this spreadsheet are calculated to balance the forward link to a

reverse link supporting a data rate of 9.6 kbps. This is done to provide the same coverage

footprint as in IS-95 and 3G-1X, which is very much desired when collocated 1xEV-DO

with IS-95 and 3G-1X. Therefore, a reverse link path loss of 150.6 dBi (Item r, Figure

5-4, “Path Loss Slope” (p. 5-16)) is used for Item 5. The objectives of this section are to

introduce and describe the major factors that must be considered when calculating the

link budgets governing base station coverage and signal quality for the forward link paths.

Although the forward link analysis spreadsheet for 1xEV-DO differs from the analysis

spreadsheet for 3G-1X and IS-95, the underlying principles and calculation parameters

remain the same. One fundamental difference is that the base station transmit power does

not have to be shared among all the users in the sector.

Forward link budget analysis is performed by accounting for the base station transmit

signal gains and losses or attenuation in much the same way that the gains and losses or

attenuation of the AT transmit signal are accounted for during reverse link budget

analysis.

Forward Link Budget Spreadsheet for PCS Band

Table 5-8 Forward Link Budget Spreadsheet for PCS Band

Item Description Units Traffic Channel Rate (kbps) Comments

38.4 76.8 153.6 307.2 614.4 921.6 1228.8 1843.2 2457.6

Transmit Power calculations

1 Total available power at

J4

dBm 42.0 42.0 42.0 42.0 42.0 42.0 42.0 42.0 42.0 16 Watt amplifier

RF Coverage and Capacity Forward Link Budget AnalysisForward Link Budge Spreadsheet

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

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

5-36 401-614-323Issue 16 October 2009

Page 347: 1xev-Do Rf Engineering

Table 5-8 Forward Link Budget Spreadsheet for PCS Band (continued)

Item Description Units Traffic Channel Rate (kbps) Comments

38.4 76.8 153.6 307.2 614.4 921.6 1228.8 1843.2 2457.6

2 Cell site Cable Loss dB 3.0 3.0 3.0 3.0 3.0 3.0 3.0 3.0 3.0 Typical

3 Cell site Transmit

Antenna Gain

dBi 18.0 18.0 18.0 18.0 18.0 18.0 18.0 18.0 18.0 Typical 3-sector

4 EIRP dBm 57.0 57.0 57.0 57.0 57.0 57.0 57.0 57.0 57.0 = Items 1 - 2 + 3

AT Receive Power

5 Path loss from reverse

link

dBi 150.6 150.6 150.6 150.6 150.6 150.6 150.6 150.6 150.6 Include

building/vehicle

penetration

6 ATAntenna Gain dB 2 2 2 2 2 2 2 2 2 Typical

7 Path loss slope dB/

Dec

38.5 38.5 38.5 38.5 38.5 38.5 38.5 38.5 38.5 Typical vale

8 Delta path loss for

coverage area

dB 0.0 0.0 -0.4 -2.1 -5.3 -8.8 -12.8 -19.6 -28.8 = Item7x log

Item 21

9 AT receive user power

at full rate from base

station

dBm -91.6 -91.6 -91.2 -89.5 -86.3 -82.8 -78.8 -72.0 -62.8 = Items 4 -5 +6

+7

Total Interference

10 Ratio of mean other

sector interference to

host sector power

dB 9.5 8.3 5.2 2.2 -0.8 -3.5 -6.3 -10.5 -14.8 From geometry

distribution

based on area

coverage

11 Other cell/sector

interference

dBm -82.1 -83.3 -86.0 -87.3 -87.1 -86.3 -85.1 -82.5 -77.6 = Items 9 + 10

12 AT �oise Figure dB 9.0 9.0 9.0 9.0 9.0 9.0 9.0 9.0 9.0 Typical (F)

13 Thermal �oise Density dBm/

Hz

-174.0 -174.0 -174.0 -174.0 -174.0 -174.0 -174.0 -174.0 -174.0 (�o=KT)

14 Total Thermal �oise

Power/Hz

dBm/

Hz

-165.0 -165.0 -165.0 -165.0 -165.0 -165.0 -165.0 -165.0 -165.0 = Items 12 + 13

15 Effective Traffic

Channel Spreading

Bandwidth

dB

Hz

60.9 60.9 60.9 60.9 60.9 60.9 60.9 60.9 60.9 (W)

16 Total thermal noise

power

dBm -104.1 -104.1 -104.1 -104.1 -104.1 -104.1 -104.1 -104.1 -104.1 = Items 14 + 15

(�oWF)

17 Total interference to

traffic channel

dBm -82.1 -83.2 -85.9 -87.2 -87.0 -86.2 -85.0 -82.5 77.6

AT Receiver Sensitivity

18 Processing Gain dB 13.8 10.8 7.8 4.8 1.8 0.1 -1.3 -3.0 -4.3

19 Calculated Traffic

Channel Eb/�t

dB 4.3 2.5 2.5 2.5 2.5 3.5 5.0 7.5 10.5 = Items 18 + 9 -

17

RF Coverage and Capacity Forward Link Budget AnalysisForward Link Budge Spreadsheet

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

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

401-614-323Issue 16 October 2009

5-37

Page 348: 1xev-Do Rf Engineering

Table 5-8 Forward Link Budget Spreadsheet for PCS Band (continued)

Item Description Units Traffic Channel Rate (kbps) Comments

38.4 76.8 153.6 307.2 614.4 921.6 1228.8 1843.2 2457.6

20 Required traffic Eb/�o dB 2.5 2.5 2.5 2.5 2.5 3.5 5.0 7.5 10.5

21 Probability of coverage % >95 >95 95 78 53 35 22 10 3

Rev A Forward link budget (4.8 kbps through 76.8 kbps)

Table 5-9 Rev A Forward link budget (4.8 kbps through 76.8 kbps)

Line Units ItemData rate (kbps)

Comments4.8 9.6 19.2 38.4 76.8

1 dBm Total available power at J4 point 42.0 42.0 42.0 42.0 42.0 16-Watt amplifier

2 dB Cell site Cable Loss 3.0 3.0 3.0 3.0 3.0 consistent with RL

3 dBi Cell site Transmit Antenna Gain 18.0 18.0 18.0 18.0 18.0 consistent with RL

4 dBm EIRP 57.0 57.0 57.0 57.0 57.0 =1-2+3

5a dBi Reverse link path loss 151.8 151.8 151.8 151.8 151.8 from reverse link

5b dB Building/Vehicle Penetration

Loss

0.0 0.0 0.0 0.0 0.0 consistent with RL

5c dB AT antenna gain 2.0 2.0 2.0 2.0 2.0 consistent with RL

5d dB Body/head loss 0.0 0.0 0.0 0.0 0.0 consistent with RL

5 dBi Total path loss to AT 149.8 149.8 149.8 149.8 149.8 =5a+5b-5c+5d

6 db/Dec Path loss slope 35.22 35.22 35.22 35.22 35.22 Assumed value

7 dB Delta Path loss for Area

Coverage

-0.4 -0.4 -0.4 -0.0 -0.0 =6*log(sqrt(20))

8 dBm Mobile Rx User Signal power at

full rate (from serving cell)

-92.4 -92.4 -92.4 -92.8 -92.8 =4-5+7

9 dB Ratio of other sector interference

to host sector power

2.1 2.1 2.1 2.1 2.1 from Geometry distribution, based on

area coverage (20)

10 dBm Other Cells/Sector Interference -90.3 -90.3 -90.3 -90.7 -90.7 =8+9

11 dB Mobile �oise Figure (F) 9.0 9.0 9.0 9.0 9.0 Typical

12 dBm/Hz Thermal �oise Density

(�o=KT)

-174.0 -174.0 -174.0 -174.0 -174.0

13 dBm/Hz Total thermal �oise power per

Hz (�oF)

-165.0 -165.0 -165.0 -165.0 -165.0 =11+12

14 dBHz Spreading bandwidth (W) 60.9 60.9 60.9 60.9 60.9 10log(1.23e6)

15 dBm Total thermal noise power

(�oWF)

-104.1 -104.1 -104.1 -104.1 -104.1 =13+14

RF Coverage and Capacity Forward Link Budget AnalysisForward Link Budge Spreadsheet

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

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

5-38 401-614-323Issue 16 October 2009

Page 349: 1xev-Do Rf Engineering

Table 5-9 Rev A Forward link budget (4.8 kbps through 76.8 kbps) (continued)

Line Units ItemData rate (kbps)

Comments4.8 9.6 19.2 38.4 76.8

16 dBm Total interference to the traffic

channel

-90.1 -90.1 -90.1 -90.5 -90.5 =10log(db2lin(10)+db2lin(15))

17 dB Processing Gain 22.8 19.8 16.8 13.8 10.8

18 dB Calculated Traffic Channel

Eb/(�o+Io)

20.6 17.5 14.5 11.5 8.5 =17+8-16

19 dB Required Traffic Eb/�t 3.8 3.0 2.8 2.5 2.4 Reference from standards for AWG�

case

20 % Probability of Coverage 95% 95% 95% 95% 95%

Rev A Forward link budget (153.6 kbps through 1228.8 kbps)

Table 5-10 Rev A Forward link budget (153.6 kbps through 1228.8 kbps)

Line # Units ItemData rate (kbps)

Comments153.6 307.2 614.4 921.6 1228.8

1 dBm Total available power at J4

point

42.0 42.0 42.0 42.0 42.0 16-Watt amplifier

2 dB Cell site Cable Loss 3.0 3.0 3.0 3.0 3.0 consistent with RL

3 dBi Cell site Transmit Antenna Gain 18.0 18.0 18.0 18.0 18.0 consistent with RL

4 dBm EIRP 57.0 57.0 57.0 57.0 57.0 =1-2+3

5a dBi Reverse link path loss 151.8 151.8 151.8 151.8 151.8 from reverse link

5b dB Building/Vehicle Penetration

Loss

0.0 0.0 0.0 0.0 0.0 consistent with RL

5c dB AT antenna gain 2.0 2.0 2.0 2.0 2.0 consistent with RL

5d dB Body/head loss 0.0 0.0 0.0 0.0 0.0 consistent with RL

5 dBi Total path loss to AT 149.8 149.8 149.8 149.8 149.8 =5a+5b-5c+5d

6 db/Dec Path loss slope 35.22 35.22 35.22 35.22 35.22 Assumed value

7 dB Delta Path loss for Area

Coverage

-0.2 -0.4 -2.0 -4.4 -7.4 =6*log(sqrt(20))

8 dBm Mobile Rx User Signal power at

full rate (from serving cell)

-92.6 -92.4 -90.8 -88.3 -85.4 =4-5+7

9 dB Ratio of other sector

interference to host sector

power

2.1 2.1 -0.9 -3.4 -6.0 from Geometry distribution, based

on area coverage (20)

10 dBm Other Cells/Sector Interference -90.5 -90.3 -91.7 -91.7 -91.4 =8+9

11 dB Mobile �oise Figure (F) 9.0 9.0 9.0 9.0 9.0 Typical

RF Coverage and Capacity Forward Link Budget AnalysisForward Link Budge Spreadsheet

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

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

401-614-323Issue 16 October 2009

5-39

Page 350: 1xev-Do Rf Engineering

Table 5-10 Rev A Forward link budget (153.6 kbps through 1228.8 kbps)

(continued)

Line # Units ItemData rate (kbps)

Comments153.6 307.2 614.4 921.6 1228.8

12 dBm/Hz Thermal �oise Density

(�o=KT)

-174.0 -174.0 -174.0 -174.0 -174.0

13 dBm/Hz Total thermal �oise power per

Hz (�oF)

-165.0 -165.0 -165.0 -165.0 -165.0 =11+12

14 dBHz Spreading bandwidth (W) 60.9 60.9 60.9 60.9 60.9 10log(1.23e6)

15 dBm Total thermal noise power

(�oWF)

-104.1 -104.1 -104.1 -104.1 -104.1 =13+14

16 dBm Total interference to the traffic

channel

-90.3 -90.1 -91.4 -91.5 -91.1 =10log(db2lin(10)+db2lin(15))

17 dB Processing Gain 7.8 4.8 1.8 0.1 -1.3

18 dB Calculated Traffic Channel

Eb/(�o+Io)

5.5 2.5 2.5 3.2 4.5 =17+8-16

19 dB Required Traffic Eb/�t 2.3 2.5 2.4 3.2 4.4 for Reference from standards for

AWG� case

20 % Probability of Coverage 95% 95% 77% 56% 38%

Rev A Forward link budget (1536.0 kbps through 3072.0 kbps)

Table 5-11 Rev A Forward link budget (1536.0 kbps through 3072.0 kbps)

Line Units ItemData rate (kbps)

Comments1536.0 1843.2 2457.6 3072.0

1 dBm Total available power at J4 point 42.0 42.0 42.0 42.0 16-Watt amplifier

2 dB Cell site Cable Loss 3.0 3.0 3.0 3.0 consistent with RL

3 dBi Cell site Transmit Antenna Gain 18.0 18.0 18.0 18.0 consistent with RL

4 dBm EIRP 57.0 57.0 57.0 57.0 =1-2+3

5a dBi Reverse link path loss 151.8 151.8 151.8 151.8 from reverse link

5b dB Building/Vehicle Penetration Loss 0.0 0.0 0.0 0.0 consistent with RL

5c dB AT antenna gain 2.0 2.0 2.0 2.0 consistent with RL

5d dB Body/head loss 0.0 0.0 0.0 0.0 consistent with RL

5 dBi Total path loss to AT 149.8 149.8 149.8 149.8 =5a+5b-5c+5d

6 db/Dec Path loss slope 35.22 35.22 35.22 35.22 Assumed value

7 dB Delta Path loss for Area Coverage -9.5 -13.6 -17.6 -24.6 =6*log(sqrt(20))

8 dBm Mobile Rx User Signal power at full

rate (from serving cell)

-83.3 -79.2 -75.2 -68.2 =4-5+7

RF Coverage and Capacity Forward Link Budget AnalysisForward Link Budge Spreadsheet

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

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

5-40 401-614-323Issue 16 October 2009

Page 351: 1xev-Do Rf Engineering

Table 5-11 Rev A Forward link budget (1536.0 kbps through 3072.0 kbps)

(continued)

Line Units ItemData rate (kbps)

Comments1536.0 1843.2 2457.6 3072.0

9 dB Ratio of other sector interference to

host sector power

-7.6 -10.6 -13.3 -17.1 from Geometry distribution, based

on area coverage (20)

10 dBm Other Cells/Sector Interference -90.9 -89.8 -88.5 -85.3 =8+9

11 dB Mobile �oise Figure (F) 9.0 9.0 9.0 9.0 Typical

12 dBm/Hz Thermal �oise Density (�o=KT) -174.0 -174.0 -174.0 -174.0

13 dBm/Hz Total thermal �oise power per Hz

(�oF)

-165.0 -165.0 -165.0 -165.0 =11+12

14 dBHz Spreading bandwidth (W) 60.9 60.9 60.9 60.9 10log(1.23e6)

15 dBm Total thermal noise power (�oWF) -104.1 -104.1 -104.1 -104.1 =13+14

16 dBm Total interference to the traffic channel -90.7 -89.7 -88.3 -85.2 =10log(db2lin(10)+db2lin(15))

17 dB Processing Gain -2.1 -3.0 -4.3 -5.2

18 dB Calculated Traffic Channel Eb/(�o+Io) 5.3 7.4 8.9 11.8 =17+8-16

19 dB Required Traffic Eb/�t 5.1 7.3 8.6 11.8 for Reference from standards for

AWG� case

20 % Probability of Coverage 29% 17% 10% 4%

RF Coverage and Capacity Forward Link Budget AnalysisForward Link Budge Spreadsheet

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

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

401-614-323Issue 16 October 2009

5-41

Page 352: 1xev-Do Rf Engineering

Transmit Power Calculation

Description

To maximize the forward link data rate, the base station always transmits at full power to

users within the sector on a time-share basis. The base station effective isotropic radiated

power (EIRP) per traffic channel computed in Item 4 of the forward link analysis

spreadsheet, and is equal to the base station total power available at J4, Item 1, less cell

cable loss, Item 2, plus cell transmit antenna gain, Item 3.

AT Receiver Power

The AT receive power is equal to the reverse link path loss less the base station effective

isotropic radiated power (EIRP) per traffic channel, computed in Item 4, plus a delta path

loss. The delta path loss value is a correction factor to adjust the reverse link path loss as a

function of the probability of coverage (Item 20, for Rev 0, and 18, for Rev A). The

reverse link path loss represents the total path loss to the cell outer boundary which, when

considering the probability of coverage in the forward link, particularly at higher data

rates (refer to Figure 5-10, “Percentage of Area Covered Vs. Data Rate” (p. 5-29)), may

be considerably larger than the path loss experienced in the forward link. Therefore, the

reverse link path loss must be adjusted by the delta path loss (Item 8, for Rev 0, and 7, for

Rev A) correction factor to account for the reduction in area coverage as the data rate

increases.

Determining the Delta Path loss Value

Before the delta path loss (Item 8, for Rev 0, and 7, for Rev A) correction factor can be

calculated, the probability of coverage (Item 21, for Rev 0 and Rev A) in the forward link

must be determined for each forward link data rate.Rrealize that the probability of

coverage in this forward link budget has a different meaning than the probability of

area/edge coverage in the reverse link. The reverse link budget results in a maximum

allowable path loss for a given probability of area/edge coverage and is a function of the

fade margin. In the forward link, the probability of coverage, which is the bottom line of

the forward link budget, is a function of both the interference ratio and the path loss that

varies with data rate. As illustrated in Figure 5-10, “Percentage of Area Covered Vs. Data

Rate” (p. 5-29), the forward link probability of coverage represents the percentage of area

that is expected to achieve the desired data rate.

�ote:Key to developing the link budget is under-standing that the Probability of Area

Coverage (Item 21, for Rev 0 and Rev A) can be varied until the Calculated Traffic

Eb/(�o + Io) value (Item 19) is equal to or greater than the Required Traffic Eb/�t

value (Item 20).

RF Coverage and Capacity Forward Link Budget AnalysisTransmit Power Calculation

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

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

5-42 401-614-323Issue 16 October 2009

Page 353: 1xev-Do Rf Engineering

The primary factor that determines the base station maximum range at a given data rate is

the AT received Eb/�t level at that range, which must be equal to or greater than the

required Eb/�t level listed for the data rate in Table 5-7, “Required Traffic Channel

Forward Link Eb/�o Value” (p. 5-31). Key in determining the Probability of Coverage

(Item 21, for Rev 0 and Rev A) is to vary its value on the link budget spreadsheet until the

Calculated Traffic Channel Eb/(�o + Io) (Item 19) value is equal to or greater than the

Required Traffic (Item 20, for Rev 0, and 18, for Rev A).

Computing Delta Path loss for Coverage Area

After the probability of coverage is determined the Delta Path loss for Coverage Area

(Item 8, for Rev 0, and 7, for Rev A) can be computed by multiplying the log of square

root of Item 21, expressed as a decimal, by the Path loss Slope (Item 7, for Rev 0, and 6,

for Rev A) value.

The path loss slope is generally expressed in dB per decade (dB/Dec), which means that

the RF signal strength will decrease at a fixed number of dB's as the distance between

transmitter and receiver increases by a factor of 10. The expression, dB per decade,

represents a fixed slope indicating the exponential rate at which signal strength decreases

as the distance between transmitter and receiver increases. The delta path loss is

concerned with radius of the reduced coverage area, which is proportional to square root

of the area. Therefore, the delta path loss is calculated by multiplying the Path loss Slope

(Item 7, for Rev 0, and 6, for Rev A) value by log of the square root of Probability of

Coverage (Item 21, for Rev 0, and 20, for Rev A).

RF Coverage and Capacity Forward Link Budget AnalysisTransmit Power Calculation

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

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

401-614-323Issue 16 October 2009

5-43

Page 354: 1xev-Do Rf Engineering

Total Interference

Introduction

The calculation for Total Interference on the Traffic Channel (Item 17, for Rev 0, and 16,

for Rev A) is divided into two parts:

• Calculation of the Interference from Other Cells/Sectors, Item 11, for Rev 0, and 10,

for Rev A

• Calculation of the Total Thermal �oise Power, Item 14, for Rev 0, and 13, for Rev A.

The Interference from Other Cells/Sectors (Item 11, for Rev 0, and 10, for Rev A) is

greater than Total Thermal �oise Power (Item 14, for Rev 0, and 13, for Rev A), which is

typically small compared to cell interference levels. Therefore, the Total Interference on

the Traffic Channel (Item 17, for Rev 0, and 16, for Rev A) is fundamentally equal to

Item 11, for Rev 0, and 10, for Rev A.

Interference from Other Cells/Sectors

As stated in “Percentage of the coverage area” (p. 5-34), the interference from other

cells/sectors may be expressed in terms of forward link interference ratio (β f), which is

equal to the power from the interfering sectors divided by the power in the serving sector

or P other /P host . Therefore, the value for the other cell interference is calculated by

multiplying the serving cell signal power by a forward link interference ratio (β f X P host). The interference ratio can be determined by off-line simulations that provide a

cumulative distribution function (CDF) curve. The CDF curve identifies distribution

Geometry over the area of the sector for a n-section cell, and will vary based on a number

of parameters governing a particular deployment strategy. The simulations may be

performed to examine the interference Geometry (G), which is simply the power from the

serving sector divided by the sum of the thermal noise power and power from the

interfering sectors:

Simulation results

The simulations studied the interference-limited case where FN o W << P other ;

therefore, the geometry can be simplified to:

Figure 5-16 Equation 10

othero

host

PWFN

PG

+=

RF Coverage and Capacity Forward Link Budget AnalysisTotal Interference

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

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

5-44 401-614-323Issue 16 October 2009

Page 355: 1xev-Do Rf Engineering

Geometry simulations include random fading; therefore, no separate fade margin needs to

be included in the forward link budget. Also, the simulations calculated the Geometry

from the best serving cell. The situation models the 1xEV-DO virtual soft handoff, so no

separate soft handoff gain term is required in the forward link budget.

The CDF curve will plot percentage of CDF on the vertical against G, in dB, on the

horizontal. Because the Geometry (G) is the inverse of the interference ratio (β f), the

points that correspond to the probability of coverage percentage are the reciprocal of the

CDF percentile. For example, the points that correspond to a 90% probability of coverage

are above the 10% point on the CDF axis. For a particular Geometry, the value

corresponding to the 10% point on the CDF axis is -4 dB, which corresponds to a +4 dB

interference ratio (β f).

Interference-limited situation

For an interference-limited situation, where FN o W << βf P host , the basic forward

link equation shown in Figure 5-16, “Equation 10” (p. 5-44) is simplified to:

which in dB terms is written as:

Edge Coverage For Interference Limited Case

This means that the processing gain (g) less the interference ratio (β f) must be equal to or

greater than the required Eb/�t value for a given probability of coverage. The

determination of the interference ratio (β f) value can be used to evaluate edge coverage

for the different data rates. For example, if the Geometry-indicated interference ratio (β f)

values are 4 dB and 5.5 dB for 90 and 95 percent coverage, respectively, the g - βfvalues for 90 and 95 percent coverage can be evaluated at each data rate as shown in

Table 5-12, “Edge Coverage For Interference Limited Case” (p. 5-46).

Figure 5-17 Equation 111

other

host

P

PG

f

ȧ

Figure 5-18 Equation 12

dg

ß≥

Figure 5-19 Equation 13

dg − ≥fß

RF Coverage and Capacity Forward Link Budget AnalysisTotal Interference

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

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

401-614-323Issue 16 October 2009

5-45

Page 356: 1xev-Do Rf Engineering

Table 5-12 Edge Coverage For Interference Limited Case

Data

Rate(kbps)

Required

Eb/Nt (dB)

Processing

Gain (dB)

g - βf Covered at edge for

interference limited case

90%

area

case

95% area

case

90% area

coverage

95% area

coverage

38.4 2.5 13.8 9.8 8.3 Yes Yes

76.8 2.5 10.8 6.8 5.3 Yes Yes

153.6 2.5 7.8 3.8 2.3 Yes �o

307.2 2.5 4.8 0.8 -0.7 �o �o

614.4 2.5 1.8 -2.2 -3.7 �o �o

921.6 3.5 0.1 -3.9 -5.4 �o �o

1228.8 5.0 -1.25 -5.25 -6.75 �o �o

1843.2 7.5 -3.0 -7.0 -8.5 �o �o

2457.6 10.5 -4.26 -8.26 -9.76 �o �o

From Figure 5-16, “Equation 10” (p. 5-44) we see that the required received Eb/�t at the

AT (d) is a function of the Process Gain (Item 19, for Rev 0, and 17, for Rev A) less the

Ratio of Mean Other Sector Interference to Host Sector Power (Item 10, for Rev 0, and 9,

for Rev A). This will account for the Other Cell/Sector Interference (Item 10, for Rev 0,

and 10, for Rev A) value that will be equal to the sum of the AT receiver power (Item 9,

for Rev 0, and 8, for Rev A) and the Ratio of Mean Other Sector Interference to Host

Sector Power (Item 10, for Rev 0, and 9, for Rev A).

Total Thermal Noise Power

The thermal noise power in the base station receiver is determined in the same manner as

the AT thermal noise power in the reverse link budget. First, the Total Thermal �oise

Power Per Hz (Item 14, for Rev 0, and 13, for Rev A) is calculated by summing the

internal noise density of a perfect amplifier at room temperature (290° Kelvin), which is

typically is -174 dBm/Hz, with the AT noise figure, which is 9.0 dB. Item 16, for Rev 0,

and Item 15, for Rev A converts Item 14, for Rev 0, and 13, for Rev A, which is power

per Hz (dBm/Hz) to a power value by adding the value of Item 14 (for Rev 0, and 13, for

Rev A) to 60.9 dBHz, which is the Effective Traffic Channel Spreading Bandwidth (Item

15, for Rev 0 and Rev A) .

RF Coverage and Capacity Forward Link Budget AnalysisTotal Interference

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

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

5-46 401-614-323Issue 16 October 2009

Page 357: 1xev-Do Rf Engineering

Total Interference on the Traffic Channel

The Total Interference on the Traffic Channel, Item 17 for Rev 0 and 16 for Rev A, which

is the sum of Items 11 for Rev 0 and 10 for Rev A and 16 for Rev 0 and 16 for Rev A, is

computed by summing the inverse log of both values. Because the noise component of

Item 16 for Rev 0 and 15 for Rev A is usually considerably smaller than the noise

component of Item 11 for Rev 0 and 10 for Rev A, the value of Item 17 for Rev 0 and 16

for Rev A is usually essentially equal to the value of Item 11 for Rev 0 and 10 for Rev A.

Forward Link Receiver Sensitivity

The last computation shown on the forward link spreadsheet given in Table 5-8, “Forward

Link Budget Spreadsheet for PCS Band” (p. 5-36) determines the Calculated Traffic

Channel Eb/�t value listed in Item 19 for Rev 0 and 18 for Rev A. This value must be

equal to or greater than the Required Eb/�t value given in Table 5-7, “Required Traffic

Channel Forward Link Eb/�o Value” (p. 5-31), which is listed for reference as Item 20

for each data rate. The value of Item 19 for Rev 0 and 18 for Rev A is computed by

multiplying the AT receive signal power from the serving sector (Item 9, for Rev 0 and 8

for Rev A) by the Processing Gain (Item 18, for Rev 0 and 17 for Rev A) and dividing the

product by the Total Interference on the Traffic Channel (Item 17 for Rev 0 and 16 for

Rev A). Because these values are in dB and dBm, this computation is performed by

subtracting Item 17 for Rev 0 and 16 for Rev A from the sum of Items 9 for Rev 0 and 8

for Rev A and 18 for Rev 0 and 17 for Rev A.

RF Coverage and Capacity Forward Link Budget AnalysisTotal Interference

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

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

401-614-323Issue 16 October 2009

5-47

Page 358: 1xev-Do Rf Engineering

Capacity Overview

Overview

Purpose

In addition to knowing how large a geographical area a base station can cover, a network

planner must know how much traffic can be supported. This section discusses the

1xEV-DO system capacity. Because of the fundamental differences in how the reverse

and forward links operate, capacity analysis for the two links is completely different. The

reverse link is analyzed in a method similar to voice systems and results in a maximum

number of simultaneous users. The forward link is analyzed in a manner more similar to

3G-1X data services, and results in per-sector throughput.

Keep in mind that the capacity values presented here represent average values that are

intended to be useful in system planning. Actual performance in 1xEV-DO systems will

vary from sector to sector as well as from network to network. Capacity in CDMA

systems is a soft value that can be traded off against coverage and Quality of Service.

Contents

Rev A and Rev 0 Sector capacity 5-49

Capacity/Coverage Trade-off 5-50

Pole Capacity 5-52

RF Coverage and Capacity Capacity OverviewOverview

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

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

5-48 401-614-323Issue 16 October 2009

Page 359: 1xev-Do Rf Engineering

Rev A and Rev 0 Sector capacity

Introduction

Simulation comparing Rev A sector capacity with Rev 0 Sector capacity is shown in

Table 5-13. The values in this table are conservative and higher values can be expected.

The value for video telephony capacity is based on a fixed 64 kbps source.

Table 5-13 Rev 0/Rev A per-sector capacity

CriteriaNo. of

antennas

1xEV-DO Rev 0 1xEV-DO Rev A

Users Throughput Users Throughput*

Forward Link One

antenna

16 650 kbps 16 720 kbps

Dual

antenna

16 1.1 Mbps 16 1.3 Mbps

Reverse Line Dual

antennas

10 230 kbps 16 450 kbps

VoIP Capacity Dual

antennas

�/A �/A 45 35 Erlangs

Video Telephony

Capacity

Dual

antennas

4 8

Notes:

1. *Assuming forward link equalizer

RF Coverage and Capacity Capacity OverviewRev A and Rev 0 Sector capacity

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

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

401-614-323Issue 16 October 2009

5-49

Page 360: 1xev-Do Rf Engineering

Capacity/Coverage Trade-off

Introduction

To maintain quality service throughout the coverage area, a capacity-coverage trade-off

must be considered when designing a terrestrial system. Because every transmitting AT

creates interference for every other AT, for a given level of quality, as the capacity

increases, the coverage area decreases.

Minimum acceptable Eb/Nt

To maintain the minimum acceptable Eb/�t at the base station, when capacity increases,

the increase in interference causes all of the ATs in the coverage area to increase their

transmitting power. Those ATs transmitting from the cell outer parameter at or near full

power may not be able to increase their transmit power sufficiently to bring their Eb/�t

level at the base station up to the minimum acceptable level. As a result, the call from

these ATs will be dropped. Effectively, the higher capacity causes the cell coverage area to

shrink.

Upper limit

The upper limit of sector capacity is reached when, in addition to shrinking, any newAT

call, regardless of position, does not have enough power to overcome the level of

interference generated by current ATs, and the current ATs do not have enough power to

overcome the additional interference that would be generated by a new call.

The upper limit is influenced by any factor that varies the level of signal and/or

interference at the base station. For example, a heavily loaded neighbor cell will increase

the level of interference and lower the base station capacity. The amount of reverse link

traffic activity will affect capacity because the AT restricts the output power when not

transmitting. Capacity is also affected by soft handoff populations because the diversity

gain inherent in the use of multiple receivers allows the ATs to reduce their transmit

power.

Flexibility

The multiple factors influencing CDMA capacity give rise to a desirable flexibility in

system operation. The dependence on interference levels means that a cell capacity is

inherently dynamic; i.e., a base station can naturally absorb more users if neighboring

cells are lightly loaded. In addition, the system can naturally exploit the reduced levels of

interference generated by low traffic activity.

RF Coverage and Capacity Capacity OverviewCapacity/Coverage Trade-off

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

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

5-50 401-614-323Issue 16 October 2009

Page 361: 1xev-Do Rf Engineering

When the capacity decreases, the overall interference level also decreases, and the

coverage area will expand. The shrinking and expanding of the cell coverage area is

known as cell breathing. To compensate for cell shrinkage of coverage areas, base stations

may be spaced so that the footprints of adjacent sectors overlap each other to avoid

dropped calls when usage increases.

Low Data Rates in Rev A

The problem of dropped calls due to increased capacity is mitigated in Rev A by the

introduction of the 8.4-kbps low data rate. This data rate is primarily intended to service

voice calls over small payload single-user VoIP packets. However, this low data rate

service may also benefit idle ATs or ATs handling mostly high latency traffic types.

Because the minimum acceptable Eb/�t for calls at this data rate is low, the call can be

delayed longer from being dropped in anticipation that handoff to a stronger signal will

soon occur.

RF Coverage and Capacity Capacity OverviewCapacity/Coverage Trade-off

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

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

401-614-323Issue 16 October 2009

5-51

Page 362: 1xev-Do Rf Engineering

Pole Capacity

Description

System design must use a loading margin to protect against too much coverage area

shrinkage. The loading margin provides a built-in overlap to avoid the creation of holds

resulting from shrinkage. The loading margin is a function of the percentage of a pole

capacity for the sector. The pole capacity is the theoretical maximum number of users

served by a single carrier on a cell, and is a function of the traffic channel activity factor

(α), the processing gain (g), and the interference ratio (β).

At this maximum capacity (pole capacity), the coverage is at its minimum, zero miles.

This is because at maximum capacity, or 100% loading, the noise rise is so high that other

than being next to the cell sites, the ATs cannot achieve the desired Eb/�t level.

Therefore, to have an appreciable coverage, a load factor is introduced. The load factor

selected is a function of the percentage of the pole capacity that the service provider is

willing to trade off for coverage.

Determining Receiver Interference Margin

Figure 5-5, “Determining Receiver Interference Margin” (p. 5-18), which is reproduced in

Figure 5-20, “Determining Receiver Interference Margin” (p. 5-53), shows that as the

load factor increases from zero to 100 percent, which is the pole capacity, the total noise

level will increase from zero dB to infinity. When designing a system, an engineering or

policy decision is made in determining what load factor to use. Whenever a load factor is

selected, its associated noise level must be accounted for in the reverse link budget (refer

to “Receiver Interference Margin” (p. 5-17)). If the load factor is too low, capacity is

sacrificed. If the load factor is too high, coverage is sacrificed. A good place to start is in

the fairly linear region between 50 and 75 percent. Because of its faster power control and

its uplink pilot channel, 3G systems are tolerant of slightly more noise than the IS-95

system, and the load factor can be set closer to the 75 percent region. The expectation is

that 1xEV-DO will support loadings (percentage relative to pole point) similar to 3G-1X,

which are currently being designed for typical cases of 72% of pole point loading. In

accordance with Figure 5-20, “Determining Receiver Interference Margin” (p. 5-53), 72%

corresponds to a noise rise of 5.5 dB.

RF Coverage and Capacity Capacity OverviewPole Capacity

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

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

5-52 401-614-323Issue 16 October 2009

Page 363: 1xev-Do Rf Engineering

Forward vs. Reverse Link

The reverse link is expected to support users with throughput of up to one quarter of the

forward link throughput. The reverse link can also be analyzed for a maximum number of

simultaneous users, using a pole point analysis similar to a regular CDMA system.

However, the result is dependent on traffic model assumptions. Also, the number of users

the system can support must take the influence of the dormancy state.

Much of the reverse link capacity is used for control information rather than user data.

Because of the fundamental differences in how the reverse and forward links operate,

capacity analysis for the two links is completely different. The reverse link is analyzed in

a method similar to voice systems and results in a maximum number of simultaneous

users. The maximum number of users is fixed at 59 by Walsh code limitations. This

number can be reduced by a parameter inserted into the system database. The forward

link analysis results in per-sector throughput. Forward link capacity is expressed as an

average sector throughput. A typical capacity that can be used for planning purposes is an

average sector throughput in the range of 500 to 600 kbps.

Figure 5-20 Determining Receiver Interference Margin

The receiver interference margin, sometimes referredto as loading margin, accounts for the interferencecontributed by other users in the environment. Here,the relationship between interference and percentage ofloading is illustrated.

0 10 20 30 40 50 60 70 80 90 100Percent Loading

0

2

4

6

8

10

12

14

16

18

20

Nois

e R

ise (

dB

)

5.5

72%

RF Coverage and Capacity Capacity OverviewPole Capacity

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

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

401-614-323Issue 16 October 2009

5-53

Page 364: 1xev-Do Rf Engineering

Reverse Link Capacity

Overview

Purpose

The Pilot, RRI, and DRC Channels on the reverse link are transmitted continuously by

every AT in the service area that is in the active state. This is true regardless the quantity

of data the AT has to send. Therefore, the 1xEV-DO reverse link analysis is a hybrid

between the approach taken for typical CDMA voice and data. The number of users that

can be accommodated on the coverage area established by the reverse link budget

analysis can be obtained by first determining the pole capacity. This number is then

multiplied by the loading factor (typically 72%) used on the reverse link budget

spreadsheet.

Contents

Spectral �oise Density 5-55

Pole Capacity Calculation 5-57

Channel Gain 5-59

Interference ratio and channel activity 5-62

Increased capacity in the reverse link 5-64

Traffic Model 5-65

Rev A performance 5-67

Pole Point Based Capacity Calculation 5-69

Capacity Objectives 5-71

Data Traffic Load in Erlangs 5-72

Determining Average �umber of Reverse Link Channels Required 5-75

RF Coverage and Capacity Reverse Link CapacityOverview

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

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

5-54 401-614-323Issue 16 October 2009

Page 365: 1xev-Do Rf Engineering

Spectral Noise Density

Pilot Channel Ec/Nt

The reverse link pilot channel chip energy (Ec) to noise (�t) ratio can be used to derive a

reverse pole capacity equation in terms of the maximum number of users at 100% pole

capacity. The equation will be developed for a centrally embedded base station under

idealized conditions, assuming that power control acts to maintain a constant receiver

power from all ATs in the service area. Under these conditions, the minimal reverse link

pilot channel Ec/�t value at the base station receiver for each reverse link signal equals

the required pilot channel Ec/�t, identified as d:

Description

In the above equation, Ec/�t is the ratio of pilot channel chip energy to total spectral noise

density. The total spectral noise density is obtained by summing background thermal

noise density (�o ), and the spectral density of broadband interference from all other

CDMA users. The background thermal noise density must be adjusted by the base station

noise figure (F). The spectral density of broadband interference from all other CDMA

users is composed of contributions from users both within the cell and in other cells.

Different users have different pilot channel Ec/�t requirements to maintain a certain

packet error rate (PER). For example, static users need less pilot channel Ec/�t to maintain

a PER of 1% as compared to users traveling at 3 m.p.h., and higher mobility users (about

30 m.p.h.) have different pilot channel Ec/�t requirement as compared to low mobility

and static cases. In the capacity derivation, we take a pilot channel Ec/�t at the worst-case

value.

The range of required pilot channel Ec/�t values at the cell site receiver is a slowly

varying function of AT speed and multipath condition. The latter is determined by the

number of paths that can be separately demodulated at the rake receiver. The range of

possible values has been measured. Generally, a minimum of two multi-paths can be

assumed because the diversity-receive antennas employed at the cell site guarantee the

presence of at least two paths. The narrow range of values within the two multipath cases

permit the use of a worst-case value for all ATs without being overly conservative.

The pilot channel Ec/�t is proportional to pilot channel power (Ppilot ) divided by the base

station noise power, plus spectral density of broadband interference from all other CDMA

users within the sector and neighboring sectors.

Figure 5-21 Equation 14E

Nc

t------

Pilotd=

RF Coverage and Capacity Reverse Link CapacitySpectral Noise Density

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

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

401-614-323Issue 16 October 2009

5-55

Page 366: 1xev-Do Rf Engineering

Base Station Noise Power

The base station noise power is the product of thermal noise density �o , CDMA

bandwidth W, and the base station noise figure F, (F�thW). This quantity is a useful

reference point for measuring the strength of incoming signals.

Interference From All Other CDMA Users

Within a sector, the restriction of equal pilot channel Ec/�t for all calls can be shown to

require that all signal strengths received at the cell site are equal to the common term, Ptot. The interference from all other ATs within the sector equals (�-1)Ptot , where � is the

number of ATs within the sector. This term, (�-1)Ptot , is the primary source of

interference on the reverse link.

The co-channel interference fromATs outside the sector is a secondary source of

interference and can be taken to be a fraction, β, of the in-cell interference. The low

transmitter strength and increased distance (path loss) of the surrounding ATs produces an

interference level that can be typically characterized by β < 1. Unlike the in-cell

interference, the interference fromATs outside the cell is not under power control by the

cell site receiver, and is therefore more difficult to determine; however, only the aggregate

affect of all outside ATs need be known with any accuracy: the large number of

surrounding ATs, as well as the inherent randomness in their locations, generates an

averaging affect that facilitates prediction.

RF Coverage and Capacity Reverse Link CapacitySpectral Noise Density

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

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

5-56 401-614-323Issue 16 October 2009

Page 367: 1xev-Do Rf Engineering

Pole Capacity Calculation

Simplifications

The relatively low level of co-channel interference allows the use of a β , where β < 1,

without being overly conservative. Further, for large �, all interference can be reduced by

a factorα that reflects the mean traffic activity (less than 100%) across all active channels

on the reverse link. These considerations lead to:

where:

• d = Ec/�t

• Ec = Chip energy

• �t = Spectral density of thermal noise plus interference

• �th = Spectral density of thermal noise

• F = Base station noise figure

• Ptot = Received signal strength

• α = Channel activity factor

• β = Interference factor

• � = �umber of ATs in sector

• W = System bandwidth.

Solving for N max

Solving for �, the above expression can be rewritten to explicitly indicate the number of

AT users:

In the above equation, the finite limit on capacity can be conveniently reached by letting

the signal-to-cell-site noise ratio go to infinity. In this case, the received signal power, Ptot, becomes unbounded with respect to the sector noise, F�thW, causing the last term to

drop. Therefore, the theoretical maximum number (�max ) of ATs at pole capacity is:

Figure 5-22 Equation 15

dPpilot

F Nth× W× N - 1( ) ! +1 ××+=

( )ß × Ptotα

Figure 5-23 Equation 16

NPpilot

Ptot

-------------è øæ ö 1

α d 1 ß+( )------------------------------------

è øæ ö 1

F Nt h W

a 1 +( ) Ptot

-------------------------------------------–+´=

´ ´ ´ ´

´´

ß

RF Coverage and Capacity Reverse Link CapacityPole Capacity Calculation

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

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

401-614-323Issue 16 October 2009

5-57

Page 368: 1xev-Do Rf Engineering

Total power to Pilot power

The total power a given AT transmits is the sum of the pilot channel power, the DRC

channel power, and the traffic channel power. �ote that to simplify the analysis, the ACK

channel is ignored since only one AT transmits the ACK channel at a time. The DRC

channel and traffic channel powers are set relative to the pilot channel power by digital

gain factors inserted into the RC/V data base, so that the total power to pilot power ratio

can be expressed as:

where:

GDRC = DRC channel gain translation in dB stored in the RC/V data base GTraffic = Traffic

channel gain translation in dB stored in the RC/V data base.

Pole capacity Figure 5-24, “Equation 17” (p. 5-58) can then be written as:

Determining Theoretical Maximum Number of Users

The maximum number of AT users calculated at pole capacity, sometimes referred to as

the pole point or power pole, represents a theoretical maximum that cannot be reached.

The value of �max calculated in Figure 5-26, “Equation 19” (p. 5-58) serves as a useful

reference point. Sector loading can be conveniently expressed as a fraction of the pole

point. 1xEV-DO are expected to support loadings (percentage relative to pole point)

similar to 3G-1X, which is currently being designed for typical cases of 72% of pole point

loading.

To implement Figure 5-26, “Equation 19” (p. 5-58), typical values are used to provide a

conservative capacity estimate; when appropriate, worst cast values are selected for DRC

and traffic channel gains, channel activity factor (α ), interference ratio (β) , and Ec/�tratio (d).

Figure 5-24 Equation 17

Nmax

Ppilot

Ptot

------------- 1

α d 1 β+( )------------------------------------

1+×=

× ×

Figure 5-25 Equation 18×α Ptot

Pp i lo t

------------------- 1 10G

D R C( ) 10⁄

10GTraf f ic( ) 10

+ += ×⁄

ά

Figure 5-26 Equation 19

Nmax1

ά 10GTraf f ic 10⁄

×+

-------------------------------------------------------------------------------1

d 1 ß+( )-------------------------- 1=

1 10GDRC 10 −

××⁄

+

RF Coverage and Capacity Reverse Link CapacityPole Capacity Calculation

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

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

5-58 401-614-323Issue 16 October 2009

Page 369: 1xev-Do Rf Engineering

Channel Gain

Description

The amplitudes of the signal on the DRC and traffic channels are scaled by gain factors

relative to the amplitude of the pilot signal. The gain factors, which are inserted into the

RC/V database and represented by the DRC channel gain (GDRC ) and traffic channel gain

(Gtraffic ) factors in Figure 5-26, “Equation 19” (p. 5-58), are specified relative to the

required pilot channel power).

Required Pilot Channel Ec/Nt Ratio (δ)

The required pilot channel Ec/�t ratio (δ) is a function of the following:

• AT speed

• Handoff state

• Multipath condition

• Desired packet error rate (PER)

• Traffic channel rate.

The required pilot channel Ec/�t ratio has been determined by link level simulation for a

variety of conditions. The worst-case ratios, which are used for a conservative capacity

estimate, are given in Table 5-14, “Required Pilot Channel Ec/�t (δ )” (p. 5-59).

Table 5-14 Required Pilot Channel Ec/Nt (δ )

Traffic Channel Data Rate (kbps) Required Pilot Channel Ec/Nt (dB)

9.6 -23

19.2 -23

38.4 -23

76.8 -23

153.6 -22

The 153.6 kbps traffic channel data rate uses less robust turbo coding than other traffic

channel data rates (1/2 rate versus 1/4 rate). Hence, the 153.6 kbps traffic channel data

rate requires a higher pilot channel Ec/�t ratio.

RF Coverage and Capacity Reverse Link CapacityChannel Gain

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

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

401-614-323Issue 16 October 2009

5-59

Page 370: 1xev-Do Rf Engineering

Traffic Channel Gain

The Traffic Channel gain relative to the pilot power is a function of traffic channel rate.

The following values, given in Table 5-15, “Traffic Channel Gain” (p. 5-60), are

recommended.

Table 5-15 Traffic Channel Gain

Traffic Channel Data Rate (kbps) Traffic Channel Gain

9.6 3.75

19.2 6.75

38.4 9.75

76.8 13.25

153.6 18.5

DRC Channel Gain

The DRC channel power is specified relative to the pilot channel. The recommended

value for DRC channel gain, relative to the pilot power, is a function of DRC length

factor and is given in Table 5-16, “DRC Gain” (p. 5-60). These values are selected from

link level simulations to produce a low probability of DRC errors to limit the result on

forward link throughput performance.

Table 5-16 DRC Gain

DRC Length Value DRC Update Rate (Hz) DRC Channel Gain

(doubles)

1 600 0

2 300 -1.5

4 150 -4.5

8 75 -6

Essential to the DRC value is a four-bit value indicating a null or a forward data rate

value form 1 to 12. The four-bit value is bi-orthogonal encoded and repeated once. The

symbol then is spread by one of seven W8Walsh code cover sand one of W18 long Walsh

code to produce a 128-chip sequence. The selected Walsh code function identifies the best

serving selector measured by the AT. Ultimately, the 128-chip sequence is spread to a

2048-chip sequence to fill the 1.67-ms transmission slot period. The DRC length factor

specifies the number of repetitions of the same information bit. When the DRC length

value is 1, the DRC chip sequence is transmitted during each 1.67-ms slot period,

resulting in a 600-Hz update rate. A DRC length value of 2 will repeat the same

RF Coverage and Capacity Reverse Link CapacityChannel Gain

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

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

5-60 401-614-323Issue 16 October 2009

Page 371: 1xev-Do Rf Engineering

information once and provide a 300-Hz update rate.DRC length values of 4 and 8

transmit the same information four and eight times, respectively, providing an update rate

of 150 Hz and 75 Hz.

Increasing the DRC length increases DRC channel processing gain, enabling transmission

of DRC channel data at less power. At lower power levels, less interference is introduced

in the reverse link environment, resulting in increased capacity to support a greater

number of users. The trade-off from longer DRC lengths is forward link throughput. The

slower the DRC channel information, the less responsive the base station is to changing

AT RF environment conditions. This includes missed opportunities for faster data rates

when the RF environment conditions improve, and retransmission when the RF

environment conditions worsen.

Alcatel-Lucent sets the default value for the DRC length to 2.

RF Coverage and Capacity Reverse Link CapacityChannel Gain

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

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

401-614-323Issue 16 October 2009

5-61

Page 372: 1xev-Do Rf Engineering

Interference ratio and channel activity

Interference Ratio (βf )

The inter cell interference ratio, βf is expected to be similar to the values used in

analyzing other CDMA technologies, i.e., IS-95 and 3G-1X. The interference ratio was

determined by system level simulation. Typical values for βf are given in Table 5-17,

“Interference Ratio β” (p. 5-62).

Table 5-17 Interference Ratio β

Cell SectorizationAT Antenna

Omni Directional

Omni 0.6 0.15

3-Sector 0.85 0.25

6-Sector 1.2 0.2

Channel Activity Factor (α)

The expected channel activity factor is dependent on the user's behavior, which can be

simulated by a traffic model and is discussed in the following section. The average

channel activity factor is the actual user throughput divided by the net channel

throughput. To determine the actual user throughput on the reverse link, the overhead

information of associated 1xEV-DO must to be subtracted from the transmitted data. The

overhead information is 48 bits per packet and is divided as follows:

• Physical layer: 22 bits

• MAC layer: 2 bits

• Stream layer: 2 bits

• RLP sequence number: 22 bits.

Overhead percentage

The overhead percentage is then calculated to determine the net throughput rate. For

example, at the 9.6 kbps data rate, the net throughput is determined by first calculating the

overhead percentage, which is the ratio of the usable packet bit size, to the transmitted

packet length bit size times 100% (208/256 X 100% = 18.8%; see Table 5-18, “Reverse

Link �et Throughput” (p. 5-63)). The usable packet bit size is obtained by subtracting the

48 overhead bits from the 256-bit packet transmitted at the 9.6 kbps data rate. The

overhead percentage, which in this case is 18.8%, represents that portion of the 9.6-kbps

data rate that is used to transmit the overhead bits.Therefore, 81.2% (100% - 18.8%) of

the 9.6 kbps transmission rate, or 7.8 kbps, represents the usable net throughput data rate.

RF Coverage and Capacity Reverse Link CapacityInterference ratio and channel activity

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

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

5-62 401-614-323Issue 16 October 2009

Page 373: 1xev-Do Rf Engineering

A traffic model defining how the user of a specific demographic is expected to use

wireless service must be constructed to calculate the traffic channel activity factor. The

traffic model discussion in the following section (“Introduction” (p. 5-65)) for web

browsing shows that a typical user reverse link offered load is expected to be about 2

kbps. The 2 kbps throughput does not represent a data rate, but simply indicates the

number of bits that must be received within each second to support a particular traffic

model activity. Thus, the reverse link 2 kbps offered load value is independent of the

reverse link data rate.The reverse link traffic channel activity factor indicates what portion

of the net throughput is used to transmit user data. Therefore, the reverse link traffic

channel activity factor is computed by dividing the user offered load, which for web

browsing is about 2 kbps, into the net offered load calculated at each data rate. As the data

rate increases, the traffic channel activity factor will proportionately decrease.

Reverse Link Net Throughput

Table 5-18 Reverse Link Net Throughput

ParameterData Rate (kbps)

9.6 19.2 38.4 76.8 153.6

Packet length (bits) 256 512 1024 2048 4096

Overhead (bits) 48 48 48 48 48

Usable packet (bits) 208 464 976 2000 4048

Overhead percentage

(%)

18.8 9.4 4.7 2.3 1.2

�et Throughput

(kbps)

7.8 17.4 36.6 75.0 151.8

User Throughput for

Web Browsing

2 kbps 2 kbps 2 kbps 2 kbps 2 kbps

Traffic Channel

Activity Factor (α )10.256 0.115 0.055 0.027 0.013

Notes:

1. For web browsing traffic model only

RF Coverage and Capacity Reverse Link CapacityInterference ratio and channel activity

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

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

401-614-323Issue 16 October 2009

5-63

Page 374: 1xev-Do Rf Engineering

Increased capacity in the reverse link

Description

The increased capacity in the reverse link is due to hybrid-ARQ early termination. Rather

than transmitting the packet in one 16-slot frame, the system tries to send the packet in

one, two, or three sub-frames. This is done providing that the AT has enough T2P

resources in its T2P token bucket to transmit the first, first two, or first three sub-packets

at a higher power level to encourage early termination. As a result, the packet effective

data rate is increased and the overall transmit power is most likely reduced. The latter is

true because, although the sub-packets are transmitted at a higher power level rather than

transmitting four sub-packets, only one or two sub-packets are transmitted.

Power level required to achieve termination target

A termination target is the average number of sub-packets to be transmitted to achieve

early termination. Table 5-19, “Power level required to achieve termination target”

(p. 5-64) identifies the power level required above the pilot power to achieve a

termination target for a specific payload size. For example, to achieve early termination

for a 1024-bit payload after the second sub-packet is transmitted, which is after 8 slots,

the first two sub-packets are transmitted at a power level 16.25 dB higher than the pilot

power.

Table 5-19 Power level required to achieve termination target

Payload16 12 8 4

128 0.75 3.2500 6.75 13.25

256 3.75 6.5000 10.00 16.25

512 7.00 9.5000 13.25 19.25

768 8.75 11.5000 15.00 22.25

1024 10.00 12.5000 16.25 23.25

1536 11.75 14.0000 18.00 25.25

2048 13.00 15.5000 19.50 27.25

3072 14.25 16.2500 19.25 25.25

4096 15.50 17.5000 20.50 27.25

6144 17.00 19.0212 22.25 28.00

8192 18.50 20.2712 23.75 28.00

12288 21.25 23.7710 26.75 28.00

Termination target (slots)

RF Coverage and Capacity Reverse Link CapacityIncreased capacity in the reverse link

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

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

5-64 401-614-323Issue 16 October 2009

Page 375: 1xev-Do Rf Engineering

Traffic Model

Introduction

Traffic models can be constructed to estimate forward and reverse link data air interface

capacity, and should represent how the service provider expects subscribers to use the

service. The traffic model will vary from one demographic area to another and should be

evaluated on a case-by-case basis. For example, usage in industrial areas, where users

frequently check prices and shipping and delivery schedules, will differ from usage in

business areas, where users frequently send and receive e-mail, browse the web and FTP

files, and that will differ from airports, where travelers may just want to send and receive

e-mail.

HTTP traffic model

In the following text, the HTTP traffic model, similar to the one defined in 1xEV-DV

Evaluation Methodology - Addendum (V6) from the 3GPP2, is selected to illustrate how

a traffic model may be used. Although this traffic model is an evaluation of 1xEV-DV

(Data Voice) as opposed to 1xEV-DO (Data Only), Alcatel-Lucent does not expect that

user behavior will differ between the two. Also, this traffic model specifies a mix of data

services (WAP, HTTP, FTP, and streaming video). To simplify the analysis here, only

HTTP is considered. A similar analysis can be performed for a mixed case.

The traffic model makes simplifying assumptions and ignores the statistical variations of

the model parameters, i.e., only mean values are considered, not the distribution of

possible values. Examples of parameters used to characterize a traffic model, and a

description of the parameters for the aforementioned HTTP traffic model, are given in

Table 5-20, “HTTP Traffic Model Parameters” (p. 5-65).

HTTP Traffic Model Parameters

Table 5-20 HTTP Traffic Model Parameters

Parameter Description Traffic Model

Application Web browsing, e-mail, FTP, etc. Web browsing HTTP 1.1

Layer 4 protocol TCP vs. UDP TCP (Required for HTTP)

Think time, sometimes

referred to as reading time

Time user is reading without

requesting or sending new data

30 seconds

Packet calls per session The number of web page views or

e-mails downloaded

Packet call size Web page size for HTTP, file size for

FTP or e-mail size

54465 bytes

RF Coverage and Capacity Reverse Link CapacityTraffic Model

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

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

401-614-323Issue 16 October 2009

5-65

Page 376: 1xev-Do Rf Engineering

Table 5-20 HTTP Traffic Model Parameters (continued)

Parameter Description Traffic Model

Objects per packet call and

object size

Typically for web browsing, the

number object embedded on a web

page

5.64 (7.758 kilobyte per

object)

Maximum Transmission

Unit (MTU) size

Used to define TCP segments. If

HTTP request packet is large, the

TCP stack divides the HTTP packet

into two or more TCP segment in

accordance with the MTU size is

about the web page size divided by

MTU size or 54465/1500 = 36

segments.

1500 bytes (Web page size

is divided by MTU size or

54465/1500 = 36

segments)

Session time Time user is logged on

Activity on the Reverse Link

HTTP GET Method to retrieve whatever

information (in the form of an entity)

is identified by the request-URL

364 bytes (Approximately

65 bytes per GET times

5.6 objects per page)

TCP connection setup and

tear-down

Three packets of 40 bytes each 120 bytes

Layer 4 TCP

acknowledgment (ACK)

Assume each forward TCP segment

is acknowledged, total number of

forward

1452 bytes (Each ACK is

40 bytes long: 36

segments X 40 bytes)

Activity on the reverse link

From examining the activity on the reverse link, the total reverse link transmitted traffic is

1936 bytes (364 + 120 + 1452), or 15488 bits. The time the user transmits this much data

on the reverse link is the total download time plus the smaller of either the think time or

the dormancy time. Currently, the default for the dormancy timer is 10 seconds. Assuming

that the download time is small compared to the dormancy time, a reverse link throughput

is 15488 bits divided by the 10-second dormancy time, or about 1550 bits per second for

the user's traffic.

Simulations show that the over-the-air signaling traffic associated with this traffic model

is about 450 bps per user. Combining the signaling traffic and the user's data traffic yields

a total throughput per user of about 2 kbps.

RF Coverage and Capacity Reverse Link CapacityTraffic Model

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

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

5-66 401-614-323Issue 16 October 2009

Page 377: 1xev-Do Rf Engineering

Rev A performance

Description

1xEV-DO networks using the Rev A features will have higher air-interface capacity then

Rev 0 systems (see Figure 5-27, “Rev A performance” (p. 5-68)). Rev A air-interface

provides peak data rates of up to 3.07 Mbps in the forward link, and up to 1843.2 kbps in

the reverse link for a single user. Computer simulation estimates that Rev A forward link

average aggregate RLP throughput to be around 1.1 Mbps per carrier-sector, with dual

antenna at the AT. The reverser link average aggregate RLP throughput is about 400 kbps

per carrier-sector, using two-way receive diversity. The reverse link capacity is expected

to further increase by using four-way receive diversity. Preliminary simulation results

indicate that such increase is around 70% above the capacity with two-way receive

diversity.

Factors

In a Modular Cell 1-3, each SB-EVMm modem card in the CDM supports up to 192

Channel Elements (CEs) to serve three sector-carriers using two-way receive diversity.

The VoIP capacity is estimated to be around 35 Erlang per sector-carrier, which translates

to 45 primary users based on 2% blocking criterion. The total number of CEs required is

estimated to be around 184 CEs, assuming CEs are pooled across 3-sectors and a

soft-handoff overhead of 40% is used. If an additional carrier is needed, then additional

CDMs are required as a CDM supports only three sector-carriers. All Modular Cells 1-3

can support up to three CDMs. The overall capacity of the Modular Cell 1-3 is limited by

the backhaul, i.e. the number of T1 lines deployed. AModular Cell 1 with one URCm

card supports up to 2 T1 lines. Modular Cell 2-3 with one URCm supports up to 4 T1

lines. Furthermore, the capacity could be also limited by the URCm processing capability.

RF Coverage and Capacity Reverse Link CapacityRev A performance

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

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

401-614-323Issue 16 October 2009

5-67

Page 378: 1xev-Do Rf Engineering

Rev A performance table

Figure 5-27 Rev A performance

Reverse linkRLP troughput

Foward linkRLP troughput

Number of activepacket data usersper sector-carrier

Number of VoIPcalls persector-carrierwith 2% blocking

-Four way receive diversity

-Two way receive diversity

AT with single antenna

AT with dual antenna

Dual antenna receiveforward and reverse links

Dual antenna receiveforward and reverse links

200 kbps

1000 kbps 1100 kbps

800 kbps

680 kbps

400 kbps

700 kbps

340 kbps

Rev 0 Rev A

20

N/A

30

45(35 Erlang)

RF Coverage and Capacity Reverse Link CapacityRev A performance

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

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

5-68 401-614-323Issue 16 October 2009

Page 379: 1xev-Do Rf Engineering

Pole Point Based Capacity Calculation

Description

A pole point analysis is performed to determine the maximum number of sessions (RF

channels) that can be supported on the reverse link. Because the traffic channel data rate

and channel activity factor will differ among users, using pole point Figure 5-26,

“Equation 19” (p. 5-58) to determine the maximum number of sessions (users) at 72%

loading is more complicated than determining the pole point number of users for voice

systems.

Simplest case

The simplest case, which may provide insight into the capacity of the system, would be to

assume a channel activity factor (α ) of 1 for all users which means that all ATs in the

covered are continuously transmitting data. Table 5-21, “MaximumActive Data Sessions

at 72% Loading for Full Buffer Traffic Model” (p. 5-69) shows the resulting maximum

number sessions computed for each data rate. The values for Ec/�t (d), traffic gain (Gtraffic), DRC gain (GDRC ), and interference ratio (β ) are extracted from Table 5-14, “Required

Pilot Channel Ec/�t (δ )” (p. 5-59) through Table 5-17, “Interference Ratio β” (p. 5-62),

respectively.

Table 5-21 Maximum Active Data Sessions at 72% Loading for Full Buffer Traffic

Model

Data RateDRC Length

1 2 4 8

none 38.8 45.3 57.0 61.6

9.6 18.2 19.4 21.3 21.8

19.2 12.0 12.6 13.2 13.5

38.4 7.4 7.6 7.8 7.8

76.8 4.0 4.1 4.1 4.1

153.6 1.5 1.6 1.6 1.6

�ote that the first row (labeled none) is the computation for the case of no traffic

channels. In this case, the ATs are transmitting only the DRC and pilot overhead channels.

Confidence

The confidence in the table values decreases as the number of users decrease. The values

in the table are the result of a calculation that uses average values for multiple random

terms. As the number of users decreases, the variance of these terms that are random will

increase. Hence, the confidence in the values in the table decreases as the number of users

RF Coverage and Capacity Reverse Link CapacityPole Point Based Capacity Calculation

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

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

401-614-323Issue 16 October 2009

5-69

Page 380: 1xev-Do Rf Engineering

decrease. Furthermore, the assumption of all ATs at the same channel rate does not match

the dynamic nature of reverse link channel rate control. However, the results are useful

for general capacity planning purposes.

Maximum Active Data Sessions at 72% Loading for Web Browsing Traffic Model

In Table 5-22, “MaximumActive Data Sessions at 72% Loading for Web Browsing

Traffic Model” (p. 5-70), the maximum number of sessions is again computed for each

data rate using the channel activity factor computed in Table 5-18, “Reverse Link �et

Throughput” (p. 5-63) for typical web browsing users.

Table 5-22 Maximum Active Data Sessions at 72% Loading for Web Browsing

Traffic Model

Data RateDRC Length

1 2 4 8

9.6 30.1 33.8 39.7 41.9

19.2 30.7 34.6 40.9 43.2

38.4 31.4 35.5 42.0 44.4

76.8 30.9 34.7 41.0 43.3

153.6 21.8 24.2 27.8 29.1

As shown in the above table, the capacity in terms of the maximum number of sessions is

almost independent of data rate. The higher data rates require higher traffic gain. The

resulting extra power is offset by the decrease in the amount of time the channel is used

(i.e., channel activity). The capacity for the 153.6 kbps channel users is lower because of

the higher required Ec/�t .

RF Coverage and Capacity Reverse Link CapacityPole Point Based Capacity Calculation

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

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

5-70 401-614-323Issue 16 October 2009

Page 381: 1xev-Do Rf Engineering

Capacity Objectives

Determining Target Capacity

The results of the pole point analysis performed in the previous section determined the

maximum number of active sessions that can be supported on the reverse link. The actual

number of active sessions that may be supported on the reverse link is limited to the

number of users that can be supported on the reverse link and the number of Walsh codes

available. This number may vary greatly, depending on the activity of the users.

Extensively, a greater number of users downloading simple text e-mail may be

accommodated than users downloading web pages with large graphic files. Therefore,

most likely, this maximum number of forward link active sessions will be achieved in

only a fraction of the time.

A practical approach when allocating base stations to support data traffic is to design for a

target capacity that reflects an average amount of session usage in a geographical area. An

efficient and cost-effective design is one that will accommodate a maximum number of

busy-hour data traffic, while in the long term having the least number of its resource

capacity idle for the shortest period of time. Ideally, the perfect system will have none of

its resources idle at any time, with zero percent data delay. While the ideal situation can

never be achieved, a system can be designed to meet expected average busy hour data

traffic at a minimum resource expenditure by allowing an acceptable response delay.

Acceptable Call-blocking Objective

Fundamental elements of system design include determining the hardware resources

needed to meet target traffic capacity. For voice, which requires immediate service when

a call is originated or terminated, the target traffic capacity is specified at an acceptable

call-blocking objective. The call blocking objectives, sometimes referred to as blocking

probabilities, identify the percentage of call requests for channel resources denied because

the resources required to comply with the requests are currently not available.

Acceptable Queue Delay Objective

In a data-only system such as 1xEV-DO, the real-time constraints demanded for voice

systems is relaxed. Delay, or latency, can be tolerated for data traffic, reducing the

blocking probability to zero. That is, rather than block the call, the request for data traffic

is held in a queue until resources become available to service the data traffic request.

Instead of designing for an acceptable blocking rate, data traffic systems are designed for

an acceptable queuing delay.

RF Coverage and Capacity Reverse Link CapacityCapacity Objectives

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

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

401-614-323Issue 16 October 2009

5-71

Page 382: 1xev-Do Rf Engineering

Data Traffic Load in Erlangs

Introduction

Traffic usage can be measured in Erlangs. One Erlang is the usage of a single channel

resource for one hour, or 3600 seconds. When defining the data capacity of a group of

channels within a base station, one Erlang is the usage of a subset or all of the base station

channels where the cumulative usage time of all un-idle channels is equal to one hour.

Therefore, one Erlang is also equal to the usage of two channels for one-half hour, or four

channels for one-quarter hour, and so on.

The average busy hour usage of a base station in Erlangs can be estimated from its user

population. Here, the load contributed from a typical user for the average busy-hour call

duration is estimated in Erlangs. This value is then multiplied by the average number of

calls that may be served at any one time during a typical busy call hour.

General Erlang Model

For voice traffic, which exists in a real-time domain, tables for specific blocking

objectives in terms of the number of channels required for a given traffic load are used for

channel provisioning. These tables are based on telecommunication traffic statistics of

Poisson exponentially-distributed arrival times and distributed call durations. Although

standard mathematical models exist for representing the behavior of voice traffic, the

Erlang B table, which is based on a special Erlang B model, is generally used because of

its simple concepts for provisioning voice channels. Because data traffic is delay-tolerant,

delay rather than blocking becomes an issue when determining traffic usage. When

provisioning for data traffic, the Erlang C model is generally used. The B and C models

are special cases of the general Erlang model, and the difference between the B and C

models is best described with reference to the general Erlang model illustrated in Figure

5-28, “General Erlang Model” (p. 5-73).

RF Coverage and Capacity Reverse Link CapacityData Traffic Load in Erlangs

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

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

5-72 401-614-323Issue 16 October 2009

Page 383: 1xev-Do Rf Engineering

The general Erlang model shows � servers and a queue of M length. Calls or requests for

service are received at the average arrival rate, designated by the Greek letter lambda (λ),

which is expressed by the number of requests per unit of time. The average call or

message completion rate is represented by another Greek letter, µ, which is the number of

calls or messages transmitted per unit of time. Therefore, the system average completion

rate is � times µ, and the average duration of service required by each request is one over

µ, where � equals the number of servers and the total capacity of the system is equal to �

plus the length of the queue, M. When the queue is empty and at least one server is idle,

the next service request arrival is immediately passed through the queue and is serviced

by the idle server. If all the servers are busy, subsequent request arrivals are backed up in

the queue, and when the queue is full, additional requests for service by the next request

arrival are denied or blocked. At this time, the system remains blocked until a server has

completed its transmission and becomes idle. Subsequently, the request at the output of

the queue is serviced by the idle server, and the backed-up requests in the queue are

moved up one place to unblock the system and allow the next request arrival to enter the

queue.

Figure 5-28 General Erlang Model

Arrivals l

Queue (length M)

N Servers

Completion m

Completion m

Completion m

Completion m

m

m

m

m

m

RF Coverage and Capacity Reverse Link CapacityData Traffic Load in Erlangs

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

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

401-614-323Issue 16 October 2009

5-73

Page 384: 1xev-Do Rf Engineering

Erlang B and C Models

In an Erlang B model, the length of the queue is zero. If a service request is received and

all servers are busy in the B model, the service request is blocked, and service is denied.

The length of the queue in the Erlang C model is infinity. When no idle servers are

available, new arrivals of data packets vying for service will be delayed in the queue until

idle servers are made available. Because the length of the queue is infinity, no data

packets will be blocked or denied service. The Erlang C model can be used to compute

the average number of service requests that can be handled when allowing for the

probability of queue delay. When considering 1xEV-DO, the Erlang C model can be used

to compute average number of sessions that can be handled on a single carrier. The

allowable delay is typically normalized to the average service time and expressed as a

delay-to-service time ratio. For example, if the allowable delay, commonly referred to as

target delay, is 5 seconds and the average service time is 25 seconds, the normalized delay

ratio is 5/25 of 0.2.

RF Coverage and Capacity Reverse Link CapacityData Traffic Load in Erlangs

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

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

5-74 401-614-323Issue 16 October 2009

Page 385: 1xev-Do Rf Engineering

Determining Average Number of Reverse Link ChannelsRequired

Description

The average number of reverse link channels required is derived as a function of the

number of users that can be supported on the forward link. As indicated in “Determining

Target Capacity” (p. 5-71), this number is, in turn, a function of the user download

activity, which determines the value of the traffic channel activity factor, a . This number

is also a function of the quality of service (QoS) in the form of latency the service

provider is willing to provide. This allowable delay (latency) is factored into the Erlang C

model by normalizing the delay to the average service time. If the web browsing traffic

model developed in “Introduction” (p. 5-65) is used, the reverse link service time equals

the time required to download the requested web page, plus the time interval between

download requests. Because the RF resources are surrender after a 10-second dormancy

period, a 10-second interval period (worst case condition) should be used.

Time required for a web page

The time required to download a web page is estimated by dividing the average web page

size by the average forward link throughput rate. This throughput rate can be determined

by dividing the carrier throughput, which is the aggregate average forward link rate, by

the expected number of active data sessions. If a carrier throughput of 600 kbps is used

and the number of users is estimated at 20, the average throughput is 30 kbps/user. Using

54.5 kilobytes, which is 436,000 bits (one byte equal 8 bits), as the average web page

size, the download time is about 15 seconds. Adding the 10-second dormancy period, the

reverse link service time equals 25 seconds. If a fixed 5-second delay is used, the

normalized delay ratio is 0.2 (5/25). Using the Erlang C model, the reverse link Erlang

load is computed from Table 5-21, “MaximumActive Data Sessions at 72% Loading for

Full Buffer Traffic Model” (p. 5-69) and Table 5-22, “MaximumActive Data Sessions at

72% Loading for Web Browsing Traffic Model” (p. 5-70) and is given in Table 5-23,

“Erlang capacity (Delay Ratio = 0.2, α = 1)” (p. 5-75) and Table 5-24, “Erlang Capacity

(Delay Ratio = 0.2, α = VAF1)” (p. 5-76), respectively.

Table 5-23 Erlang capacity (Delay Ratio = 0.2, α = 1)

Data Rate DRC Length

1 2 4 8

�one 35.2 42.1 54.0 58.0

9.6 15.6 16.6 18.6 18.6

19.2 9.9 9.9 10.8 10.8

38.4 5.2 5.2 5.2 5.2

RF Coverage and Capacity Reverse Link CapacityDetermining Average Number of Reverse Link Channels

Required...................................................................................................................................................................................................................................

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

401-614-323Issue 16 October 2009

5-75

Page 386: 1xev-Do Rf Engineering

Table 5-23 Erlang capacity (Delay Ratio = 0.2, α = 1) (continued)

Data Rate DRC Length

1 2 4 8

76.8 2.5 2.5 2.5 2.5

153.6 0.16 0.16 0.16 0.16

Erlang Capacity (Delay Ratio = 0.2, α = VAF1)

To provide a realistic average of the user's activity for any demographic, traffic models

(refer to “Introduction” (p. 5-65)) can be constructed for each activity expected to be used

a coverage area. The percentage of total users in each activity is then estimated, and a

weighted average of the traffic activities is calculated in accordance with the percentage

of use in each traffic activity.

Table 5-24 Erlang Capacity (Delay Ratio = 0.2, α = VAF1)

Data RateDRC Length

1 2 4 8

�one 35.2 42.1 54.0 58.0

9.6 27.4 31.3 36.2 38.2

19.2 27.4 31.3 37.2 40.2

38.4 28.3 32.3 39.2 41.1

76.8 27.4 31.3 38.2 40.2

153.6 15.2 17.9 20.6 22.4

Notes:

1. VAF =Variable activity factor

The above analysis is performed to identify the number of active users that can be

supported on the reverse link. The 20 forward link users value chosen for this analysis is

an estimate. If the result of the Erlang C calculation yields values substantially different

from 20, re-calculation is required using a different number of forward link users.

Active Users vs. Total Users

An active data session means that the user is assigned RF resources and is transmitting a

DRC and pilot channel. A user who has not sent or received data for a period longer than

the dormancy time will enter the dormant state. In the dormant state, the user releases RF

resources (pilot channel, DRC Channel, and Walsh codes), but maintains their PPP

session and IP address. The RF resources that are surrendered are now available to other

users. By allowing RF resource sharing, the dormant state allows more users on the

RF Coverage and Capacity Reverse Link CapacityDetermining Average Number of Reverse Link Channels

Required...................................................................................................................................................................................................................................

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

5-76 401-614-323Issue 16 October 2009

Page 387: 1xev-Do Rf Engineering

system than permitted by the carrier RF limits. Users returning from the dormant state to

an active state will have to re-establish RF resources. Because users in the dormant state

maintain a PPP session and IP address, when returning to the active state, the user will not

have to log in and continue data exchange on its original PPP session with its original IP

address. The transition from the dormant state to the active state, although transparent to

the user (no logon required), will incur a setup delay. The dormancy timer is set in the

RC/V data base must be carefully chosen to maximize the number of users, while not

significantly affecting user-perceived delay.

The increase in the number of PPP sessions obtained at a base station by establishing a

dormancy timer can be routinely estimated by dividing the total session time for a user by

the total active time. The total session time includes all the time the user has a PPP

session active (downloading, dormancy timer period and read/think time). The active time

is the time RF resources are assigned to a user (download and a short period permitted by

the dormancy timer). For example, if the average user in a web-browsing scenario takes

10 seconds to download, and 70 seconds to read the page before the next page is

downloaded and the dormancy timer is set to 10 seconds, the active period is 20 seconds;

the 10-second download time plus the 10-second dormancy timer period. In this scenario,

the number of PPP sessions obtained at the base station is increased by a factor of 3.5

(70/20).

RF Coverage and Capacity Reverse Link CapacityDetermining Average Number of Reverse Link Channels

Required...................................................................................................................................................................................................................................

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

401-614-323Issue 16 October 2009

5-77

Page 388: 1xev-Do Rf Engineering

Forward Link Capacity

Overview

Purpose

1xEV-DO is designed to take advantage of the asymmetric nature of expected data

services. The forward link is time-shared instead of code-shared. When a user receives

forward link data, the entire carrier bandwidth and all the base station transmit power is

dedicated to the user. The transmit data rate is determined by the user AT measured

carrier-to-noise ratio, and is a function of the user's Geometry.

Contents

Geometry 5-79

Sector Throughput 5-80

RF Coverage and Capacity Forward Link CapacityOverview

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

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

5-78 401-614-323Issue 16 October 2009

Page 389: 1xev-Do Rf Engineering

Geometry

Description

Geometry, in this case, refers to the AT geographical position with reference to its serving

base station and neighboring base stations, and is defined as the received power of the

serving cell divided by the total of thermal noise and received interfering power. The

closer the AT is to the serving cell, the higher is the received signal from the serving cell,

and most likely, the higher the signal-to-noise and interference ratio experienced by the

AT. In this case, the AT is referred to as having high Geometry and will receive data at a

high data rate. An AT at a considerable distance from the base station, experiencing a high

level of noise and interference from neighboring base station, will have low Geometry.

More likely scenario

The more likely scenario at any sector coverage area is that certain ATs will be at high

Geometries and others at low Geometries. The scheduling algorithm in the network takes

advantage of multi-user Geometry diversity by serving users experiencing favorable RF

conditions and delaying data transmission to users in unfavorable conditions. The latter

are served when their conditions improve. This approach maximizes overall sector

throughput. This feature enables 1x-EV-DO to achieve significantly higher spectral

efficiency than is possible for voice and other real-time services.

RF Coverage and Capacity Forward Link CapacityGeometry

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

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

401-614-323Issue 16 October 2009

5-79

Page 390: 1xev-Do Rf Engineering

Sector Throughput

Introduction

The dependence on user Geometry makes an analytical approach to determining forward

link capacity difficult. Simulations have been run to predict estimated forward capacity in

terms of per sector throughput.

The simulations require the following inputs:

• Geometry distribution: The probability distribution function that a given user has a

given Geometry determined by simulating typical hexagonal layout with all cells at

full power and sampling all locations for Geometry

• Channel profile: Mix of channel types, e.g., AWG�, 1-path Rayleigh, 2-path

Rayleigh, etc.

• Mix of mobile speeds

• Model of predictor in mobile that takes S�R measurement inputs and generates DRC

value (desired forward link channel rate)

• Proportional Fair Scheduler Algorithm.

Aggregated Sector Throughput

A typical set of simulation results is shown in Figure 5-29, “Aggregated Sector

Throughput” (p. 5-81).

RF Coverage and Capacity Forward Link CapacitySector Throughput

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

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

5-80 401-614-323Issue 16 October 2009

Page 391: 1xev-Do Rf Engineering

Throughput

As can be seen from Figure 5-29, “Aggregated Sector Throughput” (p. 5-81), the

throughput increases with the number of users, leveling off at around eight users. This

increase in users is a direct manifestation of the scheduling gain discussed earlier. As the

scheduler has more users to choose from, a greater probability exists that one or more of

the users will be in a good Geometry and capable of supporting high channel rates.

�ote that the simulation does not include a traffic model, and assumes that users have an

infinite queue of data waiting for them. Inclusion of a real traffic model will reduce the

predicted throughput.

Summary

Based on simulations done to date, the recommended throughput capacity for planning

purposes for a 1xEV-DO system is in the range from 500-650 kilobits per second.

Figure 5-29 Aggregated Sector Throughput

RF Coverage and Capacity Forward Link CapacitySector Throughput

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

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

401-614-323Issue 16 October 2009

5-81

Page 392: 1xev-Do Rf Engineering
Page 393: 1xev-Do Rf Engineering

6 6Frequency Assignment

Overview

Purpose

This chapter describes wireless frequency assignments for overlay and standalone

deployment and the RF characteristics of the 1xEV-DO carrier waveform.

Contents

Deployment 6-2

Frequency Assignment 6-3

Cellular Band 6-5

PCS Band 6-10

Guard Band 6-11

Carrier Spacing 6-13

Dual Band Carriers 6-15

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

401-614-323Issue 16 October 2009

6-1

Page 394: 1xev-Do Rf Engineering

Deployment

Introduction

The 1xEV-DO may be deployed as a stand-alone base station serving high speed data

users, or may be co-located with an IS-95 and/or IS-2000 3G-1X to include voice.

Because 1xEV-DO user the same carriers assignment and guard bands as IS-95 and

IS-2000 3G-1X, collocation of the mixed technology base stations is straightforward.

Even though the coverage footprint of a 1xEV-DO base station is a function of the data

rate offer, the 1xEV-DO system can be engineered to be overlaid on an IS-95 or 3G-1X in

a 1:1 fashion. If collocated with IS-95 systems in a 1:1 fashion, the obvious trade-off is

that the 1xEV-DO may not be achieved at the outer edges of the coverage area.

Overlay Designs

The typical 1xEV-DO deployment scenario is an overlay onto an existing IS-95 or

IS-2000 network. In the overlay case, the footprint of the existing network being overlaid

determines the footprint of the 1xEV-DO carriers. Both reverse and forward data rates at

the cell edge can be determined from the link budget analysis. If traffic maps and

information on the subscriber traffic patterns are available (such as the number of sessions

during the busy hour, average number of data downloaded per session and average

download size, etc.) conclusions on the throughput per subscriber may be reached based

on the sector capacity. Alternatively, if the throughput per subscriber is specified, then one

can draw conclusions about total number of subscribers that can be served.

Standalone Designs

As for all cellular network systems, cost containment dictates that the number of base

stations deployed is held to a minimum. For the most part, the distribution of base stations

and the distance between them is determined through link budget analysis. In voice

systems, the information rate (vocoder data rate), which is a link budget component, is

fixed to provide a level of voice quality at the cell edge. In 1xEV-DO, a trade-off exists

between the data rate and coverage area. The information rate entered on the reverse link

budget spreadsheet (refer to “Information Rate (10logRb), Item k” (p. 5-19) ) determines

the cell coverage radius. Therefore, the design of any greenfield network would start by

determining the data rate to be achieved at the cell edge for both reverse and forward

links. After the cell edge data rate is determined, the reverse and forward link budget

spreadsheets are prepared to determine the maximum allowable path loss that can be

support for the desired data rate. The smaller value is the limiting link and determines the

cell footprint.

Frequency Assignment Deployment

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

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

6-2 401-614-323Issue 16 October 2009

Page 395: 1xev-Do Rf Engineering

Frequency Assignment

Frequency Bands

Carrier assignments and guard bands are the same as for IS-95 and IS-2000. The

recommendations for carrier assignments are provided for two band classes:

• Band Class 0 (cellular band, 850MHz)

• Band Class 1 (PCS band, 1900MHz).

Band Class 0 (Cellular Band, 850MHz)

This section on the cellular band addresses frequency assignment considerations in

dual-mode systems. Dual-mode systems refer to the air link technology that supports

IS-95, 3G-1X, 1xEV-DO, and Advance Mobile Phone System (AMPS). Support for

dual-mode systems allows voice CDMA providers to service visitors entering its coverage

area with either analog or TDMAmobiles. When TDMA service is not available, visitor's

TDMAmobiles will switch to AMPS service. �ot only does AMPS service within a

CDMA service provider's spectrum require channel allocation to carry voice traffic, a

prescribed dedicated band of channels must be allocated as analog access (setup)

channels. In dual-mode systems, the mandated analog access channels present limitations

on CDMA carriers frequency assignment.

Carrier Waveform

The 1xEV-DO carrier waveform conforms to the IS-95 requirements as shown in Figure

6-1, “Cellular Carrier Waveform Centered on Channel 283 at 878.49 MHz” (p. 6-4). The

IS-95 specification requires that the base station 3 dB bandwidth is 1.23 MHz, where the

maximum noise floor is 45 dB below the mean output power level ±750 kHz from the

center frequency. The mean output power reference is calculated from the measured

power spectral density in a 30 kHz bandwidth at the center of the CDMA channel. To

correct for the measuring bandwidth to get the total mean output power, multiply the

measured power in the 30 kHz band by the bandwidth ratio (1230 kHz/30 kHz), or 10 X

log 10 (1230/30) = 16 dB. The 0 dB reference accounts for this 16 dB bandwidth

correction; therefore, the vertical scale shows signal levels referenced to the mean output

power. The requirement is shown as the dashed line overlay on the spectrum.

Frequency Assignment Frequency Assignment

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

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

401-614-323Issue 16 October 2009

6-3

Page 396: 1xev-Do Rf Engineering

Figure 6-1 Cellular Carrier Waveform Centered on Channel 283 at 878.49 MHz

0

-10.0

-20.0

-30.0

-40.0

-50.0

-60.0

-70.0

-80.0

876.99 877.99 878.99 879.99 880.99 881.99

3 dB Bandwidth

45 dB

878.49

}

Frequency Assignment Frequency Assignment

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

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

6-4 401-614-323Issue 16 October 2009

Page 397: 1xev-Do Rf Engineering

Cellular Band

Description

To promote cellular competition within each geographic area, the FCC divides the

frequency spectrum allocated for cellular transmission into two radio frequency bands

designated as A-band and B-band. The A-band and B-band frequencies are distributed

over the frequency spectrum as shown in Figure 6-2, “Distribution of Cellular Frequency

Bands” (p. 6-6). One band is assigned to the radio common carrier and the other to the

regional wireline carrier. The blocks that are identified as A' and A'' in the A-band and B'

in the B-band are the results of additional 10-MHz blocks of frequencies which are

allocated to each carrier. The A- and B- bands are further subdivided into transmit and

receive frequencies.

The total frequency spectrum allocated for cellular communications consists of 832

duplex channels. A duplex channel consists of two 30-MHz AMPS voice channels. One is

for cell frequency modulation (FM) transmission to the AMPS mobile, which is referred

to as forward link (downlink) transmission, and the other for AMPS mobile FM

transmission to the cell, which is referred to as reverse link (uplink) transmission.

Therefore, each band is assigned 416 duplex channels to transmit and receive voice traffic

signals.

Distribution of Cellular Frequency Bands

The duplex traffic channels are numbered from 1 through 799, and then from 991 through

1023. The channel number gap between channels 799 and 990 accommodates the

frequency bands allocated for air-to-ground telephony and for specialized mobile radio

which are shown as shaded areas in Figure 6-2, “Distribution of Cellular Frequency

Bands” (p. 6-6). The number of channels in each A- and B- block of frequency, their

bandwidths, boundary channel numbers, and the cell and subscriber transmit center

frequencies of each boundary channel are given in Table 6-1, “AMPS and CDMA

Channel �umbers and Corresponding Frequencies For Band Class 0” (p. 6-7).

Frequency Assignment Cellular Band

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

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

401-614-323Issue 16 October 2009

6-5

Page 398: 1xev-Do Rf Engineering

Channel boundaries

Because each transmit channel bandwidth is 30 kHZ or 0.03 MHz, the center frequency

of the subscriber or cell transmit or receive channel is calculated by multiplying its

channel number (�) by 0.03MHz. The product is then added to the starting frequency of

the band. The channel upper and lower boundary frequency is calculated by adding (for

upper boundary) or subtracting (for lower boundary) 0.015MHz from the center

frequency. The starting frequency of the band used by a cellular subscriber and the cell

site frequencies is a function of the channel number. To calculate the subscriber channel

center frequency for a given channel number, use the following:

When the channel number = 1≤�≤799, F = 0.03 � + 825.000 When the channel number

= 990≤�≤1023, F = 0.03 (�-1023) + 825.000

To calculate the base station channel frequency for a given channel number, use the

following:

Figure 6-2 Distribution of Cellular Frequency Bands

824

825

835 845

846.5

849

851

856 869

870

880 890

891.5

894

896

901MHz

Reverse Link

Air-to-Ground

Specialized Mobile

Air-to-Ground

Specialized MobileRadio Rx

A BA” A’ B’

Forward Link

A’ B’A” BA

RxTelephony Tx Telephony

Radio Tx

Frequency Assignment Cellular Band

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

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

6-6 401-614-323Issue 16 October 2009

Page 399: 1xev-Do Rf Engineering

AMPS and CDMA Channel Numbers and Corresponding Frequencies For Band Class 0

When the channel number = 1≤�≤799,F = 0.03 � + 870.000 When the channel number =

990≤�≤1023, F = 0.03 (�-1023) + 870.00

Table 6-1 AMPS and CDMA Channel Numbers and Corresponding Frequencies For

Band Class 0

System

Designator

CDMA

Channel

Validity

Number

of Analog

Channels

AMPS/

CDMA

Channel

Number

Transmitter Frequency

Assignment (MHz)

Access

Terminal

Access

Network

A'' (1 MHz) �ot Valid 22 991-1012 824.040-824.670 869.040-869.670

Valid 11 1013-1023 824.700-825.000 869.700-870.000

A (10

MHz)

Valid 311 1-311 825.030-834.330 870.030-879.330

�ot Valid 22 312-333 834.360-834.990 879.360-879.990

B (10

MHz)

�ot Valid 22 334-355 835.020-835.650 880.020-880.650

Valid 289 356-644 835.680-844.320 880.680-889.320

�ot Valid 22 645-666 844.350-844.980 889.350-889.980

A' (1.5

MHz)

�ot Valid 22 667-688 845.010-845.640 890.010-890.640

Valid 6 689-694 845.670-845.820 890.670-890.820

�ot Valid 22 695-716 845.850-846.480 890.850-891.480

B' (2.5

MHz)

�ot Valid 22 717-738 846.510-847.140 891.510-892.140

Valid 39 739-777 847.170-848.310 892.170-893.310

�ot Valid 22 778-799 848.340-848.970 893.340-893.970

The 22-channel groups that are identified as �ot Valid are dedicated to AMPS setup

channels in a dual-mode environment. The CDMA 1.23-MHz carrier bandwidth occupies

41 AMPS channels (41 x 0.03 MHz). The assignment of valid CDMA channels must take

into account practical considerations such as guard-band needs and/or the channel needs

for AMPS in dual-mode systems.

Need for guard bands

Because of the need for guard bands and/or AMPS channels in dual-mode systems,

ideally all the channel allocation to either CDMA or AMPS should be contiguous. This

ideal situation may not always be achieved; however, effort should be taken to achieve

this goal as much as possible. By using contiguous channels/bands for CDMA and

AMPS, a single guard band is required for the overall spectrum. For example, if an

A-Band, dual mode, CDMA application required two CDMA channels, a good first

CDMA channel selection would be channel 283. In the case of a dual mode

Frequency Assignment Cellular Band

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

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

401-614-323Issue 16 October 2009

6-7

Page 400: 1xev-Do Rf Engineering

(AMPS/CDMA) system, this is the highest available channel in the 10 MHz A-Band that

could be selected without concern for interference in A-Band AMPS setup channels 313

through 333. This channel selection already provides a 0.27 MHz guard band of channels

between the nominal 1.23 MHz CDMA channel band and the AMPS setup channels

(313-333) required for the A-Band service provider.

Channel separation

The logical choice for the second CDMA carrier channel would be channel 242, which is

41 channels away from 283 for a carrier frequency separation of 1.23 MHz. Any selection

resulting in a carrier frequency separation of less than 41 channels would result in the two

CDMA carriers being separated by less than the nominal 1.23 MHz CDMA channel

bandwidth, and would cause excessive interference between the two carriers. Using a

separation of greater than 41 channels results in inefficient use of the spectrum.

Guard band recommendations

Alcatel-Lucent recommends that for 1xEV-DO and AMPS operating in the same cellular

band (A- or B-Band), a guard band of 270 kHz be implemented on both sides of the

consecutive 1xEV-DO carriers. A guard band is not required between the two 1xEV-DO

carriers. Table 6-2, “Recommended A-Band CDMACenter Frequency Assignments”

(p. 6-8) and Table 6-3, “Recommended B-Band CDMACenter Frequency Assignments”

(p. 6-9) show frequency assignments for dual-mode AMPS and CDMA operations in the

A- and B-Band spectrums. These assignments are given for up to eight 1.23-MHz CDMA

channels. The remaining channels and channel numbers that are available for AMPS

coverage are also listed.

Table 6-2 Recommended A-Band CDMA Center Frequency Assignments

Number of

CDMA

Channels

CDMA Center Frequency

Assignments

Number

of AMPS

Channels

AMPS Channel

Assignments

1 283 3561-252, 313-333, 667-716,

991-1023

2 242, 283 3151-211, 313-333, 667-716,

991-1023

3 201, 242, 283 2741-170, 313-333, 667-716,

991-1023

4 160, 201, 242, 283 2331-129, 313-333, 667-716,

991-1023

5 119, 160, 210, 242, 283 1921-88, 313-333, 667-716,

991-1023

Frequency Assignment Cellular Band

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

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

6-8 401-614-323Issue 16 October 2009

Page 401: 1xev-Do Rf Engineering

Table 6-2 Recommended A-Band CDMA Center Frequency Assignments

(continued)

Number of

CDMA

Channels

CDMA Center Frequency

Assignments

Number

of AMPS

Channels

AMPS Channel

Assignments

6 78, 119, 160, 201, 242, 283 1511-47, 313-333, 667-716,

991-1023

7 37, 78, 119, 160, 201, 242, 283 1101-6, 313-333, 667-716,

991-1023

8691, 37, 78, 119, 160, 201, 242,

28360 1-6, 313-333, 991-1023

Recommended B-Band CDMA Center Frequency Assignments

Table 6-3 Recommended B-Band CDMA Center Frequency Assignments

Number of

CDMA

Channels

CDMA Center Frequency

Assignments

Number

of AMPS

Channels

AMPS Channel

Assignments

1 384 356334-354, 415-666,

717-799

2 384, 425 315334-354, 456-666,

717-799

3 384, 425, 466 274334-354, 497-666,

717-999

4 384, 425, 466, 507 233334-354, 538-666,

717-999

5 384, 425, 466, 507, 548 192334-354, 579-666,

717-799

6 384, 425, 466, 507, 548, 589 151334-354, 620-666,

717-799

7384, 425, 466, 507, 548, 589,

630110

334-354, 661-666,

717-799

8384, 425, 466, 507, 548, 589,

630, 77757

334-354, 661-666,

717-746

Frequency Assignment Cellular Band

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

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

401-614-323Issue 16 October 2009

6-9

Page 402: 1xev-Do Rf Engineering

PCS Band

Description

The Personal Communication System (PCS) 1900 MHz spectrum is divided into six

bands. A, B, and C bands are each 15 MHz wide, and D, E, and F bands are each 5 MHz.

Each band is divided into channels that are 50 kHz wide. CDMARF frequency carriers

are spaced 25 channels, or 1.25 MHz apart.

Although the 60-MHz forward and reverse link PCS spectrum (Figure 6-3, “Distribution

of the Personnel Communication System (PCS) Spectrum” (p. 6-10)) implies the

availability of 1200 CDMA carriers, not all 1200 are actually usable. Table 6-4,

“1xEV-DO Channel Allocation Availability For Band Class 1” (p. 6-11) indicates the

availability of the channels by classifying them as valid (usable) channels, conditionally

valid, or not valid.

Distribution of the Personnel Communication System (PCS) Spectrum

Figure 6-3 Distribution of the Personnel Communication System (PCS) Spectrum

AA DD BB EE FF CC

19301850 19451865 19501870 16501885 19701890 19751895 1990 Mhz1910

80MHz

60MHz

15MHz 15MHz15MHz 15MHz15MHz 15MHz5MHz 5MHz5MHz 5MHz5MHz 5MHz

Reverse LinkForward Link

Frequency Assignment PCS Band

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

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

6-10 401-614-323Issue 16 October 2009

Page 403: 1xev-Do Rf Engineering

Guard Band

Description

The first 25 channels in Band A (channels 0-24) and the last 24 channels in the E band

(channels1176-1199) represent the border channels of the PCS 60-MHz reverse and

forward spectrums and are designated �ot Valid to eliminate the possibility of

interference between PCS systems and the services allocated to the spectrum above and

below the reverse and forward spectrums. The channels designated Conditionally Valid

are valid only under the condition that the service provider also owns the adjacent block

of spectrum. These channels are provisioned conditionally to eliminate the possibility of

interference between to competing PCS service providers.

Therefore, except for the 25 lowest highest channels in each block, all channels within the

block are valid for CDMA carriers, providing 51 unconditionally available channels in

Blocks D, E, and F, and 251 unconditionally available channels in Blocks A,B, and C. If a

service provider owns a license for adjacent blocks, the channels between the block,

designated Conditionally Valid, can also be used as part of the CDMA carrier.

1xEV-DO Channel Allocation Availability For Band Class 1

Table 6-4 1xEV-DO Channel Allocation Availability For Band Class 1

Block

Designator

CDMA Channel

Validity

CDMA Channel

Number

Transmit Frequency Band (MHz)

Access Terminal Access

Network

A

(15 MHz)

�ot Valid 0-24 1850.000-

1851.200

1930.000-

1931.200

Valid 25-275 1851.250-

1863.750

1931.250-

1943.750

Conditionally

Valid

276-299 1863.800-

1864.950

1943.800-

1944.950

D

(5 MHz)

Conditionally

Valid

300-324 1865.000-

1866.200

1945.000-

1946.200

Valid 325-375 1866.250-

1868.750

1945.600-

1948.750

Conditionally

Valid

376-399 1868.800-

1869.950

1948.800-

1949.950

Frequency Assignment Guard Band

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

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

401-614-323Issue 16 October 2009

6-11

Page 404: 1xev-Do Rf Engineering

Table 6-4 1xEV-DO Channel Allocation Availability For Band Class 1 (continued)

Block

Designator

CDMA Channel

Validity

CDMA Channel

Number

Transmit Frequency Band (MHz)

Access Terminal Access

Network

B

(15 MHz)

Conditionally

Valid

400-424 1870.000-

1871.200

1950.000-

1951.200

Valid 425-675 1871.250-

1883.750

1951.250-

1963.750

Conditionally

Valid

676-699 1883.800-

1884.950

1963.800-

1964.950

E

(5 MHz)

Conditionally

Valid

700-724 1885.000-

1886.200

1965.000-

1966.200

Valid 725-775 1886.250-

1888.750

1966.250-

1968.750

Conditionally

Valid

776-799 1888.800-

1889.950

1968.800-

1969.950

F

(5 MHz)

Conditionally

Valid

800-824 1890.000-

1891.200

1970.000-

1971.200

Valid 825-875 1891.250-

1893.750

1971.250-

1973.750

Conditionally

Valid

876-899 1893.800-

1894.950

1973.800-

1974.950

C

(15 MHz)

Conditionally

Valid

900-924 1895.000-

1896.200

1975.000-

1976.200

Valid 925-1175 1896.250-

1908.750

1976.250-

1988.750

�ot Valid 1176-1199 1908.800-

1909.950

1988.800-

1989.950

Frequency Assignment Guard Band

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

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

6-12 401-614-323Issue 16 October 2009

Page 405: 1xev-Do Rf Engineering

Carrier Spacing

Description

�ot all of the valid and conditionally valid channels can be used simultaneously as

carriers in a given system. Once the first carrier in a system is selected, the minimum

carrier spacing rules should be observed. These rules limit how close a new carrier can be

above or below previously existing carriers. While the classification of channels as Valid

and Conditionally Valid is by FCC decree, the minimum spacing between active carriers

is determined by CDMA (1xEV-DO) technology considerations. Generally, the channels

are specified as dictated by the minimum carrier spacing of 25 CDMA channels, which is

consistent with the nominal 1.25 MHz bandwidth for CDMA, i.e., 1xEV-DO, 3G-1X, and

IS-95.

The selection of the frequencies might be dictated by issues handling inter-system or

inter-system interference. If these issues are not significant factors in the system

performance, the number of channels that the service provider might consider for carrier

frequencies can be reduced significantly to the list of preferred channels in Table 6-4,

“1xEV-DO Channel Allocation Availability For Band Class 1” (p. 6-11). These are the

channel numbers that a personal station will scan when looking for service. Thus, a

system must use at least one (or more) of these carriers at each site in the system if the

sites are to be capable of providing (CDMA) access to the system.

Preferred CDMA Channels For Band Class 1

Table 6-5 Preferred CDMA Channels For Band Class 1

Frequency Block Preferred Channel Numbers

A 25, 50, 75, 100, 125, 150, 175, 200, 225, 250, 275

D 325, 350, 375

B 425, 450, 475, 500, 525, 550, 575, 600, 625, 650, 675

E 725, 750, 775

F 825, 850, 875

C 925, 950, 975, 1000, 1025, 1050, 1075, 1100, 1125, 1150, 1175

A 25, 50, 75, 100, 125, 150, 175, 200, 225, 250, 275

Exclusions

Conditionally valid channels 300, 400, 700, 800, and 900 are excluded from Table 6-5,

“Preferred CDMAChannels For Band Class 1” (p. 6-13) because they can only be used if

the service provider has licenses for both the frequency block containing the channel and

the immediately adjacent frequency block (e.g., Channel 300 is a likely carrier channel if

Frequency Assignment Carrier Spacing

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

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

401-614-323Issue 16 October 2009

6-13

Page 406: 1xev-Do Rf Engineering

the service provider has licenses for both Blocks A and D).

Frequency Assignment Carrier Spacing

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

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

6-14 401-614-323Issue 16 October 2009

Page 407: 1xev-Do Rf Engineering

Dual Band Carriers

Carriers supported

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)

BTS's supported

Dual band can be provided in the same cell site with multiple BTS frames and each BTS

frame operates in either BC0 or BC1. The following BTS types are applicable:

• 9218 Macro, 9228 Macro

• 9216 Compact

• 9218 Macro HD, 9228 Macro HD

• Modcells 1, 2, and 3

In these configurations the following band class assignment is supported

– Modcell(s) 1, 2 or 3 supports BC0

– 9218 Macro (or 9228 Macro) supports BC1

Features supported

This feature supports the following features

• Load balance at call connection set up to handle the dual band cell configuration.

• Inter-frequency Hand Off (IFHO)

• Cross-band hashing, allowing the dual band ATs to hash to either band. With

cross-band hashing, the channel list information sent on the control channel includes

carriers of both band classes.

Set up

To set up a cell for dual band, different radio resources are assigned for BC0 and BC1.

The technician enters the band class of each 1xEVDO carrier at the GUI.

Assumptions

This feature works with the assumption that all ATs operating in the PCS and cellular

frequencies are dual band ATs. The result of cross-band hashing by a single-band AT is

undefined. Paging of single-band AT in a dual-band cell site therefore will not work

reliably.

Frequency Assignment Dual Band Carriers

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

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

401-614-323Issue 16 October 2009

6-15

Page 408: 1xev-Do Rf Engineering
Page 409: 1xev-Do Rf Engineering

7 7Call Processing

Overview

Purpose

This chapter describes call processing, which is concerned with the establishment and

maintenance of airlink channels between the AT and RA�. Most of call processing

operation is governed by a set of protocols at the Connection Layer of the TIA-856-A

protocol stack. Protocols within this layer control the AT' operating states from the time

the AT is powered on. This chapter discusses the AT operating states from the

Initialization State (when powered up), through the Idle State, to the Connection State

(when a traffic channel is assigned to a call). In addition, this chapter describes call

handoff, base station transmit power control, and overload control.

Contents

Initiating a call 7-4

1xEV-DO Call Processing Overview 7-5

Air Link Management Protocol 7-7

Access Probe Structure 7-10

Initialization State 7-13

Idle State 7-15

Authentication 7-18

Idle Mode Sub-States 7-20

Monitor Sub-State 7-22

Default Sleep Sub-State 7-24

Rev A Enhanced Idle State Protocol 7-26

Page mask 7-28

Idle State Pilot Channel Supervision 7-30

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-1

Page 410: 1xev-Do Rf Engineering

Connection setup 7-34

Fast Connect Setup 7-37

Configuration �egotiation to Open a Session 7-39

Configuration �egotiation Procedure 7-41

PPP Connection 7-43

Session Maintenance 7-45

Messages during inactivity 7-47

Paging 7-49

Paging types 7-50

Terms used with paging 7-51

EVDO paging considerations 7-53

Default paging with neither QoS or DOS 7-55

QoS paging for Profile IDs 7-56

1xEV-DO Basic PTT using 1xEV-DO Rev A�etworks 7-58

1xEV-DO PTT Paging Enhancements 7-60

Parameters 7-62

Paging controls example 7-63

Distance based paging operation 7-65

Deriving Route Update Message distance 7-66

QoS paging with DOS 7-68

Resource allocation 7-70

Traffic Channel Resource Allocation 7-71

RTC Parameters 7-72

Indices and P� offset 7-73

RAB Offset/RAB Length 7-74

Handoff introduction 7-76

Pilot Sets 7-77

Pilot Drop Timer Maintenance 7-78

Active Set Management 7-81

Candidate Set Management 7-85

�eighbor Set Management 7-86

Virtual Soft Handoff 7-89

Support forMultiple 1xEV-DO Carriers - IFHO, FID 8219.11 7-91

Call Processing Overview

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-2 401-614-323Issue 16 October 2009

Page 411: 1xev-Do Rf Engineering

Other handoffs 7-97

1xEV-DO Distance Based Handoff (FID 13579.0) 7-99

BroadCast andMultiCast Service (BCMCS) 7-102

Power control 7-107

Rev 0 Power control 7-108

Rev 0 Overload control 7-111

Rev A power and overload control 7-114

Leaky bucket control mechanism 7-117

RAB bit load control and RoT 7-120

Call Processing Overview

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-3

Page 412: 1xev-Do Rf Engineering

Initiating a call

Overview

Purpose

This section discusses the parameters and processes involved in initiating a call.

Contents

1xEV-DO Call Processing Overview 7-5

Air Link Management Protocol 7-7

Access Probe Structure 7-10

Initialization State 7-13

Idle State 7-15

Authentication 7-18

Idle Mode Sub-States 7-20

Monitor Sub-State 7-22

Default Sleep Sub-State 7-24

Rev A Enhanced Idle State Protocol 7-26

Page mask 7-28

Idle State Pilot Channel Supervision 7-30

Connection setup 7-34

Fast Connect Setup 7-37

Configuration �egotiation to Open a Session 7-39

Configuration �egotiation Procedure 7-41

PPP Connection 7-43

Session Maintenance 7-45

Messages during inactivity 7-47

Call Processing Initiating a callOverview

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-4 401-614-323Issue 16 October 2009

Page 413: 1xev-Do Rf Engineering

1xEV-DO Call Processing Overview

Introduction

A significant part of call processing, which is concerned with the establishment and

maintenance of airlink channels between the AT and RA�, is governed by the connection

layer of the TIA-856A Protocol Architecture (refer to Figure 2-4, “AT Protocol Stacks

Interface” (p. 2-18)). The set of protocols in this layer is shown in Figure 7-1,

“Connection Layer of 1xEV-DO TIA-856-A Protocol Architecture” (p. 7-5). The

unshaded protocols are use in both Rev 0 and Rev A and are referred to as the default

connection layer protocols. The shaded Enhance Idle State Protocol is used only in Rev A

Call processing is performed by the software modules that provide the necessary

functions to enable the AT to access and receive service from the Evolution Controller

(EVC) in the RA� network. The functions that these services include overhead message

processing, signaling messaging transmission/receiving processing, allocating/de-

allocating of airlink resources for a particular AT, setting up the R-P connections to the

PDS�, etc.

Connection Layer Protocol

The 1xEV-DO operation, as defined by the connection layer protocol set, is divided into

four states; each identifies the mode that an AT may enter from the time the AT is

switched on. The relationship of the connection layer protocols is shown in Figure 7-2,

“1xEV-DO Operation” (p. 7-6). Except for the Overhead Message protocol, which is

performed exclusively by the RA�, incidence of protocols are performed in both the AT

and RA� network. The protocols share data with each other in a controlled fashion, and

the arrows indicate activation command data flow.

Figure 7-1 Connection Layer of 1xEV-DO TIA-856-A Protocol Architecture

Air LinkManagement

Protocol

InitiationState Protocol

Idle StateProtocol

Enhanced IdleState

Protocol*

ConnectedState Protocol

PacketConsolidation

Protocol

Route UpdateProtocol

OverheadMessageProtocol

Connection Layer

* used in Rev A only

Call Processing Initiating a call1xEV-DO Call Processing Overview

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-5

Page 414: 1xev-Do Rf Engineering

The AT and the RA� network maintain either a closed or open connection state that

dictates the type of communications between the two.

• Closed Connection: In this connection state, the AT is not assigned to a dedicated

airlink resource. Communications between the AT and the RA� network are

conducted over the access channel and control channel.

• Open Connection: In this connection state, the AT can be assigned the forward traffic

channel, and is assigned a reverse power control channel and a reverse traffic channel.

Communications between the AT and RA� network are conducted over these

assigned channels, as well as over the control channel.

Figure 7-2 1xEV-DO Operation

Air Link ManagementProtocol

Initialization StateProtocol

Idle State Protocol/Enhanced Idle State

Protocol

Connection StateProtocol

Route UpdateProtocol

Overhead MessageProtocol

Call Processing Initiating a call1xEV-DO Call Processing Overview

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-6 401-614-323Issue 16 October 2009

Page 415: 1xev-Do Rf Engineering

Air Link Management Protocol

Introduction

The Air Link Management protocol in the connection layer maintains the overall

connection state control in the access terminal and RA� network. The protocol can be in

one of three states, corresponding to whether the access terminal has yet to acquire the

network. The states are:

• Initialization State -Maintained by the Initialization State protocol, enabling the AT to

acquire the RA� network

• Idle State - Maintained by the Idle State protocol after the AT has acquired the RA�

network. In this state, the AT is not assigned any dedicated airlink resources.

Communications between the AT and the RA� network are conducted over the

reverse access channel and the forward control channel in a closed connection. A

closed connection is referred to in the TIA-856-A specification to indicate that the

traffic data connection is closed off.

• Connected State - Maintained by the Connection State protocol to manage the radio

link between the AT and the RA� network in an open connection. An open

connection is referred to in the TIA-856A specification when the AT is (or can be)

assigned a forward traffic channel, RPC (Reverse Power Control) forward channel,

and a reverse traffic channel (refer to Figure 3-1, “1xEV-DO Channel Structure”

(p. 3-6)). Communications between the AT and the RA� network are conducted over

the assigned channels, as well as over the forward control channel.

Access Mode

In addition to connection state supervisory control, the Air Link Management protocol

controls initial AT to base station access. Initial access is required whenever the AT must

send data to the base station, and the distance between the AT and the closest base station

is indeterminate. If initial access is required, the access mode is entered, enabling the AT

to determine the minimum transmit power required to access the base station. This is done

to avoid the generation of unnecessary RF interference in the environment. To accomplish

this, the AT begins to transmit a sequence of access probes at increasing power levels

until a response is returned from the base station. The power level of the first access probe

transmit is a function of the strength of the signal received by the AT. If the receive signal

is strong, indicating that the base station is close by, the transmit power of the first access

probe would be much lower than if the receive signal was weak. When an acknowledge

response to the access probe is received, the AT uses the power level of the last

transmitted access probe, which is determined to be the minimum power level required

for the base station to receive discernible data from the AT to transmit subsequent

messages to the base station.

Call Processing Initiating a callAir Link Management Protocol

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-7

Page 416: 1xev-Do Rf Engineering

Generation and transmission of the access probes

The generation and transmission of the access probes are governed by the access

parameter and initial configuration attributes messages transmitted from the RA�

network. These messages, which in general are targeted to the Access Channel MAC

Protocol in the MAC layer, are comprised of a number of access translation parameters

entered on Service �odes/General section of the configuration data page. The generation

of these messages is handled by the overhead message protocol in the RA� network. A

portion of the parameters extracted from these messages to control the generation of the

access probe are identified and described in Table 7-1, “Access Probe Related Translation

Parameters” (p. 7-8).

Access Probe Related Translation Parameters

Table 7-1 Access Probe Related Translation Parameters

Parameter Range Default Description

Access Parameter message

Access Capsule Max

Length

2 to 15 frames 2 frames Identifies the maximum number of frames that

may be used for any message within the access

probe

Access Cycle Duration 0 to 255 time

slots

64 Indicates the duration of the access cycle in time

slot periods

Open Loop Power

Adjustment

0 to 255 dB 0 Used by the AT to estimate the initial access

probe transmit power

Initial Probe Power

Correction Factor

-16 to 15 db

in 0.5 dB

steps

0 Correction factor that adjusts the AT open loop

power estimate for initial access probe

transmission

Power Increment Step 0 to 15 dB in

0.5 dB steps

6 Indicates power increment between successive

probes

�umber of Access

Probes

1 to 15 5 Identifies the number of access probes to be

generated within access probe sequence

Access Preamble Length 1 to 7 frames 2 frames Indicates length of preamble portion of access

probe in number of frames

Initial Configuration Attribute message

Maximum �umber for an

Access Probe Sequence

1 to 15 3 Indicates the maximum number of probe

sequences permitted in a single access attempt

Access Channel Probe

Backoff

1 to 15 4 Backoff value used in an algorithm for

determining the time the AT waits for a probe

response during an access probe sequence

Call Processing Initiating a callAir Link Management Protocol

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-8 401-614-323Issue 16 October 2009

Page 417: 1xev-Do Rf Engineering

Table 7-1 Access Probe Related Translation Parameters (continued)

Parameter Range Default Description

Access Channel Probe

Sequence Backoff

1 to 15 8 Backoff value used in an algorithm for

determining the time the AT waits before

generating the net access probe sequence

Sector Parameter Message

Reverse Link Silence

Period

0 to 3 0 Indicates the duration of the reverse link silence

period where the parameter value, n, is

expressed in units of 64 pseudo noise (P�)

chips:1 = duration of 64 P� chips, 2 = duration

of 128 P� chips, 3 = duration of 192 P� chips

Reverse Link Silence

Duration

0 to 3 frames 0 Indicates the duration of the interval between

Reverse Link Silence Periods in which ATs

cannot transmit on the reverse link.

Persistent Test

The access probe sequence must begin at the start of the access cycle. To control

congestion on the access channel, a persistent test based on its AT class is performed by

all ATs petitioning system access before attempting to generate a probe sequence. This

test greatly reduces the odds that two or more ATs in the area will generate access probes

at the same time. Based on its AT class and a persistent vector extracted from the

overhead message, the AT computes a persistence value p. This value is then compared

with a uniformly distributed random number x, where 0 < x < 1. If p is greater, then the

persistent test is passed, and the AT may transmit a sequence of access probes. If the AT

fails to transmit an access probe sequence during unsuccessful persistent tests, the AT is

allowed to generate the access probe sequence after the number of consecutive persistent

tests exceeds 4/p.

Reverse Link Silence Period

To help obtain the reverse link noise floor at the base station, a reverse link silence period

periodically occurs in which all AT transmissions are halted. Therefore, the generation of

the access probes cannot overlap the reverse link silence period. This period is determined

by the AT from the Reverse Link Silence Period and Reverse Link Silence Duration

translation parameters received in the Sector Parameter overhead message. The latter

parameter defines the length of the silence period, and the former specifies the interval

between silence periods. This interval is equal to:

2048 2ReverseLinkSilencPeriod

× 1– Frames

Call Processing Initiating a callAir Link Management Protocol

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-9

Page 418: 1xev-Do Rf Engineering

Access Probe Structure

Description

The structure of the Rev 0 transmitted access probe is shown in Figure 7-3, “Access

Probe Structure” (p. 7-10)(refer to Figure 3-39 the Rev A access probe). The access probe

consists of a preamble followed by access data wrapped within access capsules, which are

Physical Layer-assembled packets (refer to “Generation of Access Channel” (p. 3-100)

and “Rev 0 Access Channel” (p. 3-99)). The access data portion of the probe may consist

of one or more access capsules, up to its maximum length specified by the Access

Capsule Max Length translation parameter. Because the Rev 0 access probe is transmitted

at a 9.6 Kbps data rate, a signal access capsule is transmitted during a 16-slot frame. The

reverse link pilot signal is transmitted at a high-power level during the preamble. During

the data portion of the access probe, the pilot signal power is reduced and the amplitude

of the data channel is in proportion to the pilot transmit amplitude so that the sum of the

data and pilot channel transmit power is equal to the pilot channel transmit output

transmitted during the preamble period.

Access Probe Structure diagram

Figure 7-3 Access Probe Structure

Preamble

(Preamble length x 16 slots)

Beginning of accesschannel cycle

Access Capsule

Access Probe Transmission Period

Access Cycle Duration Access Cycle Duration

Up to Access CapsuleMax Length x 16 slots

~ ~

Pilot

Pilot

Data

Transmit Power

Time

Call Processing Initiating a callAccess Probe Structure

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-10 401-614-323Issue 16 October 2009

Page 419: 1xev-Do Rf Engineering

Access Probe Sequence

A number of access probes, designated �p, are successively generated at increasing

transmit power levels during each access probe sequence, as shown in Figure 7-4,

“Access Probe Sequence” (p. 7-11) where �p is 4. The number of probes to be generated

within each sequence is expressed in the system translation database (�umber of Access

Probes) and is sent to the AT as part of the overhead message. After performing a

persistence test, the AT generates the first access probe of the sequence at a power level

based on an open-loop estimate using its mean receive power level in an algorithm using

the Open Loop Power Adjustment and the Initial Probe Power Correction Factor

parameter values extracted from the overhead messages. The power levels of subsequent

probes in the sequence is increased by the increment extracted from the Power Increment

Step parameter.

Inter-Probe Backoff

The time distance between successive probes in an access probe sequence, Tp , is

computed from the Access Channel Probe Backoff parameter extracted from the overhead

messages. The inter-probe backoff period must be long enough to allow the AT, if the

base station receives and recognizes the probe, to receive the base station

acknowledgment before the next probe is transmitted. In addition, to reduce the

probability of the access probes from two or more ATs in the area colliding, the Tp value

computed from the overhead broadcast Access Channel Probe Backoff parameter must be

different for each AT.

Figure 7-4 Access Probe Sequence

PersistenceTest

1 2 3 Np

Ts

Tp

PersistenceTest

1 2 3 Np

TpTp

PersistenceTest

1 2 3 Np

Tp

~ ~

Probe Sequence No, 1 2 Ns

PowerIncrement

Step

Call Processing Initiating a callAccess Probe Structure

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-11

Page 420: 1xev-Do Rf Engineering

The Access Channel Probe Backoff parameter value defines the largest Tp value

permitted. To compute a unique Tp value, the AT generates a pseudo-random number, y,

which is a uniformly distributed random integer between 0 and the Access Channel Probe

Backoff parameter value. To compute the value of Tp in time slot periods, the product of

the pseudo-random number, y, and the Access Cycle Duration parameter, are added to a

fixed probe time-out value, (Probetimeout ):

The Probetimeout is set to128 time slots by the TIA-856A specification to allow the base

station enough time to acknowledge the probe. If any portion of the access probe will

state before the end of the reverse link silence interval, y is added to a y total register that

is set to zero at the start of the access probe sequence, producing a new y value, and Tp is

recalculated. The next access probe is then transmitted to the recalculated Tp slots after

the previous probe.

Inter-Sequence Backoff

The interval between access probe sequences, Ts , is defined by the Access Channel

Probe Sequence Backoff parameter value. To compute the value of Ts in time slot

periods, the AT generates a pseudo-random number, k, which is a uniformly distributed

random integer between 0 and the Access Channel Probe Sequence Backoff value. The

value of Ts is equal to the product k and the Access Cycle Duration value, plus a fixed

sequence time-out value, (Sequencetimeout ), which is 128 time slots:

Tp y AccessCycleDuration×( ) Probe timeout+=

Ts k AccessCycleDuration×( ) Sequence timeout+=

Call Processing Initiating a callAccess Probe Structure

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-12 401-614-323Issue 16 October 2009

Page 421: 1xev-Do Rf Engineering

Initialization State

Introduction

In this mode, the AT registers on the RA� to identify its presence and location within the

RA� network. In response to registering, the AT is assigned a unique address allowing

the RA� to page and send messages to the AT.

Initialization state activation

The AT will enter the initialization state, which is controlled by the initialization protocol.

In this state, the AT, which has no information about the serving base station or RA�

network, must acquire the RA� network and synchronize with its timing. The

initialization state is activated by the air link management protocol after the AT is

switched on or, the AT user attempts to open or return to a session after a long pause. In

either situation, the initialization state is activated to control how the AT acquires the

RA� network in its service area. To do this, the AT may select a forward CDMA channel

from a preferred channel record provided to the AT from the RA� network. In addition to

preferred channels, the channel record identifies the system (compliance specification)

and its band class. Immediately after the AT is activated, the AT enters a RA� network

determination mode as shown in Figure 7-5, “Initialization State Flow Diagram” (p. 7-14)

. At this time, the AT selects and tunes to one of the channels from its channel record and

attempts to acquire its forward link pilot signal. If the AT cannot acquire the pilot signal

within 60 seconds, the AT refers back to the channel record to identify another network.

Sync Message

When a pilot signal is acquired, the AT monitors the Sync Message broadcast on its

control channel. The Sync message will contain information about its serving base station

and RA�. One of the values read from the Sync message is the range of AT revisions

compatible with the base station, the base station sector pilot P� offset, and network

system timing. The RA� network sets the System Time field of the Sync message to 60

ms after the start of the Control Channel Cycle in which the SyncMessage is transmitted.

The System Time is specified in units of 26.66 ms. The Sync message transmission period

is 1.28 seconds. If the AT acquires the Sync message within 5 seconds, the AT will

advance to the idle state. If the AT version is not within the revision range specified by the

Sync message or the AT cannot synchronize to the control channel cycle within 5

seconds, the AT goes back to the RA� network determination mode for channel

reselection.

Call Processing Initiating a callInitialization State

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-13

Page 422: 1xev-Do Rf Engineering

Initialization State Flow Diagram

Figure 7-5 Initialization State Flow Diagram

AT Activated

RAN NetworkDetermination

Can ATacquire pilot

?

Can ATsynchronize to control

channel cycle?

Go toIdle State

Initialization State

No

No

Yes

Yes

Yes

Read synch message andsynchronize to control

channel cycle

IsAT revision out of

range?

No

Call Processing Initiating a callInitialization State

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-14 401-614-323Issue 16 October 2009

Page 423: 1xev-Do Rf Engineering

Idle State

Introduction

The AT will enter the idle state, which is controlled by the idle state protocol, after the

RA� network is acquired. At this time, an open connection exists, where the AT is not

assigned to a dedicated airlink resource. Communications between the AT and RA�

network are conducted over the access channel and control channel. In order for the RA�

network to identify each AT that enters its coverage area, the AT must register when it

enters the coverage area.

Registration and Location Report

Unlike IS-95 and 3G-1X, no central database exists, such as a home location register

(HLR) and visitor location register (VLR) in the 1xEV-DO system as in traditional

wireless voice systems, to keep track of each AT location. To keep track of the AT and to

know where to page it, 1xEV-DO uses registration. Two possible registration procedures

are as shown:

• UATIRequestMessage-based

• RouteUpdateMessage-based.

Process description

In both messages, which are handled by the route update protocol, the AT sends its

location information to the base station so that the RA� network may focus its paging of

the AT to the correct coverage area. Rather than using serial number paging as in voice

wireless systems, each AT is assigned a unicast AT identifier (UATI) address. This address

is similar to the IP address that is assigned to data packets to steer the packet as it makes

its way from source to destination over the Internet.To obtain an UATI assignment, the AT

transmits an UATIRequest Message over the reverse access channel (refer to Figure 7-6,

“UATIRequest Message” (p. 7-16)). This message will be sent when the AT first registers

after the initialization state.

Call Processing Initiating a callIdle State

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-15

Page 424: 1xev-Do Rf Engineering

UATIRequest Message

The AT must include its UATI address within the UATIRequest message to allow the

RA� to direct (address) its page to the AT. As a result, the RA� returns an access

acknowledge (AcAck) response. When the UATIRequest message is sent for the first

time after the initialization state, the AT is not assigned any identification address. To

provide an address, the AT picks a RandomAccess Terminal Identifier (RATI) and

includes the RATI in its UATIRequest message in place of the UATI. The RA�

recognizes the RATI and will assign a UATI value which the AT will use throughout its

stay within the subnet. The assignment of a UATI value is handled by the address

management protocol in the TIA-856A session layer. The UATI is a 128-bit address value

divided into two fields: UATI104 and UATI024. The 104 most significant bits (MSB) of

the UATI, which make the UATI104 field, provide data steering within the RA� network

between the PDS� and the base station sector, where the eight least significant bits (LSB)

of the UATI104 field are the base station sector codes. The UATI104 value is sent to the

AT in the SectorParameterMessage on the control channel. The least significant

UATI024 field is sent to the AT in the UATIAssignment message.

When an UATI value is included in the UATIRequest message, the RA� would know

that the AT had registered in another subnet and is registering its location in its current

subnet. This reregistration is referred to as Inter-Subnet Idle Transfer. Inter- Subnet Idle

Transfer is also known as Inter-PCF Idle Handoff.

RouteUpdate Message

In the idle state, the AT sends a RouteUpdate message to the RA� when the AT moves

into a different subnet. A subnet is a definable coverage area controlled through a single

Evolution Controller (EVC) within a Flexent®Mobility Server (FMS). The current subnet

Figure 7-6 UATIRequest Message

Route Update or UATI Request (RATI)

AcAck

UATI Assignment

UATI Complete

AT RAN

Call Processing Initiating a callIdle State

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-16 401-614-323Issue 16 October 2009

Page 425: 1xev-Do Rf Engineering

servicing an AT is identified by its Color Code sent over the Control Channel. The

RouteUpdate message is also sent when the AT computes that its distance (radius, r)

from the base station it sent last RouteUpdate message is greater than the

RouteUdateRadius value in the SectorParameter message from that base station.

This radius r is computed as shown in Figure 7-7, “Equation 1” (p. 7-17).

Where, xC and xL are the longitude and latitude, respectively, of the sector that receive the

last RouteUpdate message from the AT, and yC and yL are the longitude and latitude,

respectively, of the sector currently providing coverage to the AT. The base station

locations are entered in the data base via the Sectors/Base Station Antenna

Longitude and Sectors/Base Station Antenna Latitude Instance Pages for each

base station. The RouteUpdate message is used when the AT is requesting a traffic

channel assignment (refer to “�ormal Setup” (p. 7-34)).

Figure 7-7 Equation 1

r

x xC L–( )π

180---------

yL

14400---------------×cos×

2

y yC L–[ ]2

+

16-----------------------------------------------------------------------------------------------------------------------=

)(

Call Processing Initiating a callIdle State

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-17

Page 426: 1xev-Do Rf Engineering

Authentication

Authentication Challenge

AT access to either the public or a private packet data switched network is password

protected and the AT user must be authenticated by AAA server based on the Remote

Authentication Dial-In User Service (RADIUS) protocol.

When the AT is ready to exchange data, a flow control protocol for the default packet

application bound to the RC� is in the open. Subsequently, the AT and the R�C initiate

Point-to-Point Protocol (PPP) and Link Control Protocol (LCP) negotiations for access

authentication (see Figure 7-8, “Authentication Challenge” (p. 7-18)).

Challenge Handshake Authentication Protocol

Authentication is performed using a Challenge Handshake Authentication Protocol

(CHAP) in which, the R�C sends a random challenge message to the AT. The CHAP is a

remote logon authentication protocol using challenge/response security mechanism

between a client and server. Rather than requiring the AT to transmit its user secret

password that may be revealed to an eavesdropper, the R�C generates a random message

to challenge the authenticity of the AT user. Using its password, the AT deciphers the

challenge and subsequently returns an appropriate response to the R�C. The encrypted

message is relayed to the AAA and is package with the challenge message and the uses

Figure 7-8 Authentication Challenge

AT RNC AAA Server

PPP and LPC Negotiation

CHAP Challenge

CHAP Response

A12 AccessAccept

A12 AccessRequest

CHAP Authentication Success

Via Base Station

Call Processing Initiating a callAuthentication

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-18 401-614-323Issue 16 October 2009

Page 427: 1xev-Do Rf Engineering

name in an A12-AccessRequest message. encrypted response to the R�C. The encrypted

message is relayed to the AAA and is package with the challenge message and the uses

name in an A12-AccessRequest message.

Finish the process

The AAA then looks up the user password to encrypt the challenge message and compare

its results with the encrypted response from the AT. If the two encrypted message match,

the AT is authenticated, and the AAA server send an A12-AccessAccept message. In

addition to accepting the AT's petition for access, this message identifies the AT by its

Mobile �ode Identification (M� ID), which may be the International Mobile Serial

Identifier (IMSI) extracted from the AAA database for the AT following successful access

authentication. The IMSI value is sent back to the AT in the CHAPAuthenticationSuccess

message. If the A12-AccessAccept message is not received access is terminated.

Call Processing Initiating a callAuthentication

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-19

Page 428: 1xev-Do Rf Engineering

Idle Mode Sub-States

Description

In the idle state, an open connection is established between the AT and RA�.Although, in

this mode, air resources are not allocated to the AT, the ATmonitors unicast paging as

well as broadcast messages from the RA� over the forward control channel, and will

periodically update its location via RouteUpdate messages in accordance with

predefined parameters within the RA� network.

The AT may be sequenced in one of three Idle State sub-modes, as shown in Figure 7-9,

“Idle Sub-States” (p. 7-20). The three sub-states are:

• Monitor Sub-State: In this state, the AT monitors the Control Channel, monitoring the

unicast messages from the RA�, such as page and overhead messages.

• Sleep Sub-State: The AT shuts down part of its subsystems to conserve power. The AT

does not monitor the Forward Channel, and the RA� is not allowed to transmit

unicast packets to the AT.

• Connection Setup Sub-State: The AT and the A� setup a connection.

Idle Sub-States

Figure 7-9 Idle Sub-StatesInitialization state

Monitor State

Connection SetupState

Sleep State

Call Processing Initiating a callIdle Mode Sub-States

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-20 401-614-323Issue 16 October 2009

Page 429: 1xev-Do Rf Engineering

AT and RAN network operating modes

To support the sub-states, the AT and RA� network can be operated in the following

modes:

• Continuous Operation: The AT continuously monitors the control channel.

• Suspended Mode Operation: This mode is entered after the AT monitors the control

channel in the continuously operation mode for a period of time and then proceeds to

operate in the slotted mode. Suspended mode operation allows for quick

network-initiated re-connection, or Fast Connect.

• Slotted Mode Operation (Sleep Sub-State): The AT monitors the control channel

during selected slots.

Call Processing Initiating a callIdle Mode Sub-States

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-21

Page 430: 1xev-Do Rf Engineering

Monitor Sub-State

Introduction

When in the monitor sub-state, the RA� communicates with each AT, which are also in

the monitor state, on the CDMA channel selected for monitoring by the AT. The RA� will

only page those carriers that the ATs are monitoring, preventing unnecessary paging on

the other carriers to save overall control channel capacity. The Page messages are unicast

over the control channel if a connection has to be opened. At this time, the AT responding

to the page will transition to the connection setup sub-state and will send a Connection

Request message. If it has a reasonable estimate of the AT current location, the RA�

may use fast connect accelerated procedures to set up a connection with an AT by

bypassing the paging process, and transition directly to the connection setup sub-state for

the AT.

AT Monitor Sub-State

In the monitor sub-state, the AT selects a CDMA channel from the list of channels in the

SectorParameters message. If no channels are listed, the AT uses the channel currently

monitored. If a new channel is selected (a channel other than the current channel being

monitor), the AT tunes to the new channel and begins to monitor the overhead messages

on the channel. If the AT requires a close connection or response to a Page, or a Traffic

Channel Assignment message without requesting such via a Connection Request

message (fast connect), the AT sends a ConnectionRequest message and transitions to

the connection setup state.

Forward Link Control Channel

In the monitor sub-state, the AT monitors both broadcast and AT-directed (unicast)

messages transmitted over the control channel at either a 76.8-kbps or 38.4-kbps data rate.

The modulation characteristics of control channel transmission are the same as those of

the forward traffic channel at the corresponding data rate (see Table 3-3, “Transmission

Format Code Rate and Transmission Type” (p. 3-19)). Transmission at the 76.8-kbps rate

is coded using a MAC index of 2, and transmission at the 38.4-kbps rate is coded using a

MAC index of 3. Alcatel-Lucent uses control channel transmission at the 76.8-kbps rate.

Control channel packets are transmitted in either synchronous capsules, which are

transmitted at a particular time slot to accommodate slotted mode operation or in

asynchronous capsules, which are transmitted at any time, except during a synchronous

capsule transmission.

Call Processing Initiating a callMonitor Sub-State

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-22 401-614-323Issue 16 October 2009

Page 431: 1xev-Do Rf Engineering

Examples of AT-directed messages

The AT-directed messages are sent in response to the requests generated by the AT, or to

generate a request from the AT. Examples of these messages are:

• UATIAssignment Message - Sent by the RA� in response to a RouteUpdate &ConnectionRequest (RATI) message from the AT requesting a UATI addressassignment

• TrafficChannelAssignment Message - Sent by the RA� in response to a

RouteUpdate & ConnectionRequest (UATI) message from the AT requesting atraffic channel.

Examples of broadcast messages

Broadcast messages are periodically sent to inform the ATs within the coverage area of

the system parameters, access parameters, configuration parameters, neighbor

information, etc. Examples of these messages are:

• QuickConfig Message – Informs the AT about certain important parameters, such as

the Color Code, and indication that the Forward Traffic Channel for a particular MAC

index is valid

• SyncMessage – Contains information about the serving base station and RA� such as

the range of AT revisions compatible with the base station, the base station sector pilot

P� offset, and network system timing

• SectorParameter Message – Provides neighbor information, list of available channels,

local time offset, latitude, longitude, etc.

• AccessParameters Message – Contains the parameters the AT uses to access the

system

• ReverseLinkRateLimit Message – Informs the AT of the highest rate that can be used

on the reverse link channel

• Redirect Message – Redirects the AT to another 1xEV-DO carrier or IS- 2000 System.

Call Processing Initiating a callMonitor Sub-State

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-23

Page 432: 1xev-Do Rf Engineering

Default Sleep Sub-State

Description

When the AT is in the sleep sub-state, it enters the slotted mode operation. In this mode of

operation, the AT may stop monitoring the control channel and shut down certain

processing resources to reduce power consumption, and thereby increase battery life. The

control channel, which is interlaced with the transmission of traffic data, is transmitted

every 425 ms for a 13.33-ms duration, as shown in Figure 3-12, “Control Channel

Timing” (p. 3-37). On the occurrence of every twelfth control channel cycle (time slot)

which occurs every 5.12 seconds, the RA� and AT transition from the Sleep Sub-State to

the Monitor Sub-State for the 13.33-ms control channel cycle time slot to exchange

synchronous capsules. To prevent loss of this exchange, the AT cannot change its Active

Set pilot at a time that causes it to miss a synchronous Control Channel capsule. 12

control channel cycles occur within 5.12 seconds (refer to Figure 7-9, “Idle Sub-States”

(p. 7-20)).

Sleep Mode Slotted Control Cycle

Control cycle time slot

The control cycle time slot used is derived from the AT's UATI value. The Sleep State is

similar to the 3G-1X slotted mode, and although 3G-1X has fewer time slots, its slot

cycle occurs every 5.12 seconds, allowing hybrid AT/3G-1X mobile operation. If the AT

is a hybrid mobile, it monitors the paging channel on the 3G-1X system as well as the

Figure 7-10 Sleep Mode Slotted Control Cycle

Control Channel

Traffic Channel

5.12 seconds

13.33 ms

426.66 ms

Call Processing Initiating a callDefault Sleep Sub-State

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-24 401-614-323Issue 16 October 2009

Page 433: 1xev-Do Rf Engineering

1xEV-DO slotted control channel in the same time slot period. Usually in 1xEV-DO, the

sleep cycle time slot is determined by the hash function using the AT-assigned UATI

value. If the 1xEV-DO control channel time slot assigned to the AT does not align with

the 3G-1X paging channel time slot, the AT is required to change the 1xEV-DO-assigned

time slot to coincide with the 3G-1X time slot. In that case, the AT would send a

PreferredControl Channel Cycle to the 1xEV-DO base station, indicating the desired time

slot. As a result, the 1xEV-DO awake control channel time slot for the AT is recalculated

to coincide with the 3G-1X awake time slot.

Call Processing Initiating a callDefault Sleep Sub-State

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-25

Page 434: 1xev-Do Rf Engineering

Rev A Enhanced Idle State Protocol

Introduction

The 5.12-second fixed wake-up time interval has the following drawbacks:

• This fixed wake-up time interval may be too long to handle paging for certain users

and for certain delay-sensitive applications, such as push-to-talk.

• For other users, the 5.12-second wake-up time interval may be too short and could be

extended to preserve a longer battery power life.

The Enhanced Idle State protocol allows variable wake-up time intervals, as negotiated

between the AT and the R�C during session configuration (or using GAUP), shown in

Figure 7-11, “Enhanced Idle State” (p. 7-26). Because idle state paging is only permitted

during the transmission of control channel packet data capsules, which occur at the

5.12-second, wake-up time intervals shorter than 5.12 seconds are only permitted when

the Enhanced Control Channel protocol is used to permit shorter control channel cycles.

Enhanced Idle State diagram

Description

The Enhanced Idle State Protocol feature is applicable for every 1xEV-DO BTS with

either classic EVMs/EVMm's or SB-EVMs/SB-EVMm's

As shown in Figure 7-11, “Enhanced Idle State” (p. 7-26), three period durations can be

defined with different wake-up intervals. The wake-up intervals in successive periods

must be equal to or greater than the interval in the preceding period (e.g., interval 1 is

equal to or greater than interval 2, which is equal to or greater than interval 3). The

increase in intervals is based on experience showing that paging activities are likely to be

Figure 7-11 Enhanced Idle State

Connection isdropped andAT switches tothe idle state

Period 1 duration Period 2 duration

Period 3 duration

Interval 1 Interval 2 Interval 3

Continue for idlestate duration

Call Processing Initiating a callRev A Enhanced Idle State Protocol

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-26 401-614-323Issue 16 October 2009

Page 435: 1xev-Do Rf Engineering

more frequent right after the connection is dropped, and less frequent as idle time

progresses. The three period durations are calibrated in slot periods and range to four slots

(26.68 ms) to 224 X 768 slots (~249 days), with a 3072-slot (12-control cycle) default.

Page masks

Three different Page masks (monitoring states) can be defined, allowing the AT to specify

masks for different technologies (e.g., 3G-1x paging, IEEE 802.11). When more than one

mask is used and a Page mask is active, the R�C does not send unicast messages to the

AT if the AT is idle. This allows the AT to tune away to access another wireless

technology (3G1x paging, SMS, etc.). Similarly to the period duration and wake-up

intervals, the Page mask values are negotiated between the AT and the R�C during

session configuration, or using GAUP.

Preventing loss of paging messages

To prevent loss of paging messages, the Enhanced Idle State operation is supported for all

the cells served by a RevA-capable R�C, independent of whether the carrier in the cell is

Rev 0 or Rev A. When the AT moves from sector to sector and encounters a sector with

Rev 0 carriers only, the RA� limits the sending period of paging (or other

mobile-directed messages) to intervals no smaller than one control channel cycle (5.12

seconds) in those sectors that are served by the Rev 0 EVM.

Call Processing Initiating a callRev A Enhanced Idle State Protocol

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-27

Page 436: 1xev-Do Rf Engineering

Page mask

Description

Page masks are used during the AT idle state to inform the R�C when unicast messages

are not to be sent to the AT. A number of Page masks can be defined, allowing the AT to

specify masks for different technologies (e.g., 3G1x paging, IEEE 802.11). Each page

mask defines a PreMask, Mask, and PostMask period in four-slot units, where unicast

messages may be sent to the AT only during the PreMask and PostMask periods (see

Figure 7-12, “Page Mask Periods” (p. 7-28)). When more than one mask is used, the R�C

does not send unicast messages in any Mask period, allowing the AT to tune away to

access another wireless technology (3G1x paging, SMS, etc.). Similarly to the period

duration and wake-up intervals, the Page mask values are negotiated between the AT and

the R�C during session configuration, or using GAUP.

Page Mask Periods

Suspend Mode of Operation

The suspend mode is entered by the AT after the open connection with the RA� is closed.

A close connection with the RA� is always terminated by the AT. When a connection is

being closed, the AT sends a ConnectionClose message to the RA�. As a result, the

traffic channel resources are released, and the AT can choose to go into the suspended

mode operation. In the suspended mode, the AT monitors the control channel

continuously for a period of time, and then proceeds to operate in the slotted (sleep) mode

(see “Description” (p. 7-24)). The ConnectionClose message indicates how long it will

Figure 7-12 Page Mask Periods

The RNC will not send the AT unicast message during the Mask period.

PreMask Mask PostMask

T = 0

Call Processing Initiating a callPage mask

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-28 401-614-323Issue 16 October 2009

Page 437: 1xev-Do Rf Engineering

stay in the suspended mode before entering the slotted mode. If the RA� has any data to

send to the AT during the suspended mode, the A� can send a TrafficChannelAssign-

mentMessage in an asynchronous capsule instead of a Page message.

Call Processing Initiating a callPage mask

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-29

Page 438: 1xev-Do Rf Engineering

Idle State Pilot Channel Supervision

Description

In addition to monitoring the control channel messages, the AT must monitor the pilot

signal associated with the control channel currently being monitored, and compare its

signal strength with the signal strengths of pilot signals from other sectors in the area.

This is fundamental to 1xEV-DO, ensuring that the AT will be receiving data from its best

serving base station to receive data at the highest rate possible. The pilot signals that are

monitored by the AT are identified by channel and P� offsets in a NeighborList

overhead message. The signal strength of the pilot signal associated with the control

channel currently being monitored is compared with the signal strengths of neighboring

pilot channels. This is done to identify and initiate handoff when the AT finds another

sector that can better service the AT with a higher data rate. Handoff is discussed in

greater detail in subsequent paragraphs. �ot only does the AT continuously monitor of

pilot signal strength in search of a better serving sector, pilot signal monitoring is also

performed to ensure that the stronger pilot signal selected is strong enough to maintain a

reliable connection. If the strength of the selected pilot signal falls below the minimum

value set in the parameter database, AT access to the RA� is lost.

Classes of pilot strength

The AT monitors the signal strengths of all the pilot channels in its RF environment and

classifies them into four mutually exclusive sets:

• Active Set: Set of pilot signals associated with the sectors that allocate channel

resources to the AT. Allocation of channel resources means that their associated

sectors are ready to receive and transmit traffic data from and to the AT when the

value its DRC channel points to the sector. In the Idle State, only one pilot is in this

set, that of the control channel currently serving the AT.

• Candidate Set: Pilot signals that are not in the Active Set, but are received by the AT

with sufficient strength to indicate that they good candidates for inclusion in the

Active Set

• �eighbor Set: Pilot signals that are not in either one of the two previous sets, but are

possibly potential candidates for inclusion in the Active Set

• Remaining Set: All possible pilots on the current channel assignment, excluding the

pilots that are in any of the three previous sets.

NeighborList message

The pilot signals that are categorized into one of the four pilot sets are extracted from the

NeighborList message complied by the route update protocol in the RA�. When the AT

enters the Idle connected state, a NeighborList message is received to convey

information corresponding to the neighboring sectors. This message lists all of the

neighboring pilot channels by its P� offsets and CDMA channel number. The AT may

Call Processing Initiating a callIdle State Pilot Channel Supervision

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-30 401-614-323Issue 16 October 2009

Page 439: 1xev-Do Rf Engineering

measure each P� offset to determine if their signal strengths are sufficient to support

traffic channel data. Most likely, the AT will sometimes be in a multipath environment,

causing the multipath components from a single pilot pulse to be received over a

sequence of chip periods. As a result, the actual pilot signal strength is the aggregate

signal energy received from each multipath component. To insure that most of these

components are weighed in the pilot signal strength measurement, a search time window

date to allow for arrival of multipath components is also received in the NeighborList

message.

Time window

This time window, which is expressed in the number of chip periods, for the active and

candidate sets, is entered into the database via the Search Window Size for the

Active/Candidate Set parameter on Sectors/Access Control Instance page. The search

windows for the neighbor and the remaining sets are specified by similar parameters on

the same Service �ode page. The search window parameter range is 0 to 15, where 0

specifies a 4-P� chip window width, and 15 specifies a 452-P� chip window width.

Search window sizes are related to cell size; more time should be allotted for the

collection of most of the multipath components. Searching for a pilot can fail if the AT

uses a small search window size in a large cell. Because of the greater distance, the search

window size for the neighbor set must be larger than the search window size for the active

and candidate set, and the search window size for the remaining set must be larger than

the search window size for the neighbor set. Setting the search window size for the

remaining set to 0 will eliminate the remaining set population.

Idle State Pilot Supervision

As part of the idle stat pilot supervision process, the pilot signal strength (Eb /�o level) in

the Active Set is compared with the signal strengths of the pilot signals in the Candidate

and �eighbor Sets, as shown in Figure 7-28, “IFHO Decision Flow Chart” (p. 7-93).

Call Processing Initiating a callIdle State Pilot Channel Supervision

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-31

Page 440: 1xev-Do Rf Engineering

PilotCompare value

When in the idle state, the only pilot signal in the active set is the pilot signal associated

with the current control channel servicing the AT. If the Eb /�o level of any pilot signal in

either candidate set is greater than the pilot signal in the active set for one second by the

value specified by the PilotCompare parameter, an idle state handoff is performed. As a

result, the pilot signal with the higher Eb/�olevel is placed in the Active Set, and its base

station sector becomes the AT serving sector. The AT's former serving pilot signal is

moved out of the Active Set, and is placed in one of the three other sets in accordance

Figure 7-13 Idle State Pilot Supervision

Monitor pilot signal strengthsin all pilot sets except those

in Remaining Set

Ispilot signal in

Candidate Set > pilotsignal in Active Set +

for1 sec.?

PilotCompare

Isany pilot signal

< Pilot Drop value?

No

Yes

Yes

NoStop pilotdrop timer

Start pilotdrop timer

Idle StateHandoff

Register

IndicationNetworkLost

No

Yes

Istimer expired

?

Measure strength of eachpilot signal on the samechannel in Active and

Candidate Sets

Call Processing Initiating a callIdle State Pilot Channel Supervision

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-32 401-614-323Issue 16 October 2009

Page 441: 1xev-Do Rf Engineering

with its current Eb /�o level. The PilotCompare value is entered in the database via the

Active Set Versus Candidate Set Comparison Threshold field of the Service

�odes/Pilot Values Instance Page.

Ensuring at least one pilot signal

To ensure that the Eb /�o levels of at least one of the pilot signals in either the Active or

Candidate Set are of sufficient strength to produce reliable service, the Eb /�o levels of all

of the pilot signals are compared with a Pilot Drop Threshold parameter level. This level

is entered into the system data base via Service Nodes/Pilot Values Instance Page to

define the minimum acceptable pilot channel level for reliable service. The signal

strengths of each of the pilots in the active and candidate pilot sets are compared to the

Pilot Drop Threshold. When the Eb /�o level of any pilot signal falls below the threshold

level, the pilot drop timer begins to count down from a count defined by the Drop Timer

Value, which is also a translation parameter entered into the database via the same Service

�odes page. The default value of this parameter is 3, which translates to 4 seconds. If,

after the timer is started, the pilot signal being compared increases above the Pilot Drop

Threshold, the timer is stopped. The timer result for each pilot signal is recorded by the

keep register, and is subsequently reported to the RAM via a RouteUpdate message. If

the timer expires, the AT considers the network lost.

Call Processing Initiating a callIdle State Pilot Channel Supervision

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-33

Page 442: 1xev-Do Rf Engineering

Connection setup

Connection Setup Sub-State

The connection setup sub-state is entered when the AT requires connection on a traffic

channel. Two types of connection setups are supported:

�ormal setup: Initiated by the AT with a ConnectionRequest Message sent by the AT in

response to receiving a Page Message, which directs the AT to initiate a connection

request

Fast Connect: Initiated by the RA� that sends a TrafficChannelAssignment Message

based on the last RouteUpdate received from the AT, without the AT sending a

ConfigurationRequest Message to the RA�. Fast Connect eliminates the need for the

Page and ConnectionRequest exchange when the RA� has pending data to transmit to an

AT.

When the AT enters the Connection Setup State, the AT needs to have a connection within

seconds (2.5 seconds). When the RA� enters the Connection Setup State, the RA� needs

to have a connection within one second.

Normal Setup

�ormal setup is always initiated by AT and will occur when the AT user wants to open a

session, or when the AT is responding to a page. Paging is used by the RA� to

communicate with the AT during the Idle State, and is typically sent when the RA� has

data to send to the AT. In order for the AT to receive paging from the RA�, and/or request

traffic channel access, the AT must either register as described in “Registration and

Location Report” (p. 7-15), or report its location via a RouteUpdate message. In either

case, the AT will have an assigned UATI address, enabling the RA� to identify the AT

when being paged. In addition, the AT must include its UATI value when it responds with

a RouteUpdate&ConnectionRequest (UATI) message to request a traffic channel

connection. The RouteUpdate and ConnectionRequest messages are bundled in the

same access channel MAC layer packet. The message exchange between the AT and RA�

is shown in Figure 7-14, “Traffic Channel Request Response to Page” (p. 7-35).

Call Processing Initiating a callConnection setup

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-34 401-614-323Issue 16 October 2009

Page 443: 1xev-Do Rf Engineering

Traffic Channel Request Response to Page

Description

The base station sends the Page message in response to a SendPage command from the

RA� to direct the AT to request a connection. The Page message is sent only if the AT

has already registered with the network and in the idle state. In response to the page, the

AT sends the RouteUpdate and ConnectionRequest message. The RouteUpdate

portion of this message will include the pilot P� phase (P� offset), pilot strength, and

drop timer status for every pilot in the active and candidate sets. The message also

includes the P� offset and signal strength of the pilot associated with the Control Channel

that the AT is currently using.

Upon receiving a connection request, the RA� requests that the base station allocate a

traffic channel to the AT. If the base station can comply with this request, it acknowledges

(AcAck) the AT page response to the RA�, and returns a response back to the RA�

indicating compliance with traffic channel allocation request. The RA� then sends the

base DRC and channel information that will be included in the TrafficChannelAssign-

ment message to be sent to the AT. This information includes DRC cover, length, and

channel gain (refer to “Traffic Channel Gain” (p. 5-60)), and also includes the reverse

active bit. The TrafficChannelAssignment message is sent to the AT when the Sent

TCA command is generated by the RA�. When the TrafficChannelAssignment

Figure 7-14 Traffic Channel Request Response to Page

Page Send Page

Route Update & Connection Request (UATI)

AcAck Allocate Traffic ChannelReq

Allocate Traffic Channel Resp

DRC Cover Ind

Sent TCA

Mobile Acquire Ind

Send RTC Ack

TCC

Ack

Configuration negotiation procedures

Traffic Channel Complete

RTC Ack

Send DRC + Pilot and ramp up RTC

Traffic Channel Assignment

ATBase

Station RAN

Call Processing Initiating a callConnection setup

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-35

Page 444: 1xev-Do Rf Engineering

message is received, a command ID sent to the AT MAC layer acquires the reverse traffic

channel (RTC). Subsequently, the AT starts transmitting over the assigned RTC and ramps

up to the RTC power level indicated through the forward Reverse Power Control (PRC)

channel. The AT sets its DRC length and cover to the values specified in the

TrafficChannelAssignment message, and transmits these values over the quadrature

phase (Q-phase) portion of the RTC (refer to Figure 3-17, “Multi-Slot Data Interlacing

with �ormal Termination” (p. 3-46)) to confirm receipt of the TrafficChannelAssign-

ment message. To help the base station to acquire this transmission, the AT also transmits

pilot and Reverse Rate Indicator (RRI) signals, on a time share basis, of the MAC portion

of the RTC. In response, the base station sends aMobile Acquire Ind signal to the RAM

indicating that the AT has acquired the assigned traffic channel. The RA� then responds

with Send RTCAck command that is relayed back to the AT. When the AT receives the

RTCAck message, it advances to the open connection state and responds with a

TrafficChannelComplete message that is acknowledged directly from the RAM. At

that point, the AT and RA� starts to negotiate configuration procedures over the

established traffic channel.

Call Processing Initiating a callConnection setup

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-36 401-614-323Issue 16 October 2009

Page 445: 1xev-Do Rf Engineering

Fast Connect Setup

Introduction

Fast connect is initiated by the RA� to re-establish a traffic channel connection for a user.

This connection setup speeds up connection setup time by eliminating paging and the

RA� wait time for the AT RouteUpdate&ConnectionRequest (UATI) message

response. Except for the elimination of the Page and the

RouteUpdate&ConnectionRequest (UATI) response, the fast connect setup (see Figure

7-15, “Fast Connection Setup” (p. 7-37)) is very similar to the normal connect setup.

Fast Connection Setup diagram

Description

The exchange of the Page and the RouteUpdate&ConnectionRequest (UATI) response in

normal connection setup is required because the RA� has no other way of determining

the AT's current location. To perform a fast connector setup, the RA� must have reliable

indication of the AT's location, which may be from a recent message exchange with the

AT. For a fast connection, the RA� is reasonably certain of the AT location when the AT

is in the suspend mode (refer to “Suspend Mode of Operation” (p. 7-28)). When the AT

enters this mode, then RA� is informed of the AT's location via it's RouteUpdate

message, and how long the AT will be in this mode before entering the sleep mode. The

RA� initiates the connection setup by sending the AT a TrafficChannelAssignment

Figure 7-15 Fast Connection Setup

Allocate Traffic ChannelReq

Allocate Traffic Channel Resp

DRC Cover Ind

Sent TCA

Mobile Acquire Ind

Send RTC Ack

TCC

Ack

Configuration negotiation procedures

Traffic Channel Complete

RTC Ack

Send DRC + Pilot and ramp up RTC

Traffic Channel Assignment

ATBase

Station RAN

Call Processing Initiating a callFast Connect Setup

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-37

Page 446: 1xev-Do Rf Engineering

message based on the last RouteUpdate message received from the AT. The

transmission of the TrafficChannelAssignment message is synchronous and requires

that the AT monitors the Control Channel while in the suspend mode. Therefore, to avail

itself for fast connect setup, the AT cannot go into the slotted mode to conserve battery

time.

Call Processing Initiating a callFast Connect Setup

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-38 401-614-323Issue 16 October 2009

Page 447: 1xev-Do Rf Engineering

Configuration Negotiation to Open a Session

Introduction

After the UATI and traffic channel are assigned, a configuration negotiation procedure is

performed to open a session between the AT and RA�. A session is a shared state

maintained between the AT and the RA� where the AT can be addressed using the UATI.

To open a session between the AT and RA�, three things must occur:

• AUATI and traffic channel are successfully assigned to the AT

• Session configuration is successfully negotiated

• A Point-to-Point Protocol (PPP) link is established between the AT and the PDS�. At

this time, a user record is created and stored in the PDS�.

After the session is opened, the connection between the AT and RA� can open and close

a connection multiple times. When the connection between the AT and RA� is closed, a

connection release is issued. This may occur when the AT goes into the sleep mode in the

idle state because of inactivity. As a result, the session goes into the dormant mode.

Although at this time, the AT surrenders its traffic channel, the PPP link is still maintained

in an open session with the RA�.

TIA-856A Session Layer

When a session is being opened, protocol parameters are governing how communication

must be negotiated over the traffic channel. This negotiation is handled through the

Session Layers in the AT and RA�. The TIA-856A Session Layer contains the following

protocols (see Figure 7-16, “TIA-856A Session Layer” (p. 7-40)):

• Session Management Protocol: Controls the other Session Layer protocols. This

protocol performs session maintenance to ensure that the session is still valid and to

manage the closing of the session. A session may be kept open using “Keep Alive”

functions, which is controlled by this protocol. The procedure to close a session is

started when the AT no longer has a UATI and, therefore, cannot be addressed by

RA� after a long period of dormancy (AT inactivity).

• Address Management Protocol:Manages initial UATI assignment and maintains the

AT addresses

• Session Configuration Protocol: �egotiates protocols and configuration parameters.

Configuration parameters are negotiated between the AT and RA� a number of times

during a session through the exchange of ConfigurationRequest and

ConfigurationResponse messages between the AT and RA�.

Call Processing Initiating a callConfiguration Negotiation to Open a Session

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-39

Page 448: 1xev-Do Rf Engineering

Figure 7-16 TIA-856A Session Layer

Session ManagementProtocol

Address ManagementProtocol

Session ConfigurationProtocol

Call Processing Initiating a callConfiguration Negotiation to Open a Session

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-40 401-614-323Issue 16 October 2009

Page 449: 1xev-Do Rf Engineering

Configuration Negotiation Procedure

Description

The configuration negotiation procedure is initiated by the AT for the very first setup of

the session, performed after a UATI is assigned. To save bandwidth when negotiating a

session, multiple parameters in 1xEV-DO are set with default values in both the AT and

RA�. The RA�-initiated negotiation is typically used to override these default values.

To keep track of the negotiated parameters, the standards provide a Token mechanism.

The Token is set by the RA�. Every time the AT accesses the network through a new

sector, the AT will send back the Token. If the AT's Token is mismatched to that of the

base station per sector Token, a re-negotiation will take place, and the AT's Token will be

reset after the negotiation.

Configuration parameter values

The configuration parameter values can be changed through configuration negotiation by

exchanging the ConfigurationRequest and ConfigurationResponse messages between the

AT and base station. The negotiation procedures take place on the Traffic Channel, and

can take place at the beginning of a session or any other time, as long as the AT is

assigned to a traffic channel. The negotiation starts by sending a ConfigurationRequest

message.

�egotiation is done on a per-protocol basis, so there can be an equal number od

ConfigurationRequest/ConfigurationResponse messages exchanged between the AT and

A� as the number of protocols used. When the negotiation is done, a ConfigurationCom-

plete message is sent. Figure 7-17, “Session Configuration �egotiations” (p. 7-42) shows

the configuration negotiation process for initial negotiation. Subsequent configuration

will occur after the connection is established.

Call Processing Initiating a callConfiguration Negotiation Procedure

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-41

Page 450: 1xev-Do Rf Engineering

Session Configuration Negotiations diagram

Figure 7-17 Session Configuration Negotiations

ConfigurationComplete

ConfigurationComplete

ConfigurationRequest

ConfigurationRequest

ConfigurationRequest

ConfigurationResponset

ConfigurationResponset

ConfigurationResponset

Connection Establishment

AT RAN

Call Processing Initiating a callConfiguration Negotiation Procedure

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-42 401-614-323Issue 16 October 2009

Page 451: 1xev-Do Rf Engineering

PPP Connection

Description

Once a configuration has been negotiated, a PPP (Point-to-Point Protocol) connection

must be established between the AT and the PDS� (refer to “AT Protocol Stack” (p. 2-18)

). The PPP establishment is shown in Figure 7-18, “Establishing PPP Connection”

(p. 7-43). After a traffic channel is established and the session configuration negotiated,

the AT will then send a XonRequest message to the RA�. This message is generated by

the Flow Control protocol which is a sub-component of Default Packet Application

Protocol of the TIA-856AApplication layer. The Flow Control protocol provides

procedures and messages required by the Default Packet Application Protocol to perform

over the air packet data flow. The Flow Control protocol has two states:

• Close state, in which radio link protocol (RLP) packets cannot be sent or received

• Open State, in which RLP packets can be sent or received.

Establishing PPP Connection

When the XonRequest message is received by the RA�, its Flow Control protocol

transitions from the closed state to the open state. Flow Control protocol for the shared

session between the RA� and AT will remain in the open state until a XoffRequest

message is received from the AT. At this time, Flow Control protocol transitions to the

closed state.

In response to the XonRequest, the RA� causes the AP in the FMS to establish an

A10/A11 connection with the PDS�. After this connection is established, the RA�

returns an XonResponse. When this response is received, indicating that A10/A11

Figure 7-18 Establishing PPP Connection

Configuration Negotiation Procedure

XonRequest (service)

XonResponse (service)

Establishing PPP Connection

Transmitting Packet Data

Establish A10/A11Connection

PDSNRANAT

Call Processing Initiating a callPPP Connection

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-43

Page 452: 1xev-Do Rf Engineering

connection is established, the AT the user will go through IP login procedures with the

PDS�, which typically involves authenticating the user through the AAA Server. Once

successfully authenticated, the user and the PDS� create a PPP session between them.

This PPP session normally remains up until terminated by the AT user.

Call Processing Initiating a callPPP Connection

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-44 401-614-323Issue 16 October 2009

Page 453: 1xev-Do Rf Engineering

Session Maintenance

Call precessing functions

Various call processing functions are required to maintain an open session between the AT

and RA�. These processing functions are listed below. Only the first two functions are

discussed in this section. Either because of their complexity or relevance to other

functions, all the other processing functions are discussed in other sections. In this case, a

brief description of the function is given with a section reference where a detailed

discussion of the processing function is given.

• Keep Alive Function—The AT or the RA� periodically exchanges KeepAliveRequest

and KeepAliveResponse messages to ensure that the session is still open

• Dormant /Active Function—The activity of the AT is continually monitored. If the

AT is inactive for a period, the AT goes into a dormant mode.

• Scheduling— Process to maximize the overall sector throughput, by allocating

forward link time slot to those ATs reporting the best RD conditions. The scheduling

algorithm is thoroughly discussed in “Maximizing Sector Throughput” (p. 3-57).

• Rate control— Each section transmits a Reverse Activity Bit (RAB) on its reverse

activity channel. To control reverse link interference, the RAB bit is broadcast to all

the ATs in the section RF environment, instructing the ATs either to increase or

decrease its transmitted data rate. Refer to “Introduction” (p. 7-74).

• Handoff—The ATs estimate the strength of the forward channel transmitted by each

sector in its neighborhood. This estimate is based on measuring the strength of the

forward pilot channels from its serving sector and it neighboring sectors.The AT

identifies the sector having the strongest measured pilot channel by transmitting a data

rate control (DRC) value, indicating the date rate that can be supported from the

sector. If the RA� determines the data rate indicated by the AT is the highest from

other ATs vying for service from that sector, the RA� will permit the AT to be handed

off to the sector. Refer to “Handoff introduction” (p. 7-76) for a detailed discussion on

handoff.

• Power Control—Because in 1xEV-DO the base station always transmits at full

power, power control is only required on the reverse link. The purpose of reverse link

power control (RPC) is to determine the lowest power required to maintain a desired

Frame Error Rate (FER) for each user. When all ATs transmit the lowest power

required, the sector and base station capacity are maximized. Refer to “Rev 0 Power

control” (p. 7-108) for a detailed discussion on power control.

• Overload Control— In addition to power control, protection against reverse link

overload is essential. Such protection begins with the design of the forward link

budget; however, reverse link overload control algorithms are in place to protect the

system against performance degradation due to increased reverse link interference.

Reverse link overload control not only helps to maximize the reverse link throughput,

but also helps to maximize the forward link throughput. This is done by ensuring the

integrity of the reverse link MAC Channel (both DRC Channel and ACK Channel).

Call Processing Initiating a callSession Maintenance

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-45

Page 454: 1xev-Do Rf Engineering

Lost or high levels of interference on the DRC channel may present

missed-opportunities from handing off ATs to better serving sector, and the failure to

properly receive the ACK channel may result in unnecessary transmission and

re-transmission of packet data on the forward link. Refer to “Rev 0 Overload control”

(p. 7-111) for a detailed discussion on overload control.

Call Processing Initiating a callSession Maintenance

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-46 401-614-323Issue 16 October 2009

Page 455: 1xev-Do Rf Engineering

Messages during inactivity

Keep Alive Function

During periods of AT inactivity, the AT and RA� will be triggered to exchange

KeepAliveRequest and KeepAliveResponse messages between the AT and RA� to ensure

that the session is still open and can remain open. The KeepAliveRequest message may be

transmitted from either the RA� or AT. The exchange of these messages is typically

transmitted with asynchronous capsules over the access and control channels because the

most likely need for this message exchange will occur during dormancy. If the traffic

channel is still assigned to the AT, the message exchange may occur over the forward and

reverse traffic channels.

Process

When the message is transmitted, the sender waits for a KeepAliveResponseMessage,

indicating that the recipient is still available to continue the session. If a response is not

received within a specified time, a release session command is issued, causing the session

manager protocol to close the session. The system will keep a session open when no

activity is sensed over the forward and reverse traffic channels for a time period specified

by a Keep Alive Timer parameter. This parameter is entered into the database via the

Service Nodes/General Instance Page - Section 1 and has a range between 0 and

65535, calibrated in minutes where 65535 minutes equal 1092.25 hours or 45.5 days. The

TIA-856A standards define the default value of 3240 minutes, or 54 hours. A zero value

for this timer disables the keep alive function. The time interval between the transmission

of successive KeepAliveRequest/KeepAliveResponse message exchange is determined by

dividing the period set by the Keep Alive Timer parameter by three. Therefore, up to three

KeepAliveRequest/KeepAliveResponse message exchanges may occur during the AT

dormancy period. If any KeepAliveResponse Message is not received or no AT activity is

detected for the Keep Alive Timer period, the session will close down.

Dormant /Active Function

The RA� monitors the activities on the AT forward and reverse traffic channels to

determine whether the AT is in the dormant mode. Because of inactivity for a period

defined by a dormancy timer, the AT is released of its assigned traffic channel and enters

the dormant mode. The dormancy timer is set by the Dormancy Timer parameter has a

range between 1.0 and 60.0 in 0.5-second steps.

For the least active ATs the AP compresses the UATI data to conserve system memory.

While in the dormant mode, the AT can only monitor the control channel during its

wake-up cycle. During this mode, the AT monitors Page messages and will respond to

KeepAliveRequest messages over the access channel. The AT transitions back to the active

Call Processing Initiating a callMessages during inactivity

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-47

Page 456: 1xev-Do Rf Engineering

state when the user has a message to send, or when the AT is responding to a Page

message. At this time, the AT will transmit a RouteUpdate&ConnectionRequest (UATI)

message as described in “�ormal Setup” (p. 7-34).

Call Processing Initiating a callMessages during inactivity

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-48 401-614-323Issue 16 October 2009

Page 457: 1xev-Do Rf Engineering

Paging

Overview

Purpose

Different mobile applications have different Quality-of-Service (QoS) requirements for

paging latency, and network operators need the flexibility to optimize paging

effectiveness and paging efficiency. Therefore, theAlcatel-Lucent EVDO Radio Access

�etwork provides intelligent paging methods to accommodate different QoS classes of

traffic. This section describes the techniques available to optimize paging.

Topics covered

This section describes the functionality associated with paging in the following states:

• How to use our default paging capability (with neither QoS Paging or

Mobile-Terminated Data-Over-Signaling (DOS) active).

• How to use our QoS paging capability, including distance based paging.

• How to use QoS paging together with DOS.

�ote:DOS without QoS Paging strategy is not supported. DOS require QoS paging

strategy to be turned on.

Contents

Paging types 7-50

Terms used with paging 7-51

EVDO paging considerations 7-53

Default paging with neither QoS or DOS 7-55

QoS paging for Profile IDs 7-56

1xEV-DO Basic PTT using 1xEV-DO Rev A�etworks 7-58

1xEV-DO PTT Paging Enhancements 7-60

Parameters 7-62

Paging controls example 7-63

Distance based paging operation 7-65

Deriving Route Update Message distance 7-66

QoS paging with DOS 7-68

Call Processing PagingOverview

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-49

Page 458: 1xev-Do Rf Engineering

Paging types

Paging types

1. Default pagomg

• Available in R27

• Simplest to provision and monitor

2. QoS paging enhancements

• Differentiates paging by the following:

- efficiency

- effectiveness

- latency

• Distance based paging

• Priority

3. QoS plus DOS

This is a special case for latency sensitive applications.

Call Processing PagingPaging types

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-50 401-614-323Issue 16 October 2009

Page 459: 1xev-Do Rf Engineering

Terms used with paging

Definitions

These terms have specific meanings when discussing QoS and DOS.

paging Paging is sometimes used to describe a set of procedures to locate a mobile in the

network. A Page is also a TIA-856A defined message type sent by the A� to the AT.

DOS DOS and DOSAck are TIA-856A defined message types sent between the AT and

the A�. DOS also is an acronym for Data Over Signaling and DOS is used to describe

a set of procedures to deliver data over the Control Channel.

QoS paging AQoS Paging Attempt is similar to a default paging attempt but also

includes a defined paging area, optional DOS method and various provisionable

parameters controlling paging variables. When the QoS Paging attempt is provisioned

to be a Data Over Signaling delivery attempt, a DOS message is sent via the Control

Channel.

paging attempt The term "paging attempt" is kept for a general sense of locating the AT.

In the case of DOS, the term "paging attempt" does not result in a Page message, but

is really DOS delivery or RouteUpdateRequest delivery.

DOS Method types

Three DOS Method types are defined. Each method type is listed in the table below with

actions on the message type and the delivery area used. The letter abbreviations are used

in this section when referring to the DOS method type.

Letter Name Description

D Direct DOS Send at AT wake-up cycle. This is only allowed over the last

active set (OHM’s could be on other R�C’s).

R RouteUpdateRe-

quest

Send RouteUpdateRequest message to last active set.

For sectors that respond with RouteUpdateResponse, send

Direct DOS message.

M Mixed Send RouteUpdateRequest message to all sectors defined in

the QoS paging area except the last active set.

Simultaneously send Direct DOS to last active set.

Call Processing PagingTerms used with paging

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-51

Page 460: 1xev-Do Rf Engineering

Notes:

1. "D" is not allowed with any paging area other than Last Active Set. In this case, there is an

attempt not to flood the Control Channel synchronous and asynchronous capsules with

DataOverSignaling messages.

2. "M" is not allowed to be used with a paging area of Last Active Set. In this case,

DataOverSignaling messages are sent to each of the sectors in the last active set and

RouteUpdateRequest are sent to remaining sectors defined in the QoS paging area. A choice

of Last Active Set would result in two message types sent to the same sector simultaneously.

For the definitions of paging areas see “Paging areas” (p. 7-52).

Paging areas

The paging area is provisioned as one of the following:

Name Description

Last Active Set This is the list of all sectors which are in the Active Set which the OHM

considers current for the AT.

Last Seen R�C This paging area includes all sectors in the color code of the last seen R�C.

�eighbor R�C. This paging area includes all sectors in all cells the current R�C and all sectors

in the previous R�C.

R�C Group This paging area includes all sectors in all cells in each R�C which belongs to

the R�C Group.

Distance Tier 0

Distance Tier 1

Distance Tier 2

Distance Tier 3

The paging area includes all cells which are determined to be within the

provisioned distance away from the cell which last received a message from the

AT. This enhancement requires a distance based ordered list of neighboring

cells associated with each cell. The building and maintenance of these

distance-ordered lists is a significant part of the architecture, in addition to the

actual paging call flow operations.

Call Processing PagingTerms used with paging

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-52 401-614-323Issue 16 October 2009

Page 461: 1xev-Do Rf Engineering

EVDO paging considerations

Paging considerations

Three characteristics of paging performance in a wireless network are shown below:

• Paging Effectiveness (How often is the mobile located?)

• Paging Efficiency (How much network resources are consumed in locating the

mobile?)

• Paging Latency (How long does it take to locate the mobile?)

As "Push" applications such as Push-To-Talk proliferate in EVDO networks, paging will

consume a larger part of EVDO network resources. Estimates indicate that paging will

consume sizeable fractions of resources across the EVDO system (AP CPU, R�C to Cell

backhaul bandwidth, EVDO control channel utilization) and that the use of distance based

paging will be required to maximize paging efficiency without sacrificing paging

effectiveness

Parameter precedence

Parameters of the same name can exist for various levels in the system precedence. A

parameter at a smaller unit in the precedence will override the value of that parameter for

a higher level object.

For example, a parameter specified at the BTS level will override a similarly named

parameter that is specified at the R�C Group level

Paging priorities

Priorities set for the different paging areas (see “QoS Paging Controls: example” (p. 7-63)

) are ordered low number to higher number. For example, a priority of 20 is greater than a

priority of 30.

Manual updates

The following diagram is a representation of an R�C group spanning service node

boundaries.

ServiceNode

RNCgroup

RNC RNC RNCRNC

RNC RNC RNCRNC

RNC RNC RNCRNCServiceNode

Call Processing PagingEVDO paging considerations

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-53

Page 462: 1xev-Do Rf Engineering

�ote:R�C Group settings override per Service �ode Settings. When an R�C group

spans multiple service nodes, as in the figure, the per R�C Group paging settings

should be manually checked for consistency, or unpredictable behavior could result.

Time to page an AT

To conserve resources, set the time to page the AT less than the time the sending

application waits for a response.

Configure the paging strategies such that the maximum time it may take to page the AT is

less than the maximum interval that the application that initiates the paging attempt will

wait for a response.

For example, if doing 4 page attempts takes 10 seconds, but the application trying to page

the mobile only waits 5 seconds for a response, then they should reduce the number of

pages in this paging strategy. Otherwise, paging resources are wasted.

Call Processing PagingEVDO paging considerations

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-54 401-614-323Issue 16 October 2009

Page 463: 1xev-Do Rf Engineering

Default paging with neither QoS or DOS

Parameters

For default paging only the parameters from the Service �ode - Paging Parameters screen

are available (they do not vary per profile id)

• Number of Times to Page the Last Active Set

• Number of Times to Page the Last Seen RNC

• Number of Times to page neighbor RNC

• Number of Times to page entire RNC group

• Paging Escalation Timer (PET) (See “Paging Escalation Timer (PET)” (p. 7-55))

• Minimum Time to wait for a page or DOS response

• Paging Time to Live Timer

Paging Escalation Timer (PET)

If the time between when the mobile was last seen and the next time the mobile would

wake up is greater then the PET then the system will skip the paging level and escalate to

the next paging level.

For example, if it was at Last Active Set and the Paging Escalation Timer was less than

time between last seen and wake-up then it would page the Last Seen R�C.

This parameter is set per service node. A value of 60 is off (disabled). The smaller the

timer the more often the system escalates.

Paging sequence

The following list is the order in which paging attempts occur. Different attempt types can

occur more than once.

1. Last Active Set

2. Last Seen R�C

3. �eighbor R�C

4. Entire R�C group

�ote: The total # of page attempts should be <= 8.

Call Processing PagingDefault paging with neither QoS or DOS

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-55

Page 464: 1xev-Do Rf Engineering

QoS paging for Profile IDs

QoS paging attempts

AQoS Paging Attempt is similar to a default paging attempt but also includes a defined

paging area, optional DOS method and provision-able parameters controlling paging

variables. When the QoS Paging attempt is provisioned to be a Data Over Signaling

delivery attempt a DOS message is sent via the Control Channel. In the case of DOS, the

term "paging attempt" does not result in a Page message, but is really DOS delivery or

RouteUpdateRequest delivery. The term "paging attempt" is kept for a general sense of

locating the AT.

Best Effort

ABest Effort (BE) paging attempt means paging is done in the absence of any qualifying

parameters. The system makes a best effort at satisfying all paging needs.

Call Processing PagingQoS paging for Profile IDs

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-56 401-614-323Issue 16 October 2009

Page 465: 1xev-Do Rf Engineering

QoS profile IDs

As of R28, Alcatel-Lucent supports 11 “QoS Profile IDs”. These are mapped to

FlowProfileIDs specified in TSB58G as shown in the chart at the right. Most of the QoS

Profile IDs have a fixed mapping, but for PTT Speech, the actual FlowProfileID is

translatable, to allow use of PTT applications using different FlowProfileIDs.

For example, PTT Media FlowProfileID 261 represents Full Rate EVRC using unbundled

RTP, where 280 represents Half Rate EVRC using 6-frame bundled RTP.

QoS Profile ID FlowProfile ID(s) Pageable?

Best Effort 0 Y

Conversational Rate Set One Speech 256 �

Conversational Video 24K 768 �

Conversational Video 40K 770 �

Conversational Video 48K 771 �

Conversational Video 64K 773 �

ConversationalMedia Control Signalling 1280 Y

PTT Call Setup Signalling 1283 Y

PTT In-Call Signalling 1283 Y

PTT Speech Bearer 1 261 - 280* Y

PTT Speech Bearer 2 261 - 280* Y

Notes:

1. *QoS paging is only available for these profile IDs listed as page-able.

Call Processing PagingQoS paging for Profile IDs

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-57

Page 466: 1xev-Do Rf Engineering

1xEV-DO Basic PTT using 1xEV-DO Rev A Networks

Overview

1xEV-DO Basic PTT using 1xEV-DO Rev A�etworks, provides push-to-talk

functionality for 1xEV-DO and is based on theMultiflow Packet Application (MFPA).

�ew QoS service categories are introduced for PTT signaling & bearer are used. The

signaling flows and the media flow have separate A10s and RLP flows

Paging Method Examples

The following examples show 5 R�Cs, in 2 service nodes, and 2 R�C groups (from

FID-12456.1). One of the R�C groups spans across a service node. “X” marks the last

seen location of the target AT.

Last Active Set Page

Page is sent only by sectors in the last active set

reported by the AT in the RUM. Doesn’t page

across R�C group.

SN2RNC 2CC 5GROUP 2

SN2RNC 1CC 4GROUP 1

SN1RNC 3CC 3GROUP 1

SN1RNC 2CC 2GROUP 1

SN1RNC 1CC 1GROUP 1

X

Last seen R�C

Page is sent by all sectors in the R�C on which the AT

was last seen.

SN2RNC 2CC 5GROUP 2

SN2RNC 1CC 4GROUP 1

SN1RNC 3CC 3GROUP 1

SN1RNC 2CC 2GROUP 1

SN1RNC 1CC 1GROUP 1

X

�eighbor R�C page

Page is sent by all sectors in the Last Seen R�C,

and all sectors in the Previously Seen R�C if in an

R�C Group.

SN2RNC 2CC 5GROUP 2

SN2RNC 1CC 4GROUP 1

SN1RNC 3CC 3GROUP 1

SN1RNC 2CC 2GROUP 1

SN1RNC 1CC 1GROUP 1

X

R�C group page

Page is sent by all sectors in every R�C in the Group. If

the last seen R�C is not in a group, then the page would

just be sent from that R�C.

SN2RNC 2CC 5GROUP 2

SN2RNC 1CC 4GROUP 1

SN1RNC 3CC 3GROUP 1

SN1RNC 2CC 2GROUP 1

SN1RNC 1CC 1GROUP 1

X

Call Processing Paging1xEV-DO Basic PTT using 1xEV-DO Rev A Networks

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-58 401-614-323Issue 16 October 2009

Page 467: 1xev-Do Rf Engineering

Paging Area Escalation

Allows paging area to adapt based on staleness of AT location information.

If the paging area is specified to be Last_Active_Set, and the AT had not been observed

within the Paging Escalation Timer, then the paging area will be escalated to the

Last_Seen_R�C.

In 12184.1, R28, the paging area is escalated to Last_Seen_R�C.

For example, if the paging strategy specifies Last_Active_Set followed by

Last_Seen_R�C and then R�C_Group, paging escalation will occur to the

Last_Seen_R�C.

Paging Strategy Escalation

Paging for the default (Best Effort) flow is generally configured to be highly efficient, but

the paging latency may be long.

Default: Two Last Active Set pages followed by two ColorCode (R�C) pages.

If AT is not in last active set, will require 3 page intervals to find this AT.

With Paging Strategy Escalation, if data is received on a PTT flow while already paging

for BE, we terminate the BE paging attempt and escalate to use the PTT paging strategy.

For example, immediately send a Distance Based Page. This reduces PTT Paging Latency

in this scenario.

Paging count changes in FID12184.1

FID 12184.1 introduces the following paging counts:

• Page Requests Dropped Due to APOverload, per AP-Profile ID

Call Processing Paging1xEV-DO Basic PTT using 1xEV-DO Rev A Networks

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-59

Page 468: 1xev-Do Rf Engineering

1xEV-DO PTT Paging Enhancements

Overview

1xEV-DO PTT Paging Enhancements, FID 12184.5 provides paging enhancements

targeted for PTT applications. The paging enhancements improve paging efficiency by

increasing the probability of locating the users on the first page attempt.

These enhancements apply specifically to PTT, but these new paging capabilities will be

available to other services as well. The following list gives the areas of change:

• Priority Paging

• R�C Group and �eighbor R�C paging (used by QoS paging)

• Paging De-Escalation

• Contextual Repaging

Priority Paging

Priority Paging provides the capability to prioritize page messages based on QoS Profile

ID and Page attempt. For example, the relative priorities of the second attempt for PCT

versus the first attempt for BE can be specified.

Higher priority pages enjoy the following benefits:

• Lower Latency - They are selected earlier in each control channel cycle, previously

FIFO.

• Precedence during overload - If paging claims exceeds capacity, lowest priorities are

dropped first.

Priority Paging Example

The following table compares paging priorities for SLP and Priority paging.

SLP Priority Priority Paging

All Pages have SLP Priority 20

4 Pages received in order P1, P2, P3, P4

P1, P4 has CC Page Enqueue Priority 19

P2 has CC Page Enqueue Priority 29

P3 has CC Page Enqueue Priority 25

Order result is FIFO: P1, P2, P3, P4 Order result: P1, P4, P3, P2

Call Processing Paging1xEV-DO PTT Paging Enhancements

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-60 401-614-323Issue 16 October 2009

Page 469: 1xev-Do Rf Engineering

New Paging Methods

Paging Area is a mechanism for identifying the set of BTS for which a page will be

attempted. The four Paging Area types in order of increasing scope are as follows:

1. Last Active Set

2. Last Seen R�C

3. �eighbor R�C (Last Seen + Previously Seen R�C)

4. R�C Group

�ote: If distance based paging is activated criteria for using it must be determined on

a case-by-case basis.

Paging Area type can be selected for 1 up to 8 Paging Attempts. Types 3 and 4 are added

with this feature. See FID 12456.1 for a full description.

Call Processing Paging1xEV-DO PTT Paging Enhancements

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-61

Page 470: 1xev-Do Rf Engineering

Parameters

Parameters to set for QoS EVDO paging

In the following list of parameters each parameter exists at several levels in the hierarchy

and in slightly different occurrences. For example, the DOS Method parameter is repeated

for attempts one through eight for both the profile ID screen and the, higher precedence,

R�C Group profile ID screen.

• Default

– DOS method (for attempts one through eight) for profile ID and R�C Group

profile ID

– �umber of Times to Page for the Entire R�C Group, the Subnet, the �eighboring

R�C and the Last Active Set

• QoS

– Page Enqueue Priority (for attempts one through eight) for profile ID and R�C

Group profile ID

– Paging area De-Escalation Time for profile ID and R�C Group profile ID

– Paging area (for attempts one through eight) for profile ID and R�C Group

profile ID

– Repage timer for profile ID and R�C Group profile ID

– Size of Distance Paging Tier. This parameter exists for tiers 1, 2, and 3 for each of

the BTS, sector, and service node levels.

– T_Page1 (Paging escalation timer) for profile ID, R�C group, and service node

– T_page2 (Paging Time-To-Live Timer) for profile ID, R�C group, and service

node

– Use Paging Priority for profile ID and R�C Group profile ID

– Use QoS Paging Strategy for profile ID and R�C Group profile ID

• DOS

– Paging Priority for Route Update Request for profile ID and R�C Group profile

ID

This list is not intended to be all inclusive. It shows the list of parameters to consider and

the levels at which those parameters exist.

Call Processing PagingParameters

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-62 401-614-323Issue 16 October 2009

Page 471: 1xev-Do Rf Engineering

Paging controls example

QoS Paging Controls: example

The following layout is an example of the QoS paging controls.

Paging De-escalation

During blocking, there can be repeated successful attempts to page an AT in a short period

of time.

To improve efficiency in this scenario new capability added is Paging De-escalation.

• The paging area will be de-escalated to a small area if the AT was previously seen

within a translatable timer.

• �ew TR parameter per QoS Profile ID for Paging De-Escalation Timer.

• If a 1st page attempt occurs within the De-escalation timer of the AT’s previously seen

timestamp, the paging method is de-escalated to Last Active Set.

Contextual Paging Timeout

Prior to QoS Paging, theA� waits for a fixed interval for an AT response after a packet is

received that triggers a page. This is independent of the AT’s next wakeup slot.

Profile ID PTT CallSetup SignallingQoS Profile ID Value 1283

Use QoS Paging Strategy YUse Priority Paging YPaging Area for 1 st Attempt Last_Active_SetPaging Area for 2 nd Attempt Last_Seen_RNCPaging Area for 3 rd Attempt Neighbor_RNCPaging Area for 4 th Attempt RNC_GroupPage Enqueue Priority for 1 st Attempt 19Page Enqueue Priority for 2 nd Attempt 20Page Enqueue Priority for 3 rd Attempt 21Page Enqueue Priority for 4 th Attempt 22

Repage Timer (Seconds) 1.0Paging Escalation Timer (Minutes)Paging Time - To- Live Timer 0.1Paging Area De- Escalation Timer 1

Each pageable QoSProfile ID has it�s ownset of paging controls{BE, CMCS, & PTT arepageable).

If N, use default (R27) paging strategy controls.

Up to 8 attempts can bespecified; here we willstop paging after 4 tries.

Standard priority is 20; lower# will be scheduled first.

Make next attempt if no response in 1 second.

If AT hasn�t been seen for > 10 minutes,escalate paging area to Last_Seen_RNC

Stop paging after 0.1 minute,regardless of other settings.If AT was seen in last second, send to last

active set, instead of translated area.

10

Call Processing PagingPaging controls example

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-63

Page 472: 1xev-Do Rf Engineering

With Contextual Paging Timeout (FID-12814.5), when QoS Paging, theA� waits for a

translatable “Repage Timer” interval after the ATs next expected wakeup slot.

This significantly reduces the delay that can be used between page attempts.

If AT isn’t found on 1st attempt, 2nd attempt can be triggered very quickly, to minimize

95%ile paging latency.

Slotted Timer

With 12184.5, if a page arrives while the AT is still in this state the page will be delivered

immediately using asynchronous capacity instead of waiting for the AT's next wake cycle.

Whenever AT successfully completes an Access Probe, it remains in the monitor state

monitoring the control channel for a value of TACMPTransaction (1 second).

Repage Timer - Contextual repage

Prior to R28 the A� would wait a fixed value of 5 seconds after a network reactivation

page for an AT to respond before transmitting a next page. This would result in significant

latency if the AT was not present in the initial paging area.

In 12184.5 a Repage timer can be configured for each profile. This timer is started when

the A� pages the AT based upon the wake-up cycle. With this approach, the second page

can be transmitted after a much shorter period, this reducing the paging latency.

Paging count changes in FID12184.5

FID 12184.5 introduces the following paging counts:

• Page Aborts Due to Higher Priority ProfileID Override, per R�C-Profile ID

(PAGE_ABORT_HIGHER_PID)

• Paging Escalations, per R�C-Profile ID (PAGE_ESC)

• Pages for �th (1:8) Attempt, per R�C-Profile ID (PAGES)

• Connection Requests Received for �th (1:8) Attempt, per R�C-Profile ID

(PAGE_CR_RCVD)

FID 12184.5 makes the following counts obsolete:

• Page Requests (PAGE_ATTEMPTS)

• Page Attempts treated as AT Initiated Connection Request (PAGE_ATTEMPT_�OT-

_RESPO�DED)

• Page Attempt �ot Responded (PAGE_ATTEMPT_AT_I�IT_CO��_REQ)

Call Processing PagingPaging controls example

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-64 401-614-323Issue 16 October 2009

Page 473: 1xev-Do Rf Engineering

Distance based paging operation

Before the process begins

For information on the correct format for latitude and longitude see Alcatel−Lucent

Service Alerts 07−0545 EVDO R�C R28: The BTS latitude and longitude values may be

incorrect after R�C is retrofitted to R28.

For distance based paging to work the correct latitude and longitude must be entered for

each cell.

Route update radius - radius for registration update (miles)

See messages - too small and there will be a lot of messages and too big will produce

none.

Route Update Message process

...................................................................................................................................................................................................

1 All of the sectors transmit their lat/long and a “RUM Distance” on the overhead channel.

...................................................................................................................................................................................................

2 The ATs remember the lat/long of the primary sector of their last interaction (last sector

they did a RUM - Route Update Message).

...................................................................................................................................................................................................

3 ATs constantly monitor the RF strength and determining which sector is their primary.

...................................................................................................................................................................................................

4 When a new primary sector is switched to, the AT calculates the distance between the new

primary and the last RUM sector. If the distance is greater than the RUM distance

received from the last RUM sector, then the AT will do an autonomous “distance based”

RUM on the new primary sector.

...................................................................................................................................................................................................

5 When the system has a page for an AT, the R�C pages all of the sectors within a radius of

the AT's last RUM sector (the tier distance inAlcatel-Lucent vernacular). The paging

radius can be specified per sector.

Call Processing PagingDistance based paging operation

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-65

Page 474: 1xev-Do Rf Engineering

Deriving Route Update Message distance

Message distance

As the AT moves through an area it does distance based RUMs at cells.

The AT eventually stops. When a call is to be delivered to the AT, the last RUM cell is

paged plus all of the cells within the paging radius of the last RUM cell.

Thus, every cell/sector needs to have a RUM distance and a paging radius provisioned for

it. If these distances are minimized, fewer sectors will be paged.

Reverse link access channel occupancy has to be considered when minimizing the RUM

distance (smaller RUM distances imply more distance based RUMs on the precious

reverse link access channel).

�ote that in 2 dimensions the # of RUMs scales linearly with RUM distance, while the #

of cells paged scales as the square of RUM distance.

Route Update Request distance graphic

The following graphic shows the paging radius used for updating as an AT moves.

RouteUpdateMessagedistance

Moving AT

Call Processing PagingDeriving Route Update Message distance

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-66 401-614-323Issue 16 October 2009

Page 475: 1xev-Do Rf Engineering

Minimum RUM Distance

Factors affecting the minimum RUM distance include the following:

• Due to RF fluctuations, stationary ATs will toggle their primary sector between two or

more nearby sectors.

• If the RUM distance for a cell is made too small, we will get distance based RUMs

from stationary ATs.

Thus we can define a minimum RUM distance for a sector such that stationary ATs do not

cause distance based RUMs.

The minimum RUM distance can be determined offline from PCMD data.

• examine the final primary sector and the initial primary sector from subsequent

sessions (of one AT) spaced somewhat closely in time.

• take the first order assumption that all ATs are stationary (90% true), when the final

and initial sectors are different, they represent the case of a stationary AT toggling its

primary sector.

• record the frequency of occurrence of all pairs in a matrix

Call Processing PagingDeriving Route Update Message distance

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-67

Page 476: 1xev-Do Rf Engineering

QoS paging with DOS

Overview

Data Over Signaling is a standardized procedure designed to deliver small amounts of

data over the control channel (FID 12078.36) to reduce latency for signaling applications,

and to provide short message service in the EV-DO network. Data Over Signaling (DOS)

delivery and the relationship to QoS Paging Strategies and Enhanced Idle State are

presented in this section.

�ote:DataOverSignaling and DataOversignalingAck are TIA-856A defined message

names.

Data Over Signaling divisions

Data Over Signaling is further divided into two scenarios.Mobile Originated (MO) DOS

involves the mobile sending DOS to the Access �etwork. The Access �etwork Receives

DOS on the Access Channel and forwards the data on the associated A10 connection.(FID

12078.12)Mobile Terminated (MT) DOS involves the Access �etwork sending DOS

over the Control Channel received on an A10 connection.(FID 12078.36) QOS Paging

logic applies only in the Mobile Terminated DOS section and is discussed along with

DOS with QoS Paging strategies.

Related information

The following documents provide further information on Data over Signalling:

• 1xEV-DO Feature Provisioning Guide, 401-614-413

• Alcatel-Lucent CDMA2000 1xEV-DO �etwork Configuration Parameters Guide,

401-614-324

Restrictions

As is the case with the QoS Paging strategy, the DOSMethod is a per QoSProfile ID

strategy.

Provisioning enforces the following restrictions with QoS Paging areas and DOS

methods.

• Direct DOS method can O�LY be used for either Last_Active_Set or Distance_Based

paging areas

• Mixed DOS and RUR DOS methods cannot be used with Last_Active_Set, but can

O�LY be used with either Last_Seen_R�C or Distance Based paging areas.

• �eighbor_R�C and R�C_Group areas can not be used for any DOS method.

�ote:QoS Paging and Enhanced Idle state can be activated as features independently.

DataOverSignaling requires QoS activation.

Call Processing PagingQoS paging with DOS

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-68 401-614-323Issue 16 October 2009

Page 477: 1xev-Do Rf Engineering

Each standalone case is covered. However, when any two features are simultaneously

active, they are no longer separate and function in an integrated fashion.

DOS delivery criteria

To attempt DOS delivery the following conditions must be satisfied. If these conditions

are not satisfied, the DOS attempt is not performed.

• ATMust be in the "Dormant" state.

• Size of “higherlayerpacketdata” < Max_lengthhigherlayerpacket.

• The A10 with data pending has QoS Paging Strategy provisioned “Y” for that Profile

ID and DSCP in GRE header equal to translation for the second delivery attempt.

• The value of the SupportRouteUpdateEnchancement attribute negotiated with the AT

is a non-zero (not 0x00) value.

QoS Paging Attempt Logic with DOS Method "R" or "M"

The "R" method (see “DOS Method types” (p. 7-51)) is used to send the

RouteUpdateRequest message to a paging area specified in the QoS Paging attempt. The

"R" method is a good choice to define broad paging areas without flooding those areas

with DOS messages and thus increasing the capacity on the control channel. The "R"

method upon a successful RouteUpdate message will only send the DOS message to the

responding sector. Therefore, an extra step is added even in this case, but control channel

bandwidth is protected.

For both the "R" and the "M" case the paging area is required since it tells the system

where the RouteUpdateRequest message is sent. It also allows for an adjustment in

paging strategy with a change in translations in the field. For "R" and "M", the two

paging area choices are Last Active Set and subnet/R�C. In both cases, the

RouteUpdateRequest message is sent to the respective paging areas and the Tm_pg_rsp

counter is started. The number of pages counter is incremented and the system waits for

the next event.

The "M" case or mixed DOS case attempts to combine the best of both the "R" and "D"

method. The DOS message is sent to the Last Active Set of the AT, and the

RouteUpdateRequest message is sent to the rest of the Last Seen R�C or to the other

sectors in the Distance Based Tier, which were not in the Last Active Set.

If the RouteUpdateRequest message is received successfully, then the AT will return a

RouteUpdate only message. The RouteUpdate message can be received at any time

during the current or next attempt, so the logic is designed to handle race conditions first

checking the state of pending data and then by making use of the response message or

event received. In this case, the mobiles location is known. If the RouteUpdate message is

not received before Tm_pg_rsp expires, then the next attempt is performed. This logic

continues until the maximum number of attempts is reached or the paging/data delivery

method is successful.

Call Processing PagingQoS paging with DOS

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-69

Page 478: 1xev-Do Rf Engineering

Resource allocation

Overview

Purpose

This section covers resource allocation.

Contents

Traffic Channel Resource Allocation 7-71

RTC Parameters 7-72

Indices and P� offset 7-73

RAB Offset/RAB Length 7-74

Handoff introduction 7-76

Pilot Sets 7-77

Pilot Drop Timer Maintenance 7-78

Active Set Management 7-81

Candidate Set Management 7-85

�eighbor Set Management 7-86

Virtual Soft Handoff 7-89

Support forMultiple 1xEV-DO Carriers - IFHO, FID 8219.11 7-91

Other handoffs 7-97

1xEV-DO Distance Based Handoff (FID 13579.0) 7-99

BroadCast andMultiCast Service (BCMCS) 7-102

Call Processing Resource allocationOverview

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-70 401-614-323Issue 16 October 2009

Page 479: 1xev-Do Rf Engineering

Traffic Channel Resource Allocation

RTC Parameters

When the AT receives the TrafficAssignment message, and its MAC layer returns an

RTC-acquired indication, an open connection state exists between the AT and the RA�. In

multiple carrier systems, if the carrier of the assigned traffic channel (RTC) is not on the

carrier that the AT is currently monitoring, the TrafficAssignment message will identify

the carrier of the assigned traffic channel. The carrier is identified by its channel record

that identifies the channel number and band class. Parameters governing the use of the

currently assigned RTC and the RTC from other sectors that the AT may point to for

subsequent handoff. The parameters for the current RTC are:

• Frame Offset—Assigns one of the 16 time slots within a frame that the AT may start

transmission over the assign traffic channel

• DRC Length— Indicates the number of time slots per frame that the AT may transmit

over its DRC channel

• DRC Channel Gain— Indicates the ratio of DRC channel power gain to reverse

traffic pilot channel gain for currently assign traffic channel

• Ack Channel Gain— Indicates the ratio of Ack channel power gain to reverse traffic

pilot channel gain for currently assign traffic channel.

TrafficAssignment messages

The RTCs from other sectors that the AT may point to for subsequent handoff are

identified in the TrafficAssignment message by their sector pilot P� offset. These RTCs

are on the same carrier as the assigned RTC. The parameters for each RTC handoff

candidate included in the TraffcAssignment message are:

• MAC Index—Walsh code assignment for reverse traffic channel usage on the handoff

RTC candidate

• DRC Cover— Indicates the DRCWalsh code identifying the handoff RTC candidate

sector. The DRC value must be covered by one of eight Walsh codes to point to a

sector (refer to “Description” (p. 7-30))

• Frame Offset—Assigns one of the 16 time slots within a frame that the AT may start

transmission over the handoff RTC

• RAB Offset— Identifies one of the 16 time slots within a frame where the Reverse

Activity Bit (RAB) from the sector identified by DRC cover is being transmitted. The

RAB indicates if the AT should increase or decrease the data transmission rate on the

RTC if selected for handoff.

• RAB Length— Identifies the number of the time slots which the AT should use when

sending the Reverse Traffic Channel activity bit.

Call Processing Resource allocationTraffic Channel Resource Allocation

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-71

Page 480: 1xev-Do Rf Engineering

RTC Parameters

Frame Offset

To minimize processing delay at the base station, the frame offset, sometimes referred to

as the slot index, spreads the RTC transmission from all the ATs in the coverage area over

the entire 16 time-slot frame period. Data transmission from any AT within the base

station coverage can only begin at the start of the time slot assigned by the frame offset

value. The frame offset value is randomly assigned to each AT. As a result, RTC traffic

from different ATs will arrive at the base station at different times.

DRC Length/DRC Channel Gain

The DRC length and DRC channel gain are functional relative values that are inserted

into the system data base via DRC Boost Length (DRCBoostLength) and DRC Channel

Gain (DRCChannelGain) configuration parameters. The DRC length specifies the

number of repetitions of the DRC information transmitted within each frame. When the

DRC length value is 1, the DRC chip sequence is transmitted during each 1.67-ms slot

period, resulting in a 600-Hz update rate. A DRC length value of 2 will repeat the same

information once and provide a 300-Hz update rate. DRC length values of 4 and 8

transmit the same information four times and eight times, respectively, providing an

update rate of 150 Hz and 75 Hz.

Increasing the DRC length increases DRC channel processing gain, enabling transmission

of DRC channel data at less power. At lower power levels, less interference is introduced

in the reverse link environment, resulting in increased capacity to support a greater

number of users. The trade-off from longer DRC lengths is forward link throughput. The

slower the DRC channel information, the less responsive the base station is to changing

AT RF environment conditions. This includes missed opportunities for faster data rates

when the RF environment conditions improve, and retransmission when the RF

environment conditions worsen.

The DRC Channel Gain (DRCChannelGain) parameter indicates the ratio of the power

level of the DRC channel (when transmitted) to the power level of the reverse pilot

channel, expressed as its 2's complement value.

Ack Channel Gain

The Ack channel gain is set by the Ack Channel Gain (AckChannelGain) database

parameter.This parameter, which can be adjusted between -3.0 to +6.0 dB in 0.5-dB steps,

sets the ratio of the power level of the Ack channel (when transmitted) to the power level

of the reverse pilot channel, expressed as it 2's complement value in units of 0.5 dB.

Call Processing Resource allocationRTC Parameters

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-72 401-614-323Issue 16 October 2009

Page 481: 1xev-Do Rf Engineering

Indices and PN offset

MAC Index

The 64 MAC indices defined in the standards that identify 64 Walsh codes with MAC

indices 5 through 63 used to assign reverse link user data traffic channels. Each active

(non-dormant) user is assigned a unique MAC index. Therefore, 59 users are the

maximum number of active users per sector/carrier allowed by the TIA-856A standard.

However, to protect the system due to limitations of the RF environment, hardware, etc.,

the number of users may be restricted by theMaximum �umber of Users Supported

configuration parameter, which can be adjusted between 0 and 59.

The assignment selection of MAC indices always starts from the last index, i.e., 63, and

sequentially works backwards. In other words, the last index is always used first. The

MAC index is used in the QuickConfig message on the control channel to tell the AT if its

reverse channel DRC has been received correctly, and if the forward traffic channel is still

allocated to the AT. The MAC index is also used for reverse link power control by

covering the Reverse Power Control (RPC) bit in the forward medium access control

(MAC) channel (see Figure 3-1, “1xEV-DO Channel Structure” (p. 3-6)) by the

user-assigned MAC index Walsh code.

DRC Cover

The DRC cover identifies the sector for each P� offset included in the TrafficAssignment

message, and is translated by the AT into a 3-bit DRC Cover Symbol (refer to “Data Rate

Control (DRC) Channel” (p. 3-77)). After the traffic channel is assigned, the AT appends

it pilot Active Set with the pilot P�s listed in the TrafficAssignment message. The AT then

monitors the C/I level of all the pilot P�s listed in the active set, and estimates the data

rate that can be supported by the pilot P� having the highest C/I level.This data is

indicated on the reverse DRC Channel. To identify the best serving sector, the AT covers

the value transmitted over the DRC channel with one of eight orthogonal Walsh functions

IW8 , where i is a value between 0 and 7 selected by the 3-bit DRC Cover Symbol.

Call Processing Resource allocationIndices and PN offset

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-73

Page 482: 1xev-Do Rf Engineering

RAB Offset/RAB Length

Introduction

The RAB Offset and RAB values extracted from the TrafficAssignment message define

when and how often the Reverse Activity Bit (RAB) is transmitted from each sector

associated with the pilot P� offset in the ATActive Set. The RAB bit transmitted by each

sector is used control reverse link RF interface by controlling the data rate on its RTC.

When the RF interference marginally increases, the RAB bit instructs each AT that

includes the sector pilot P� offset in its Active Set to reduce its transmission data rate by

one-half. If all of the ATs comply with this request, the RF interference may be reduced

drastically, which is excessive for marginal increase in RF interference, resulting in an

inefficient use of uplink RF resources. To prevent this from occurring, probability

thresholds are established in the ATs, allowing each AT to randomly select if it should

comply with the RAB bit instruction.

RAB Offset

The RAB Offset value is determined by the Reverse Traffic Channel Activity Bit Transmit

Offset (RABOffset) parameter and provides diversity as to when the RAB bit is

transmitted from different sectors. The RAB is transmitted over the reverse activity (RA)

channel, which is a sub-channel of the forward MAC channel (refer to “MediumAccess

Control (MAC) Channel” (p. 3-40)) and is distinguished with a MAC index 4 cove. Each

neighboring sector should be set to have a different RAB offset. Without this offset,

sectors will transmit the RAB bit at the same time, which can lead to data rate limit

cycles, where each complying AT drops its rate and increases its data rate at the same

time. The offset allows for one sector to indicate the drop uplink data rate, permitting

neighboring sectors to reevaluate its influence on the RF interference environment before

deciding whether to transmit 1 or 0 RAB bit.

RAB Length

The RAB Length is set by the Reverse Traffic Channel Activity Bit Transmit Slot Length

(RABLength) parameter which is set between 0 and 3, (where 0 = 8 slots; 1 = 16 slots; 2 =

32 slots; and 3 = 64 slots). For the initial release of 1xEV-DO, only a 0 value (8 slots) is

permitted. The RAB Offset value can take on values from 0 to 7, providing eight

uniformly spaced offsets for RAB transmission within the defined RAB slot length. The

slot for RAB transmission is determined by Figure 7-19, “Equation 2” (p. 7-74):

Figure 7-19 Equation 2

xmitslotRABOffset RABLength

8-----------------------------------------------------------------=

×

Call Processing Resource allocationRAB Offset/RAB Length

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-74 401-614-323Issue 16 October 2009

Page 483: 1xev-Do Rf Engineering

If the RABLength is 64, the eight uniformly-spaced offsets for RAB bit transmission slots,

xmitslot ,are slots 0, 8, 16, 24, 32, 40, 48, and 56. If the RABOffset is 3, the RAB bit

transmission slots, xmitslot ,is 24 (3 x 64 / 8).

Controlling Interference in each Sector

The value of the RAB bit transmitted by each sector is a function of the reverse traffic

interference experienced at the sector.The AT will start its transmission at a low data rate

and may incrementally increase its data rate after every 26.67-ms frame up to a maximum

data rate limit. The maximum data rate limit is established from either a

BroadcastReverseRateLimit or UnicastReverseRateLimit message. If the RAB bit value

from any sector in the AT pilot active set is 0, the AT may double its current transmission

rate, subject to passing a transition probability test. If the RAB bit value from any sector

in the AT pilot active set is 1, the AT may reduce its current transmission data rate by half.

This rate reduction is also subject to the AT passing a transition probability test. In either

case, if the probability test is not passed, the AT transmission data rate remains

unchanged.

The transition probability for each data rate change defines a threshold above which the

data rate change will occur. The threshold for each data rate change is expressed to a

1/255 resolution by an associated transition probability parameter. For example, the

Transition Probability 38k4 to 19k2 (Transition038k4_019k2) parameter establishes the

probability that the AT uses to decrease its transmission data rate by half if its current

transmission rate is 38.4 kbps, and the RAB bit is 1. Each AT generates random number

between 0 and 1, and compares this number with the appropriate probability threshold

selected in accordance with the AT current transmission rate and the value of the RAB bit.

If the random number is greater than the probability threshold, the data transmission is

changed. Increasing a transition parameter, which may be set between 0 and 255,

increases the threshold level, therefore reducing the probability that a data rate change

will occur.

Call Processing Resource allocationRAB Offset/RAB Length

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-75

Page 484: 1xev-Do Rf Engineering

Handoff introduction

Forward Link Handoff — Introduction

Forward link handoff in 1xEV-DO is directed by the AT when the system determines that

a particular sector could provide better service, in the way of faster data rate, than its

current serving sector. Upon monitoring pilot signal strength from the better serving

sector, the AT calculates the highest data rate that can be supported from the sector. Then

the AT identifies this rate in its transmitted data rate control (DRC) channel, which is

directs to the sector. However, before doing this, the AT must be certain that its target

sector has the air resources to serve the AT, and that the sector can quickly tap into the

AT's forward link data stream so to avoid unnecessary delay. To provide this certainty, the

AT must continuously monitor the pilot signal levels from all of its neighboring sectors,

and choose those pilot P� offsets that are strong enough to be potential candidates for

handoff. When potential candidates are identified, the RA� is informed via a message

exchange that transpires between them. As a result, the Evolutionary Controller (EVC) in

the R�C allocates traffic channels and the necessary resources to the target sector so that

it could handle the handoff should the AT direct it to do so.

Call Processing Resource allocationHandoff introduction

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-76 401-614-323Issue 16 October 2009

Page 485: 1xev-Do Rf Engineering

Pilot Sets

Four pilot sets

As described in “Description” (p. 7-30), while in the idle state, the AT tracks its current

acquired pilot and neighboring pilot signal in one of four mutually exclusive pilot sets,

which are reprinted here as follows:

• Active Set: Set of pilot signals associated with the sectors that allocated channel

resources to the AT. Allocation of channel resources means that their associated

sectors are ready to receive and transmit traffic data from and to the AT when the

value its DRC channel points to the sector. In the Idle State, only one pilot exists in

this set, that of the control channel currently serving the AT.

• Candidate Set: Pilot signals that are not in the Active Set, but are received by the AT

with sufficient strength to indicate that they good candidates for inclusion in the

Active Set

• �eighbor Set: Pilot signals that are not in either one of the two previous sets, but are

possibly potential candidates for inclusion in the Active Set

• Remaining Set:All possible pilots on the current channel assignment, excluding the

pilots that are in any of the three previous sets.

Active set

Although four pilot sets are maintained by the AT, only the Act Set is maintained in the

RA� and it's container is transferred to update the ATActive Set via the

TrafficChannelAssignment message.While in the close connection Idle State, the only

pilot P� offset in the Active Set is that associated to the control channel that the AT is

currently monitoring. However, as stated in the previous section, while in the open

connection active state, the AT continuously monitors the pilot signal levels from all of its

neighboring sectors and informs the RA� of potential candidates for handoff. This is

done by including the P� offset of each handoff candidate in the AT's Active Set that is

transferred to the RA� in a RouteUpdate message. After the RA� allocates the resources

to the sector identified by the AT, the RA� places the P� offset in its Active Set and

subsequently, the AT's Active Set is updated via a TrafficChannelAssignment message. As

a result, the AT is free to direct its DRC channel to execute a handoff to any sector having

its pilot P� offset in its Active Set.

Call Processing Resource allocationPilot Sets

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-77

Page 486: 1xev-Do Rf Engineering

Pilot Drop Timer Maintenance

Description

The candidacies for any P� offset (pilot channel) for listing and maintenance in the

Active Set is contingent on its signal strength over a duration defined by the pilot drop

timer, as performed by the pilot drop time maintenance routine. When the AT is assigned

to a traffic channel, a static drop timer time routine, or both static and dynamic drop timer

routines, are performed to insure the contents of the pilot sets remain current with RF

environment conditions. If the drop timer dynamic threshold flag is not set, only a static

test routine, which is similar to the one described in “Description” (p. 7-30) and shown in

Figure 7-28, “IFHO Decision Flow Chart” (p. 7-93), is performed. In the static test, a

pilot drop timer, which counts down from its present PilotDropTimer value the signal

strength of any pilot in the Active and Candidate Sets, becomes less than the value

specified by PilotDrop parameter. If the pilot signal strength increases above the

PilotDrop level before the timer reaches it terminal count, the pilot signal remains in its

present pilot set and the timer is reset. If the timer reaches its terminal count before the

pilot signal strength could increase above the PilotDrop level, the pilot P� offset is

removed from its present pilot set.

Additional parameters

If the drop timer dynamic threshold flag is set, in addition to the static pilot drop timer

maintenance test routine, a dynamic pilot drop timer maintenance test routine is

performed. In addition to using the PilotDrop, PilotThreshold and PilotCompare

parameters described in “Description” (p. 7-30), four more parameters are required. These

parameters are:

• PilotAdd— Entered into the data base via the Pilot Detection Threshold field ofthe Service Nodes/Pilot Values Instance Page. Indicates the signal thresholdlevel that will qualify a pilot P� offset for Active set inclusion. If the threshold level

is exceeded by a pilot signal not already in the Active Set, the AT generates a

RouteUpdate message, petitioning the RA� to include the pilot P� offset in the

Active Set.

• SoftSlope— Entered into the data base via the SOFT_SLOP field of the ServiceNodes/Pilot Values Instance Page. Value of the slope used to determine thedynamic PilotAdd and PilotDrop thresholds.

• AddIntercept— Entered into the data base via the Sectors/Pilot Values InstancePage. An intercept value used to determine the dynamic PilotAdd threshold.

• DropIntercept— Entered into the data base via the Sectors/Pilot Values InstancePage. An intercept value intercept used to determine the dynamic PilotDropthreshold.

Call Processing Resource allocationPilot Drop Timer Maintenance

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-78 401-614-323Issue 16 October 2009

Page 487: 1xev-Do Rf Engineering

Dynamic Pilot Drop Threshold

When the dynamic pilot drop timer maintenance test routine is performed, PilotAdd and

PilotDrop thresholds are dynamically adjusted based on the aggregate signal strength of

the all the pilots in Active Set. The illustration in Figure 7-20, “Dynamic Pilot Drop

Threshold” (p. 7-79) shows how the dynamic pilot drop threshold (Eb/�o) depends on the

quality of the Active Set (PSi).

Active set sort

The AT sorts the pilots in the Active Set in order of increasing signal strengths, i.e., PS1 <

PS2 <... < PSA , where A is the number of the pilots in the Active Set. The pilot drop

timer is then started whenever the strength, PSi, of pilot i satisfies the following

inequality:

If the above inequality is satisfied, the pilot drop timer starts counting down from the

PilotThreshold count and will not stop until either the pilot signal strength (PSi ) increases

so that the inequality is not satisfied, or terminal count is reached. If the inequality is not

satisfied before terminal count is reached, the timer is reset and the pilot P� offset

Figure 7-20 Dynamic Pilot Drop Threshold

PSi

E /Nb o

Figure 7-21 Inequality 1

<10 log10

(PSi) < max

SolftSlope

8

10 log10 PS

j+

DropIntercept

2

PilotDrop, -

2

j>i

i = 1, 2....NA

Σ

Call Processing Resource allocationPilot Drop Timer Maintenance

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-79

Page 488: 1xev-Do Rf Engineering

remains in its current set. If the timer terminal count is reached first, the pilot P� offset is

removed from its current set.

Call Processing Resource allocationPilot Drop Timer Maintenance

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-80 401-614-323Issue 16 October 2009

Page 489: 1xev-Do Rf Engineering

Active Set Management

Description

The maximum number of pilot P� offsets that may be included in the Active Set is six.

Because the Active Set is managed by the route update protocol executed in the

Evolutionary Controller (EVC) in the RA�, each time a status change occur that may

affect contents of the Active Set kept by the AT, the RAM is notified of the change via a

RouteUpdate message.

Adding or Dropping a PN Offset To or From an Active Set

When a pilot P� offset is to be added to or dropped from the Active Set, the sector

associated with the pilot P� offset must be notified of the action. This notification, which

is included in the RouteUpdate message, is required so that a traffic channel may be

allocated when the P� offset is added, or de-allocated when the P� offset is dropped.

Also included in the RouteUpdate message are the pilot P� offsets, pilot signal strengths,

and drop time status for every pilot P� offset in the Active Set and Candidate Set. This

allows the EVC to make the appropriate adjustments to its Active Set.

Adding A Pilot PN to the Active Set

The principle exchange of messages and commands that are required when a pilot P�

offset is added to or dropped from the Active Set is shown in Figure 7-22, “Adding A

Pilot P� to the Active Set” (p. 7-82). This figure shows the message exchanged when the

AT, currently being served on Sector 1, request to add or drop a pilot P� offset associated

with Sector 2 to or from its Active Set.

Call Processing Resource allocationActive Set Management

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-81

Page 490: 1xev-Do Rf Engineering

Adding A Pilot PN to the Active Set process

If the AT, which is served by Sector 1, wants to add the pilot P� offset for Sector 2 to its

Active Set, it's RouteUpdate message is relayed through Sector 1 to its serving EVC

located in the FMS that defines the subnet. The EVC then requests that Sector 2 allocate a

traffic channel to handle the AT data flow in the event the AT directs it DRC to Sector 2.

If a traffic channel is available and allocated, Sector 2 response appropriately to the EVC.

If the RouteUpdate message was to drop the P� offset from the Active Set, the EVC

would have requested that Sector 2 deallocate the traffic channel. After receiving the

acknowledgment of the traffic channel allocation or de-allocation, the EVC will include

or remove the pilot P� offset associated with Sector 2 from its Active Set and relay a

TrafficChannelAssignment message through Sector 1 to the AT. This message would

appropriately show the inclusion or removal of the pilot P� offset associated with Sector

2 as requested in the RouteUpdate message. The AT will then add or drop the pilot P�

offset to or from its Active Set and respond back to the EVC with a TrafficChannelCom-

plete message.

Figure 7-22 Adding A Pilot PN to the Active Set

AT Sector 1 Sector 2Evolutionary

Controller(EVC)

RouteUpdate messageRouteUpdate message

Traffic Channel Request

Traffic Channel Response

TrafficChannelAssignment messageTCA

TrafficChannelComplete message

Ack Ack

Call Processing Resource allocationActive Set Management

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-82 401-614-323Issue 16 October 2009

Page 491: 1xev-Do Rf Engineering

Conditions for Dropping Pilot PN Offsets from/to the Active Set

Two conditions that cause a pilot P� offset to be dropped from the Active Set are as

follows::

1. The signal strength of the Active Set member drops below the PilotDrop threshold,

initiating drop timer, and does not recover above the PilotDrop threshold before the

drop timer reaches it terminal count

2. A pilot P� offset is added to the Active Set, increasing the number of pilot P� offsets

beyond its maximum of six P� offsets. The pilot P� offset having the lowest signal

level is dropped from the set.

Conditions for Adding Pilot PN Offsets from/to the Active Set

The conditions for adding P� offsets to the Active Set depend on whether the dynamic

threshold flag is set. If dynamic threshold flag is not set, a P� offset is added to the

Active Set if either of the following occurs:

• The signal strength of a pilot P� offset in the �eighbor Set or Remaining Set pilot is

greater than the threshold set by the PilotAdd parameter

• The signal strength of a pilot P� offset in the Candidate Set is greater than the value

specified by PilotCompare above an Active Set pilot.

Dynamic thresholds

Dynamic thresholds are used to dynamically adjust the PilotAdd and PilotDrop thresholds

based on the aggregate signal strength of all the signals in the Active Set. If dynamic

threshold flag is set, a P� offset is added to the Active Set if any one of the following

occurs:

• The signal strength of a pilot P� offset in the �eighbor or Remaining satisfies Figure

7-23, “Inequality 2” (p. 7-83):

where the where the summation is performed over all of the pilot P� offsets in the Active

Set (AS)

• The signal strength of a pilot P� offset member Candidate Set pilot satisfies Figure

7-24, “Inequality 3” (p. 7-84):

Figure 7-23 Inequality 2

>10 log10

(PS) > maxSolftSlope

8

10 log10 Σ PS

i+AddIntercept

2

PilotAdd, -

2i∈AS

Call Processing Resource allocationActive Set Management

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-83

Page 492: 1xev-Do Rf Engineering

where the where the summation is performed over all of pilot P� offsets in the Active Set

(AS).

Figure 7-24 Inequality 3

>10 log10

(PS) >

SolftSlope

8

10 log10 PS

i +AddIntercept

2i∈ASΣ

Call Processing Resource allocationActive Set Management

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-84 401-614-323Issue 16 October 2009

Page 493: 1xev-Do Rf Engineering

Candidate Set Management

Conditions to move offset from active to candidate set

The maximum number of pilot P� offsets that may be included in the candidate set is also

six. The set may consist of pilot P� offsets that were former members of either the

�eighbor Set or Remaining Set whose signal strengths exceeded the threshold level set

the PilotAdd parameter. The Candidate Set may also consist of pilot P� offsets that were

dropped from the Active Set for one of two reasons, depending on whether the drop timer

dynamic threshold flag is set:

• When the drop timer dynamic threshold flag is not set and the signal strength of the

Active Set member drops below the PilotDrop threshold. At this time, the drop timer

is initiated. The pilot P� offset is dropped from the Active Set and added to the

Candidate Set if its signal strength does not recover above the PilotDrop threshold

before the drop time reaches its terminal count.

• When the drop timer dynamic threshold flag is set and the signal strength of the

Active Set member drops below the PilotDrop threshold, resulting in initiating drop

timer. The pilot P� offset is dropped from the Active Set and added to the Candidate

Set if its signal subsequently recovering above the PilotDrop threshold, but Figure

7-21, “Inequality 1” (p. 7-79) remains satisfied throughout the drop timer count

period.

Conditions that cause a pilot PN offset to be deleted

Three conditions that cause a pilot P� offset to be deleted from the Candidate Set: are as

follows

1. The pilot signal strength increases so as to be added to the Active Set.

2. The pilot signal strength decreases so as to fail the drop timer test.

3. A pilot P� offset is added to the Candidate Set, increasing the number of pilot P�

offsets beyond its maximum of six P� offsets. The pilot P� offset having the lowest

signal level is deleted from the set.

Call Processing Resource allocationCandidate Set Management

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-85

Page 494: 1xev-Do Rf Engineering

Neighbor Set Management

Description

The maximum number of pilot P� offsets that may be included in the �eighbor Set is 31.

This number was increased from 20 to accommodate Support forMultiple 1xEV-DO

Carriers - IFHO, FID 8219.11 which is introduced in release R26.0. When the AT enters

the open connection state, the �eighbor Set is initialized to the pilot P� offset that is

received in the �eighborList message transmitted over the forward traffic channel. The

message informs the AT of its serving sector neighbor; their pilot P� offsets and CDMA

channel number, pilot search window size, and search window offset. Subsequent

�eighborList messages are transmitted as the AT moves to keep the AT up to date on

neighboring sectors. As the AT is mobile and the signal strengths of P� offsets in the four

pilot sets are continuously monitored, P� offsets move in and out of the neighbor set.

Conditions for the P� offsets to be moved back into the �eighbor Set are:

• The pilot was deleted from the Active Set because the pilot drop timer reached its

terminal when the drop timer dynamic threshold flag is set.

• The pilot drop timer of a pilot in the Candidate Set expires.

• The pilot was a member of the Remaining Set, and it was listed in a newly received

�eighborList message.

PN offset is deleted from the Neighbor Set

A pilot P� offset is deleted from the �eighbor Set when that P� offset is moved to either

the Act Set or the Candidate Set, or if the P� offset continuous stay in the �eighbor Set

exceeds the limit set by the �eighborMaxAge parameter.

NeighborList Message

Each time a new �eighborList message is received, the AT adds pilot P� offsets listed in

the message in the order they are listed to the �eighbor Set. If because of new neighbor

list entries the number of P� offsets in �eighbor Set is more than 20, the P� offsets with

the longest continuous �eighbor Set residency are dropped until the number of members

in the set is 20. The maximum period that a long continuous �eighbor Set resident can

remain in the �eighbor Set is determined by the �eighborMaxAge parameter value. With

the exception of pilot P� offsets entering from the Remaining Set, an age counter is set to

zero each time a P� offset enters or re-enters the �eighbor Set. The age counters are

advanced each time a new �eighborList message is received.

Neighbor List Selection Algorithm

The Evolution Controller (EVC) uses a neighbor list selection algorithm to assemble a

neighbor list of pilot P� offsets that may most effectively service the AT. This algorithm

prioritizes the P� offsets in the Active Set by pilot signal strength. The highest priority is

Call Processing Resource allocationNeighbor Set Management

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-86 401-614-323Issue 16 October 2009

Page 495: 1xev-Do Rf Engineering

given to the P� offset having the strongest signal strength, and the other pilots are ranked

accordingly. A list of neighboring P� offsets is complied for each P� offset in the Active

Set. For example, if the three P� offsets in a particular Active Set are ranked as P�

offsets 10, 42, and 123, where P� offset 10 is listed with the high priority, each P� offset

would sponsor a list neighboring P� offset, as shown in Figure 7-25, “�eighbor List

Ranking” (p. 7-87).

Neighbor List Ranking description

The neighbors on the three sponsored lists are combined into one list and prioritized by

discriminators to identify those neighboring P� offsets most likely to be used by the AT.

This is done to save the AT processing time by eliminating those P� offsets would most

likely not be used by the AT. Pilot P� offsets that are already members of the Active Set

and appear on any sponsored list, such as P� offset 10 that appears on the lists sponsored

by P� offset 42 and P� offset 123, are omitted.Those P� offsets sponsored by the highest

number of Active Set P� offsets are listed first. In the example, P� offset 73 that appears

on all three sponsored list would be listed first. If two or more P� offsets, such P� offset

16 and P� offset 169, have the same number of sponsors, those sponsored by the P�

offset having the highest priority will be listed before the other. In the example, P� offset

16, which is sponsored by P� offset 10, would be listed before P� offset 169. Because

they have the same number of sponsors, Pilot P� offset 20 will be listed before P� offset

203. The combined neighbor will appear as shown in Figure 7-26, “Combined �eighbor

List” (p. 7-88).

Combined Neighbor List

After ranking, if required, the combined neighbor list is truncated to a maximum of 20

entries and then sent to the AT after the handoff is complete.

Figure 7-25 Neighbor List Ranking

PN Offset 10(-5 dB)

PN Offset 42(-6 dB)

PN Offset 123(-7 dB)

PN Offset 73 PN Offset 10 PN Offset 73

PN Offset 42 PN Offset 123 PN Offset 10

PN Offset 16 PN Offset 73 PN Offset 169

PN Offset 20 PN Offset 169 PN Offset 16

PN Offset 202

Call Processing Resource allocationNeighbor Set Management

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-87

Page 496: 1xev-Do Rf Engineering

Figure 7-26 Combined Neighbor List

Neighbor List

PN Offset 73

PN Offset 16

PN Offset 169

PN Offset 20

PN Offset 202

Call Processing Resource allocationNeighbor Set Management

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-88 401-614-323Issue 16 October 2009

Page 497: 1xev-Do Rf Engineering

Virtual Soft Handoff

Description

A soft handoff occurs when a mobile leaves the domain of one sector and enters the

domain of another. During the soft handoff period, the mobile is receiving data from both

sectors. In 1xEV-DO, even though the AT is monitoring all Active Set pilots, it receives

data from only one forward link at any one time from a single sector that is associated

with one of the P� offsets in the Active Set. Because when the AT selects a new sector by

pointing its DRC to the new sector, air and data connection resources are already

allocated for the handoff, the type of handoff that occurs is called a virtual soft handoff.

Figure 7-27, “Virtual Soft Handoff” (p. 7-89) illustrates a virtual soft handoff from Sector

1 to Sector 2.

Virtual Soft Handoff diagram

Figure 7-27 Virtual Soft Handoff

AT Sector 1 Sectior 2 RNC

DRC

Data PacketsFrame

DRC

FrameData Packet

Flush Buffer

Forward Data Request

Forward Data Request

Forward Stop Indicator

Call Processing Resource allocationVirtual Soft Handoff

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-89

Page 498: 1xev-Do Rf Engineering

Process

As long as the AT directs its DRC channel to Sector 1, the sector issues a Forward Data

Request to the Flexent®Mobility Server (FMS), instructing its controlling EVC to

forward the AT's Data Packets. The data packs are then transmitted to the AT in frames

from Sector 1. When the AT redirects its DRC channel to Sector 2, Sector 2 issues a

Forward Data Request to the FMS, and Sector 1 sends the EVC a Forward Stop Indicator

identifying the last frame that was transmitted. Upon receiving the Forward Data Request

from Sector 2, the EVC sends a Flush Buffer command to Sector 1, and redirects data

packets through Sector 2.

Call Processing Resource allocationVirtual Soft Handoff

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-90 401-614-323Issue 16 October 2009

Page 499: 1xev-Do Rf Engineering

Support for Multiple 1xEV-DO Carriers - IFHO, FID 8219.11

Introduction

The Support forMultiple 1xEV-DO Carriers - IFHO, FID 8219.11, uses the

multiple-carrier feature, introduced in Release R25.0, to enable 1xEV-DO carrier

inter-frequency handoff (IFHO), which is a hard handoff. This feature is used in areas

where multiple carriers are provided when a different carrier frequency becomes more

attractive than the ATs current carrier frequency. The implementation of this feature

improves session transfer time to provide a smooth transition for real-time applications

such as streaming video and audio when an AT user moves into a sector where the AT's

current carrier frequency is not available. In addition, this feature supports IFHO handoff

to different channel carriers regardless whether the carriers are in the same band or, when

handoff is to another cell, a different band. Translation parameters are provided to limit

the operation of this feature to designated sectors and carriers. When an AT becomes a

candidate for IFHO, the system evaluates RouteUdate information reported by the AT to

determine if IFHO and non-IFHO handoff will be executed. When an IFHO handoff is

determined, one of two types of IFHO handoffs is performed:

• Mobile Assisted IFHO - The handoff candidate is selected as a function of the AT

measured pilot P� offset signal strength values on its current carrier compare to IFHO

target carriers

• Directed IFHO - The handoff candidate is selected as a function of the AT measured

pilot P� offset signal strength values on its current carrier compare to a threshold

translation value

AT Class

The IFHO evaluation and determination method used is based upon the AT class. In the

context of this discussion, three classes of ATs to consider are as follows:

• First AT class: ATs that are capable of off-frequency monitoring during a connection

• Second AT class: ATs that are not capable of off-frequency monitoring but support

AttributeOverride messages from the R�C

• Third AT class: ATs that are not capable of off frequency monitoring and do not

support AttributeOverride messages

Off-frequency monitoring during a connection refers to the AT's ability to tune away from

its current carrier, during a connection, to monitor different channels. The off-frequency

monitoring ability allows mobile-assisted IFHO for the first AT class. Support for

AttributeOverride messages allows directed FHO processing for the second AT class.

However IFHO can not be executed on the third AT class. In this case, same channel

soft/softer handoff processing is performed. There are not substantial numbers of third AT

class users.

Call Processing Resource allocationSupport for Multiple 1xEV-DO Carriers - IFHO, FID 8219.11

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-91

Page 500: 1xev-Do Rf Engineering

The AT class is determined by the R�C based upon information received from

RouteUpdate messages transmitted by the AT.Mobile-assisted IFHO processing will be

used if the RouteUpdate messages contain pilot P� offset signal strength values from

carriers other than the ATs current carrier, indicating that the AT is capable of

off-frequency monitoring. In the absence of pilot P� offset signal strength values from

other carriers, the R�C will first determine if the AT supports AttributeOverride

messages, and if so, the AT is a candidate for directed IFHO processing. If not, the AT

will be a candidate for either the same channel soft/softer handoff processing or the

current AT carrier is dropped and the AT re-establishes connection on a new carrier.

IFHO Benefit

Off-frequency monitoring during an active connection causes throughput degradation

because the AT periodically tunes away from its current carrier to monitor other carriers.

However, in areas where multiple 1xEV-DO carriers are available, the throughput lost is

compensated with improved session transfer time and end-user experience that IFHO

offers. Because this benefit can only be realized in areas serviced by multiple 1xEV-DO

carriers, IFHO processing is limited to those sectors designated IFHO-enabled sectors. An

IFHO-enabled sector is designated so when the Inter Frequency Handoff (IFHO) Enabled

translation parameter for the sector is set to yes. This translation should only be set when

at least one IFHO target carrier exists within the sector.

Decision Process

A flowchart showing the decision making process for this feature is shown in Figure 7-28,

“IFHO Decision Flow Chart” (p. 7-93). The AT will routinely transmit a RouteUpdate

message to report the contents of its Active Set. When a handoff is required and the

Active Set identified an IFHO-enabled carrier, an IFHO evaluation is initiated. If the

Active Set does not identify an IFHO-enabled carrier, either multiple 1xEV-DO carriers

are not present in the AT's environment, or IFHO is restricted. Therefore, IFHO

processing, which in this case, is unnecessary, is not permitted. Therefore, AT will

perform a soft/softer handoff.

Call Processing Resource allocationSupport for Multiple 1xEV-DO Carriers - IFHO, FID 8219.11

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-92 401-614-323Issue 16 October 2009

Page 501: 1xev-Do Rf Engineering

Neighbor List

When an IFHO-enabled carrier is reported in a RouteUpdate message, different channel

neighbors, which are neighboring sectors with different 1xEV-DO carrier frequencies, are

included in the �eighbor List sent to the AT. The number of allowed neighbor entries on

Figure 7-28 IFHO Decision Flow Chart

Call Processing Resource allocationSupport for Multiple 1xEV-DO Carriers - IFHO, FID 8219.11

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-93

Page 502: 1xev-Do Rf Engineering

the �eighbor List, which is controlled by theMaximum Entries in �eighbor List Sent to

AT translation is increased from 20 to 31, to accommodate the Support forMultiple

1xEV-DO Carriers - IFHO feature. The number of IFHO target carriers that may be added

to the �eighbor List is limited by the value of theMaximum Different Channel Entries in

�eighbor List Sent to AT translation parameter, which has a 0 to 12 range. If the full range

is not utilized, the remaining empty slots may contain AT current (same) channel

neighbor.

Two additional parameters are provided to enter the IFHO target carriers on the �eighbor

List:

• Inter Frequency Handoff (IFHO) Target Band Class to identify the IFHO target

carrier band class, which are:

– (0) Cellular 850

– (1) PCS 1900

– (4) Korea PCS 1800

– (5) �MT 450

– (6) China 2100

• Inter Frequency Handoff (IFHO) Target Channel �umber to identify the IFHO target

carriers

In addition to identifying IFHO target carriers on the �eighbor List, an AttributeOverride

message is sent to the AT to modify the Pilot Drop Threshold and Pilot Drop Timer

parameters. The Pilot Drop Threshold is raised and the Pilot Drop Timer parameter is

shortened so that the AT will report signal strength measurements for pilot P� offset

signals at an earlier stage (time) than normally for non-IFHO call processing. The earlier

pilot P� offset signal strength measurement information is reported in the RouteUpdate

message and allows the system time to determine if IFHO is permitted and, if so, does

handoff evaluation and processing for both IFHO and non-IFHO scenarios.

Non-IFHO Soft/Softer Handoff on Third Class ATs

The AT should respond and acknowledge the AttributeOverride message in a

RouteUpdate message. In the event the AT does not respond in a timely manner after the

AttributeOverride is sent, the R�C will send a ResetReport message to trigger a

RouteUpdate message. Then the R�C waits for a ResetReportTimer interval for the AT to

reply with a RouteUpdate message before sending the ResetReport message. The

ResetReportTimer interval is established by ResetReportTimer interval for RUMs

(ResetReportTimer) translation parameter and has a two-second default value. If the AT

fails to respond to the AttributeOverride message in it's RouteUpdate report, the R�C will

assume that the AT does not support AttributeOverride and the AT is within the third AT

class. In this case, the AT is relegated to perform a non-IFHO soft/softer handoff.

Depending on the AT and how programmed, the AT may drop its connection and

reconnect to a stronger carrier.

Call Processing Resource allocationSupport for Multiple 1xEV-DO Carriers - IFHO, FID 8219.11

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-94 401-614-323Issue 16 October 2009

Page 503: 1xev-Do Rf Engineering

Mobile-Assisted IFHO

Mobile-assisted IFHO evaluation/processing is performed when the RouteUpdate

messages contain pilot P� offset signal strength values from carriers other than the ATs

current carrier, indicating that the AT is capable of off-frequency monitoring. Two tests

are performed to determine if mobile-assisted IFHO hard handoff is to be executed. In the

first test, the strongest pilot P� offset signal strength on the AT's current carrier is

compared with the strongest pilot P� offset signal strength among all IFHO target carriers

that are on the �eighbor List. The first test is passed if the strongest pilot P� offset signal

strength on the AT's current carrier (StrgstP�offsetCC ) is less than the strongest pilot P�

offset signal strength among all IFHO target carriers (StrgstP�offsetIFHO ) plus a positive

differential off-set threshold (StrgstDiffoffset ). The off-set threshold value is set through the

Strongest DiffChan/SameChan Signal Differential for IFHO translation, which may be set

between 1.0 to 7.0 dB in increments of 0.5 dB.

If this test passes, the second test is performed. In the second test, the combined pilot P�

offset signal strength values of all monitored IFHO target carriers is compared with the

combined pilot P� offset signal strengths of all carriers monitored on the AT's current

carrier. The second test is passed if the combined pilot P� offset signal strengths of all

monitored IFHO target carriers (P�offsetIFHO ) is equal to, or greater than, the combined

pilot P� offset signal strength values monitored on the AT's current carrier (P�offsetCC )

plus a positive off-set threshold (Cmbndoffset ). The off-set threshold value is set through

the Combined DiffChan/SameChan Signal Strength Differential for IFHO translation,

which may be set between 0.0 to 7.0 dB in increments of 0.5 dB.

If both tests pass, the Mobile-Assisted IFHO can be executed. If either test fails, IFHO

hard handoff is prohibited and the AT is relegated to perform soft/softer handoff.

Directed IFHO

Directed IFHO evaluation/processing is performed when the RouteUpdate messages do

not contain pilot P� offset signal strength values from carriers other than the ATs current

carrier. As described for mobile-assisted FIHO, two tests are perform for directed IFHO

evaluation. Because the absence of other carriers indicates that the AT is not capable of

off-frequency monitoring, a different set of comparisons from the one described above for

mobile-assisted IFHO is applied to facilitate inter frequency handoff. In the first test, the

combined pilot P� offset signal strength value of all carriers from the IFHO-enabled

StrgstPNoffsetCC StrgstPNoffset IFHO StrgstDiffof fset+<

PNoffset∑ IFHOPNoffset∑ CC

Cmbndoffset+≥

Call Processing Resource allocationSupport for Multiple 1xEV-DO Carriers - IFHO, FID 8219.11

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-95

Page 504: 1xev-Do Rf Engineering

sector that are in the ATs Active Set is compared with the sum of all other pilot P� offset

signal strength values that are monitored by the AT. The first test is passed if the

combined pilot P� offset signal strength value of all carriers from the IFHO-enabled

sector that are in the ATs Active Set (P�offsetIFHO-Active Set ) is greater than sum of all other

pilot P� offset signal strength values that are monitored by the AT (P�offsetAll Other ).

If the first passes, the second test is performed. In the second test, the combined pilot P�

offset signal strength value of all carriers from the IFHO-enabled sector that are in the

ATs Active Set is compared with a threshold value set by the PilotP� Signal Strength

Threshold for Inter Frequency Directed Handoff translation parameter. The second test is

passed if the combined pilot P� offset signal strength value of all carriers from the

IFHO-enabled sector that are in the ATs Active Set (P�offsetIFHO-Active Set ) is less than the

directed IFHO threshold value(Directed IFHO thrsh ) set by the PilotP� Signal Strength

Threshold for Inter Frequency Directed Handoff translation parameter.

If both tests pass, directed- IFHO can be executed. If either test fails, IFHO hard handoff

is prohibited and the AT is relegated to perform soft/softer handoff.

PNoffsetIFHO Act ivesSe t�∑ PNoffsetAllOther∑>

PNoffsetIFHO ActiveSet–∑ DiretedIFHO t h r sh<

Call Processing Resource allocationSupport for Multiple 1xEV-DO Carriers - IFHO, FID 8219.11

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-96 401-614-323Issue 16 October 2009

Page 505: 1xev-Do Rf Engineering

Other handoffs

Inter-PCF Handoff

The Flexent®Mobility Server (FMS) contains four primary EVCs and four backup

EVCs. The data traffic handled by each on-line EVC is connected to the Packet Data

Service �ode (PDS�) through the Pack Control Function (PCF). Each EVC services a

single subnet which consists of up to eight base stations. A call handoff from a sector

serviced by the PCF in one subnet to a sector serviced by a different PCF in another

subnet, regardless of whether the PCF is on the same or different FMS frame, is called an

inter-PCF handoff. This handoff will always be controlled by a single EVC.

Reverse Link Handoff

Although in IS-95 forward and reverse link soft handoff occur simultaneously, in

1xEV-DO soft or softer handoff only applies to the reverse link, and the mechanism in

which soft and softer handoffs are implemented are similar. Soft and softer handoffs are

permitted in CDMA if the handoff sectors are operating on the same channel frequency

currently in use by the mobile. In a typical soft handoff scenario, the mobile establishes

communication with a new antenna face, on the same sector of a new sector without

breaking the connection with its current antenna face. This diversity with two or more

antenna faces will occur throughout the handoff period, which is the period that the

mobile remains in the area to received discernible data from the antenna faces within the

soft handoff theater (overlapping boundaries among the antenna faces).

In 1xEV-DO, reverse link handoff may occur when the AT directs its DRC channel to a

new antenna face, prompting a reverse link soft handoff scenario between the current

antenna face and the handoff candidate antenna face. Duplicate data packets received by

the RA� from the soft handoff diversity are discarded by the Radio Link Protocol (RLP)

operating at the airlink Application Lay. The RLP performs frame selection on the reverse

link. When an AT is in soft handoff, all the reverse link legs will send frames to the RLP.

When the RLP receives multiple copies of the same frame, the RLP selects a frame that

successfully passes the CRC (Cyclic Redundancy Check). Other copies of that frame are

discarded.

For open connections in soft handoff with sectors that are controlled by the same or by a

different FMS frame, the same EVC always controls the connection. The control can be

changed only when the AT re-registers with a new EVC under a different FMS.

Re-registering occurs only when the AT is in the dormant mode.

During softer handoff, which occurs when handoff is between antenna faces on the same,

the same forward link and reverse link modems are used. The power control bits for the

softer handoff legs are combined. In other words, the modem makes one decision for the

up or down power control bits sent on the forward link power control channel.

Call Processing Resource allocationOther handoffs

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-97

Page 506: 1xev-Do Rf Engineering

Handoff Between 1xEV-DO and 3G-1X Systems

A hybrid AT supports both 1xEV-DO and 3G-1X calls and is capable of transmitting and

receiving data on the 1xEV-DO carrier and making voice calls, and transmitting and

receiving data on the IS-2000 system.

The frequency change between the 1xEV-DO system and the 3G-1X system is performed

by the hybrid AT. �o network involvement exists; in fact, the network is not aware of any

switch.

For example, if a hybrid AT is in the middle of transmitting data on the 1xEV-DO system,

when the AT receives a page for a voice call, the AT could switch to the 3G-1X system to

receive the voice call if the user chooses to do so. The 1xEV-DO system would not know

that the AT had left the 1xEV-DO system and gone to the 3G-1X system for a voice call,

because the AT does not send any indication back the 1xEV-DO system. The 1xEV-DO

system would finally determine that the reverse link is lost or that the Dormancy Timer

has expired; the 1xEV-DO system would release the connection. The 3G-1X system

would not know that the AT has just broken a connection with the 1xEV-DO system for

this voice call.

The hybrid AT is able to receive a Page message when on the 1xEV-DO system because

the AT is in slot-mode operation with the 3G-1X network. The AT will “wake up” in its

designated 3G-1X slot to monitor the 3G-1X paging channel. If the AT is on the

1xEV-DO traffic channel, the AT may send a null DRC to indicate that it does not want to

receive any data from the network while monitoring the 3G-1X paging channel. If no

page message for the AT exists on the 3G-1X system, the AT would come back to the

1xEV-DO system to resume its data connection by pointing a non-null DRC to a sector. If

a page message for the AT is sent, the AT would stay in the 3G-1X system to continue call

setup procedures.

Call Processing Resource allocationOther handoffs

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-98 401-614-323Issue 16 October 2009

Page 507: 1xev-Do Rf Engineering

1xEV-DO Distance Based Handoff (FID 13579.0)

Purpose

Interfrequency handoff (IFHO) of active users (FID 8219.11) uses one of two techniques,

depending on the AT's capabilities. Either technique can result in a same-band,

cross-carrier or a cross-band handoff.

• Mobile Assisted IFHO

• A� Directed IFHO

FID 13579.0 (1xEV-DO Distance-Based Handoff) accommodates carrier coverage

differences by incorporating distance thresholds duringA�-directed IFHO. This feature

provides the following advantages:

• A per-service-node or per-sector option to turn off MAIFHO

• Distance-based A�-Directed IFHO

• Adjustment of distance measurements to account for AT slewing of the reference pilot

timing after a hard handoff.

• A validity check for distance measurements.

• Per sector-carrier views of RF parameters related to handoff and search windows.

Turning off MAIFHO per service node or per sector

Prior to FID 13579.0,MobileAssisted (AT-Directed) IFHO applies to any AT that

supports Off Frequency Search (OFS) and reports different channels in the Route Update

Message. If different channels are reported in the RUM, the A� evaluates the AT for

soft/softer handoff on the same channel and then for AT directed IFHO. When MAIFHO

is turned off for a sector, all IFHOs from that sector areA�-directed IFHOs .

Likewise, when MAIFHO is turned off for a service node, all IFHOs from that service

node are A�-directed IFHOs.

MAIFHO is then not evaluated, even for ATs that support OFS and report different

channels in the RUM. When a RUM is received, the A� evaluates the AT for same

channel soft/softer handoff and then for A�-directed IFHO.

Call Processing Resource allocation1xEV-DO Distance Based Handoff (FID 13579.0)

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-99

Page 508: 1xev-Do Rf Engineering

Distance-based AN-Directed IFHO

Upper and lower handoff distance thresholds are specified for each IFHO-enabled sector

or sector-carrier. The following table indicates the criteria used to determine a handoff.

These measurements take into account the distances for each IFHO-enabled active set leg

and compare that against their own respective thresholds.

If the one-way distance is ... then the handoff is ...

less than the lower distance threshold for any

IFHO-enabled active set leg

disallowed.

between the lower and upper thresholds for

any IFHO-enabled active set leg

evaluated based on AT measurements of pilot

strength for the current active set.

greater than the upper distance threshold for

all IFHO-enabled active set legs and at least

one such upper threshold is non-zero

forced.

Notes:

1. Distances are computed from round-trip delay measurements.

Other parameters associated with distance based handoff follow::

1. The validation time which is also used to prevent a new directed IFHO within

(validation time) of the last directed IFHO.

This is used to validate RTD measurements and to prevent ping-ponging.

2. The "distance delta limit" which limits how much slewing adjustment can be

performed.

Account for AT slewing of the reference pilot

After a hard handoff, the AT changes the reference pilot immediately, but it slews the

timing to the new reference gradually to facilitate reverse link acquisition at the new cell

site. If the difference in distances to the cells (before and after the handoff) is large, the

measurement of the new distance will be inaccurate. A round-trip delay adjustment is

computed that accounts for the difference in the lower handoff distance thresholds before

and after the IFHO and the time since the IFHO. Slew rate adjustment of the round-trip

delay measurement at the new cell minimizes handoff toggling between sectors.

Distance measurements validity check

This validity of distance measurements is determined by comparing successive round-trip

delay measurements. Rapid changes in round-trip delay measurements imply

unreasonably high AT speeds (after adjusting for slewing). In these cases, the

corresponding distance measurements are invalid and no further hand-off evaluation will

be performed for this RUM.

Call Processing Resource allocation1xEV-DO Distance Based Handoff (FID 13579.0)

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-100 401-614-323Issue 16 October 2009

Page 509: 1xev-Do Rf Engineering

Per sector-carrier views

FID 13579.0 adds a per sector-carrier view (in addition to the existing per sector view) of

various RF parameters. Those parameters are reported in the Configration Request

Message or the Sector Parameters Message:

• Included in the Route Update Protocol of the Configuration Request Message:

– Pilot Detection Threshold Same Channel

– Pilot Drop Threshold Same Channel

– Drop Timer Value Same Channel

– SOFT_SLOPE Same Channel

– Add Intercept for Same Channel

– Drop Intercept for Same Channel

– Active Set Versus Candidate Set Comparison Threshold Same Channel

– Search Window Size for Active/Candidate Set (P� Chips)

– Search Window Size for Remaining Set (P� Chips)

– "Distance Estimate Delta Limit" on a per sector or per sector-carrier bases, used to

calculate slew-compensated round-trip delay values.

– "IFHO Distance Validity Check Period" on a per sector bases, used in round-trip

delay validation.

• Included in the Sector Parameters Message:

– �eighbor Search Window Size (per-carrier)

Customer Control

FID 13579.0 is an optional feature. Customer control of the feature includes the

following:

• A feature enable parameter that controls all parts of FID 13579.0 except as indicated

below

• Control of MAIFHO (on/off) per service-node or per sector.

• Specification of upper and lower handoff distance thresholds forA�-directed IFHOs

per sector or per sector-carrier, for each sector or sector-carrier.

• Per sector-carrier views of handoff and search window RF parameters.

• Control of MAIFHO is not dependent on feature activation status with per

sector-carrier views of RF parameters, which are available even when FID 13579.0 is

disabled.

Call Processing Resource allocation1xEV-DO Distance Based Handoff (FID 13579.0)

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-101

Page 510: 1xev-Do Rf Engineering

BroadCast and MultiCast Service (BCMCS)

Introduction

BCMCS support is provisioned in TIA-856-A, but this service is not part of Rev A and is

planned for R29.0.

The Broadcast and Multicast Service is defined in 3GPP2 specification C.S0054, and

allows a common stream of information to be sent to all, or a definable group of, AT and

3G mobile subscribers in a point-to-multi-point fashion. Examples of point-to-multi-point

broadcasts are:

• Local region weather forecasts

• �ews headlines and sports scores

• Stock market ticker and business headlines

• Subscriber-requested advertisements (to lower subscriber fees)

• Public service and police announcement – such as hurricane and tornado warnings

Certain BCMCS may be conditional and restricted to employees of a company, hospital,

or members of an organization.

BCMCS distribution

The content of the BCMCS broadcast may be received from a third-party content

provider as an IP-based message, via a BCMCS controller application server within the

IMS network, as shown in Figure 7-29, “BCMCS distribution” (p. 7-103). Depending on

the message distribution region, the broadcast message may be sent to one or more Packet

Data Serving �odes for distribution to target R�Cs. In this manner, all of the target R�Cs

are supported by the same information data stream. Each R�C may, in turn, target

specific cells and sectors for the broadcast.

Call Processing Resource allocationBroadCast and MultiCast Service (BCMCS)

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-102 401-614-323Issue 16 October 2009

Page 511: 1xev-Do Rf Engineering

The broadcast message is slot-interlaced (multiplexed) on the forward physical channel

within the 26.66-ms frames, and is identified by a Flow ID. The RA� transmits a

BroadcastOverhead message to identify the message (flow ID) and the physical channel

interlace pattern. The BroadcastOverhead message indicates if the AT is required to

register. This is done for a number of reasons: if the message is transmitted on a different

carrier, causing the AT to switch carriers, the RA� knows where to page the AT if

required; if the RA� does not receive any registration in a particular area it may not need

Figure 7-29 BCMCS distribution

BCMCSContent Provider

(Broadcast Source)

BCMCSController/Server

IPNetwork

Packet Data Serving Node(PDSN)

Packet Data Serving Node(PDSN)

RNCRNC

RNCRNCRNC

RNC

Radio Access Network (RAN)

IMS

Call Processing Resource allocationBroadCast and MultiCast Service (BCMCS)

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-103

Page 512: 1xev-Do Rf Engineering

to broadcast the message in that area. The BroadcastOverhead message also indicates the

data rate. If the broadcast information is sent to neighboring cells and sectors with the

same configuration, the BroadcastOverhead message indicates so, enabling

soft-combining of the broadcast information at sector borders.

If the BCMCS message is directed to a specific subscriber group, the message may be

encrypted; therefore only authorized AT users within the group respond by registering.

Only those ATs have the applicable decrypting capability to retrieve the message.

De-registration may be required when the AT leaves the BCMCS flow to help the RA� to

better manage its radio resources.

BCMCS channel interlace

Because the forward traffic channel uses a four-slot interlace scheme to achieve early

termination, the same four-slot interlace scheme used to transmit four logical channels of

BCMCS massages (four separate BCMCS flows). Unlike traffic directed to one user, the

BCMCS is directed to a group of users and the R�C does not expect acknowledgment for

early termination.As shown in Figure 7-30, “BCMCS channel interlace” (p. 7-104), the

first channel, Channel 0, is transmitted in Slots 0, 4, 8, and 12 within the 26.66-ms frame.

These slots are designated by a two-number channel and slot multiplex pair. For example,

the slots for Channel 0 are identified by multiplex pairs (0, 0), (0, 4), (0, 8), and (0, 12).

The multiplex pairs for Channel 1 are (1, 1), (1, 5), (1, 9), and (1, 13), and so on.

Figure 7-30 BCMCS channel interlace

0 1 2 4 5 6 7 8 9 10 11 12 13 14 153Slot

Forward Traffic Dataor Control Channel

26.66-ms Frame

BCMCS Channel 0, Multiplex components are (0,0) (0,4) (0,8) (0,12)

BCMCS Channel 1, Multiplex components are (1,1) (1,5) (1,9) (1,13)

BCMCS Channel 2, Multiplex components are (2,2) (2,6) (2,10) (2,14)

BCMCS Channel 3, Multiplex components are (3,3) (3,7) (3,11) (3,15)

Call Processing Resource allocationBroadCast and MultiCast Service (BCMCS)

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-104 401-614-323Issue 16 October 2009

Page 513: 1xev-Do Rf Engineering

BCMCS Dynamic Registration Request

Users may request specific messages the are not currently broadcast/multicast. In

response, the AT tries to initiate the requested BCMCS flow by autonomously registering

with the associated BCMCS Flow ID (see Figure 7-31, “BCMCS Dynamic Registration

Request” (p. 7-105)). At this time, the AT sets a timer that is advanced as a function of the

BroadcastOverheadPeriod. The BroadcastOverheadPeriod is equal to a number of

256-slot Control Channel cycles that the RA� uses to determine when to send a

BroadcastOverhead message.

Figure 7-31 BCMCS Dynamic Registration Request

User request specific information -Stock quote, Football game score,Price quote, Weather, etc

AT converts request to an associateFlow ID and sends a BCMCS DynamicRegistration request to initiate aBCMCS flow

AT setstimer

BroadcastOverheadPeriod

AT then monitors themessages

over the Control ChannelBroadcastOverhead

Istimer expired

Did RANrespond with

BroadcastReject

Did RANrespond with

requested flow

Retrieve and print message

Print why BCMCSis not retrieved

Print why BCMCSis not retrieved andreset timer

Yes

Yes

No

No

No

Yes

?

?

?

Call Processing Resource allocationBroadCast and MultiCast Service (BCMCS)

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-105

Page 514: 1xev-Do Rf Engineering

The AT then monitors the BroadcastOverhead messages over the Control Channel to

determine when, or if, the RA� will respond to its Flow ID request. When the RA�

responds to the Flow ID request, the AT stops the timer and retrieves and displays the

BCMCS stream of data. If the RA� does not respond to the request in an allotted time,

the timer times out and the user is informed that the request broadcast/multicast

information is not available.

In certain cases the RA� may respond with a BroadcastReject message. This message

may indicate the reason for rejection, such as BCMCS Flow ID is outdated, BCMCS

Flow ID is unavailable, or Invalid authorization.

Call Processing Resource allocationBroadCast and MultiCast Service (BCMCS)

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-106 401-614-323Issue 16 October 2009

Page 515: 1xev-Do Rf Engineering

Power control

Overview

Purpose

This section covers power control in 1xEV-DO.

Contents

Rev 0 Power control 7-108

Rev 0 Overload control 7-111

Rev A power and overload control 7-114

Leaky bucket control mechanism 7-117

RAB bit load control and RoT 7-120

Call Processing Power controlOverview

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-107

Page 516: 1xev-Do Rf Engineering

Rev 0 Power control

Introduction

Because the base station always transmits at full power in a time slot mode, CDMA

power control is performed on the reverse link only to maximize system capacity and

minimize reverse link interference. Reverse link power control (RPC) effectively controls

the AT transmit power so that the lowest signal power level sufficient to maintain a

desired Frame Error Rate (FER) is received from each user at the base station. When all

ATs transmit at the lowest power required to provide discernible data at the base station,

the sector and cell capacity is maximized. Two algorithms, one providing open loop

power control and the other providing closed loop power control, are used to control the

AT output transmit power.

Open loop power

Open loop control is based on the total signal power received by the AT from all base

stations during a handoff situation. When not in a handoff situation, the strength of the

base-station transmit signal, measured by the AT, is an indication of the distance between

the nearest base station and the AT. Reception of a strong signal from the base station

indicates that the AT is either close to the base station, or has a good RF path to the base

station. In either case, the AT can use less transmitter power to provide a discernible

signal at an acceptable FER at the base station. By reducing its output power, RF

interference to other users in the area is reduced.

Open loop power control is useful when establishing a connection and reacting to large

path loss fluctuations from shadow fading. However, open loop adjustments could cause

overcompensation; hence, open loop control has a relatively slow response. The closed

loop control is faster and will compensate for errors in the open loop control.

Once the AT initiates reverse link traffic channel transmission, the initial mean output

power of the reverse link Pilot Channel is equal to the mean output power used when

transmitting the last access probe on the Access Channel (refer to “Access Mode” (p. 7-7)

).

Closed loop

Closed loop power control is faster than open loop power control, and will compensate

for errors in the open loop control. The closed loop power control is made of an outer

loop control and an inner loop control. The main objective of reverse link outer loop

power control is to maintain the reliability of the reverse link Traffic Channels. The loop

continuously adjusts a Power Control Threshold (PCT) used by the reverse inner loop

power control to achieve an acceptable target frame error rate on the reverse link.

Call Processing Power controlRev 0 Power control

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-108 401-614-323Issue 16 October 2009

Page 517: 1xev-Do Rf Engineering

Outer loop power control

The AT transmits reverse traffic data in the reverse Data Channel, and indicates to the

base station the rate in which the reverse traffic data is transmitted via the reverse rate

indicator channel (RRI Channel). The RRI data transmission is time- shared with the pilot

channel (see Figure 3-25, “Reverse Traffic Sub-Channels” (p. 3-75)), and is transmitted at

full power by the AT to provide reasonable assurance at high probability that valid RRI

data will be received and correctly identified by the base station. When data is being

transmitted, each base station in the Active Set of the AT receives the transmitted traffic

data and tries to decode each data frame in its receiver modem (EVRx).

The receiver modem at each base station that is included in the AT's Active Set decides

whether the quality of each data frame received is good or bad. The quality decisions

made are reported to the outer controller algorithm, which is run by the RLP and

Signaling Manager (RSM) software module on the EVC. The outer loop controller

algorithm then adjusts the level of the PCT threshold level according to the number of bad

and good quality reports it receives.

The decision, indicating bad quality, is rendered when the RRI Channel data indicates a

data rate other than zero, indicating the reverse traffic data is being transmitted, and the

receiver modem cannot validate a good frame. The decision, indicating good quality, is

made if the receiver modem can validate a good frame. Even though the RRI data is

transmitted at full power, a low probability exists that a bad frame quality decision will be

reported if the RRI symbols are misidentified at the base station when no reverse traffic

data is being transmitted. Consequently, the misidentified RRI symbol causes the receiver

modem to try to validate a frame which, by virtue of being non-existent, cannot be

validated.

When the reverse link is in soft handoff, the quality of a received frame reported by one

base station will not necessarily be the same as those reported by other base stations in the

Active Set. The outer loop control calculates the minimum PCT threshold level based on

the quality of the received frames at each sector in the Active Set. This minimum PCT

threshold level is then used at all receiver modems involved in the soft handoff, and is

used by the reverse inner loop power control to achieve an acceptable target frame error

rate on the reverse link.

Inner loop power control

The power control uses the PCT threshold level to determine an acceptable target frame

error rate on the reverse link, and transmits its output to the AT in a continuous stream of

1s and 0s power control pits on the forward RPC (Reverse Power Control) Channel. The

power control bits transmitted on the RPC Channel are covered by one of 59 Walsh codes

(MAC indices) to direct to bit steam to the targeted AT.

Call Processing Power controlRev 0 Power control

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-109

Page 518: 1xev-Do Rf Engineering

If the received quality is above the target threshold, a ‘1' RPC bit is transmitted, causing

the AT to decrease its transmit power. If the received quality is below the target threshold,

a ‘0' RPC bit is transmitted, and the AT increases its transmit power. The AT adjusts the

power level in 1dB or 0.5 dB steps. If softer handoff is being performed, two different

sectors at the same base station are transmitting the same RPC bit. In each slot containing

power control bits, the AT will do diversity combining of the identical RPC Channels and

obtain, at most, one power control bit from each set of identical RPC Channels.

RPC Channel and DRCLock Channel

The RPC Channel and DRCLock Channel are time-division multiplexed and transmitted

on the same MAC Channel. The DRCLock Channel indicates to the AT whether a sector

can send data to an AT if requested by the DRC sent from the AT. If the AT receives a

DRCLock bit that is set to ‘0' from the sector to which points to its DRC, the AT should

stop pointing its DRC at that sector. The RPC Channel is transmitted whenever the

DRCLock Channel is not transmitted. The DRCLock is transmitted with an interval

specified by DRCLockPeriod (default 16 slots).

Because the RPC Channel and DRCLock Channel are multiplexed on the MAC Channel,

the data rate of the RPC is 600 × (1 -1/DRCLockPeriod) bps. Each RPC bit is transmitted

four times in a slot bursts of 64 chips each. One burst is transmitted immediately

preceding and following each pilot burst in a slot (see Figure 3-25, “Reverse Traffic

Sub-Channels” (p. 3-75)).

Call Processing Power controlRev 0 Power control

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-110 401-614-323Issue 16 October 2009

Page 519: 1xev-Do Rf Engineering

Rev 0 Overload control

Introduction

In “Receiver Interference Margin” (p. 5-17) and “Description” (p. 5-52), the merits of

designing a load margin (factor) in the reverse and forward link budgets were discussed.

In both discussions, the result of increased interference on decreasing the sector coverage

was illustrated using a pole capacity diagram. This diagram (Figure 5-20, “Determining

Receiver Interference Margin” (p. 5-53)) shows that when CDMA loading in a sector

approaches its pole capacity, the coverage is at its minimum. At maximum capacity, or

100% loading, the noise rise is so high that the AT does not have enough power to achieve

the required signal level. As a result, system performance degrades severely. The

inclusion of a load margin (factor) in the link budgets provides an overlap to handle

allotted fluctuations in interference without degradation of service. Overload control

provides protection against performance degradation due to increased interference beyond

the range allotted in the link budget design.

Because the forward link uses time division multiplexing to transmit each user's data, and

always transmits at the maximum power level allowed by the sector, load control is

primarily concerned with the reverse link. Essential for reverse load control is the

maintenance of integrity of the DRC and ACK Channels, which are sub-channels of the

reverse link MAC Channel. If the base station cannot get reliable DRC feedback, the

scheduler cannot schedule any data packets to be sent on the forward link. Also important

is the base station's ability to receive reliable ACK feedback. Extra forward link capacity

could be wasted with needless retransmissions. Therefore, reverse link overload control is

vital in maximizing forward link throughput.

Reverse link loading constraints

The principal way of constraining reverse link loading to protect against overloading is to

reduce the data rate in which each AT in a sector is transmitting. 1xEV-DO standards

provide ways to accomplish this. These include the Reverse Activity Bit (RAB, discussed

“Introduction” (p. 7-74)) and rate limit messages. The rate limit messages are transmitted

from a sector in either a BroadcastReverseRateLimit message to all the ATs that include

the sector in its Active Set, or in a UnicastReverseRateLimit message that is directed to a

particular AT.

The UnicastReverseRateLimit message is transmitted to an individual active user at any

time to limit its transmit rate. This message may be useful when QoS is implemented such

that selective users can be targeted for rate limit control. However, sending one signaling

message to every user across the sector at the same time when an overload situation

occurs is not cost-effective. Amore efficient approach is to transmit the

BroadcastReverseRateLimit message.

Call Processing Power controlRev 0 Overload control

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-111

Page 520: 1xev-Do Rf Engineering

The BroadcastReverseRateLimit message is sent on the overhead channel in a periodic,

specified interval, and specifies the maximum transmit rate allowed by all ATs. This

message can be sent as frequently as every Control Channel Cycle, every 426.66ms, but

may be transmitted less frequently to preserve Control Channel capacity. Rate limit

messages are not fast enough to control the interference variations in the system where

users are allowed to double their rate every frame.

The RAB bit is transmitted every slot period, every 1.66ms, to provide a faster load

control mechanism than the BroadcastReverseRateLimit message. The AT monitors the

RAB bit transmitted from all the sectors in its Active Set, regardless of whether the slot

has any data. If any one of the forward links have set the RAB bit, the AT must decrease

its transmit rate by half if the AT passes its transition probability test. If all of the forward

links in the Active Set have not set the RAB bit, the AT can double the rate.

Overload detection

Overload detection is used to determine when and how the overload constraints described

in the previous section are used. The overload detection algorithm used considers two

input values:

• Walsh code-based CDMA loading

• RSSI (Received Signal Strength Indication) rise.

Walsh code-based CDMA loading uses system interference factors, such as number of

users, received Eb/�o, power settings of each user AT, and interference from other sectors

to compute loading. The computation does not consider out of system interference.

Therefore, the RSSI rise method is also used to compensate for interference factors

outside of CDMA loading computation. The RSSI is measured at the J4 antenna

connector, where RSSI rise is the rise of the total CDMA signal above the noise floor.

Under certain simplifying assumptions, RSSI Rise is related to sector CDMA loading

when the noise floor is accurately measured, and no out-of-system interference is

considered.

In general, high CDMA loading will cause high RSSI, but the reverse is not true because

the RSSI value has three components:

• �oise floor

• CDMA interference (corresponds to CDMA loading)

• Out of system interference.

Therefore, a high RSSI value can be caused by one or more of the above three

components. By using a combination of total Ec/Io loading and RSSI rise, CDMA loading

can be more accurately estimated. In addition, the value of RSSI rise defines the

cell/sector coverage. The cell coverage shrinks as RSSI rise increases.

Call Processing Power controlRev 0 Overload control

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-112 401-614-323Issue 16 October 2009

Page 521: 1xev-Do Rf Engineering

Overload control implementation

Reverse link overload control is implemented based on a short-term average for fast

control, and a long-term average for slow control. Slow control is also achieved, limiting

the maximum users allowed for a sector. The fast control periods are defined when the

RSSI rise is increased above pre-defined thresholds. The fast control is implemented by

using the RAB bit. When the RAB bit is set, all ATs will reduce the transmitting rate

according to certain pre-set probability until the AT reaches the minimum rate limit. When

the RAB bit is not set, the ATs are allowed to double the rate until it reaches the maximum

rate limit set by either the BroadcastReverseRateLimit or UnicastReverseRateLimit

messages. The probability of decreasing the transmit rate, determined by the appropriate

transition probability parameter described in “Controlling Interference in each Sector”

(p. 7-75), is larger than the probability of increasing the transmit rate. Thus, the loading

will decrease faster than increase with the changing of the RAB bit.

Call Processing Power controlRev 0 Overload control

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-113

Page 522: 1xev-Do Rf Engineering

Rev A power and overload control

Introduction

In Rev 0, reverse link power control (RPC) effectively controls the AT transmit power so

that the lowest signal power level sufficient to maintain a desired Packet Error Rate

(PER) is received from each user at the base station. Therefore, in a Rev 0 system, when

all ATs transmit at the lowest power required to provide discernible data at the base

station, the sector and cell capacity is maximized.

Power savings achieved by early termination

Rather than transmitting at the lowest power level sufficient to maintain a desired PER, in

Rev A the AT may transmit the first, or the first two or three sub-packets, at higher signal

power level (TxT2P) than required to encourage early termination. This is done to

provide faster low-latency flows. If early termination occurs, the effective data rate is

increased and, in most cases, early termination occurs after the first or second sub-packet

is transmitted, reducing the overall power required to transmit the packet. The result of

early termination on power savings is shown in Table 7-2, “Power savings achieved by

early termination” (p. 7-114). In this illustration the terminal target is set for a 1 percent

PER rate.

Table 7-2 Power savings achieved by early termination

4.8

9.6

19.2

28.8

38.4

57.6

76.8

115.2

153.6

230.4

307.2

460.7

Nominaldata rate

(kbps)

128

256

512

768

1024

1536

2048

3072

4096

6144

8192

12288

Packetsize

3

3

2

2

2

3

2

2

2

2

2

2

Terminationtarget 1st

sub-packettransmission

2ndsub-packet

transmission

3.25 3.25 3.25 0.75

6.50 6.50 6.50 3.75

13.00 13.00 7.00 7.00

14.75 14.75 8.75 8.75

16.25 16.25 10.00 10.00

14.00 14.00 14.00 11.50

19.25 19.25 13.00 13.00

19.25 19.25 14.25 14.25

20.50 20.50 15.50 15.50

21.77 21.77 17.02 17.02

23.27 23.27 18.52 18.52

26.27 26.27 21.27 21.27

LoLat Transmission Mode

T2P in dB T2P in dB

3rdsub-packet

transmission

4thsub-packet

transmission

0.75 0.75 0.75 0.75

3.75 3.75 3.75 3.75

7.00 7.00 7.00 7.00

8.75 8.75 8.75 8.75

10.00 10.00 10.00 10.00

11.50 11.50 11.50 11.50

13.00 13.00 13.00 13.00

14.25 14.25 14.25 14.25

15.50 15.50 15.50 15.50

17.02 17.02 17.02 17.02

18.52 18.52 18.52 18.52

21.27 21.27 21.27 21.27

HiCapTransmission Mode

1stsub-packet

transmission

2ndsub-packet

transmission

3rdsub-packet

transmission

4thsub-packet

transmission

Call Processing Power controlRev A power and overload control

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-114 401-614-323Issue 16 October 2009

Page 523: 1xev-Do Rf Engineering

Independent relationship between the Transition Point and Termination Target

Separate transmit T2P (TxT2P) profiles are indicated by the R�C per packet for the Low

Latency (LoLat) and high capacity (HiCap) transmission modes. For each flow, the R�C

also identifies a transition point and a termination target. The transition point indicates the

sub-frame in which the TxT2P level switches, and the termination target indicates the

number of sub-frames transmitted before early termination, assuming a given Packet

Error Rate (PER). Three examples are shown in Figure 7-32, “Independent relationship

between the Transition Point and Termination Target” (p. 7-116) to illustrate the

independent relationship between the transition point and termination target. In the first

(a) example, the transition point occurs prior to termination target. The transition point

and termination target may occur at the same time, as shown in the second example (b).

Example c shows that the transition point may designate an increase in the TxT2P power

rather than a decrease.

Call Processing Power controlRev A power and overload control

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-115

Page 524: 1xev-Do Rf Engineering

Figure 7-32 Independent relationship between the Transition Point andTermination Target

TxT2P

T2P TransitionPoint

Termination Target

Time

TxT2P

T2P Transition Pointand Termination Target

Time

TxT2P

T2P TransitionPoint

Termination Target

Time

(a)

(c)

(c)

Call Processing Power controlRev A power and overload control

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-116 401-614-323Issue 16 October 2009

Page 525: 1xev-Do Rf Engineering

Leaky bucket control mechanism

Introduction

The AT uses a leaky bucket control mechanism to regulate the power allocation for each

sub-packet flow. The power token bucket is used as a metaphor for a depository to store

the power resources that are allocated for an AT flow transmission. As described in

Chapter 3, the transmit power allocated to each flow is designated by a T2PInflow value

and its magnitude, which is negotiated by the AT and the R�C primarily in accordance

with the message QoS requirements. The magnitude is a function of the sector load and

the AT user QoS profile. The T2PInFlow value represents the long-term resource, based

on R�C assigned flow priority. The power allocation for each physical packet is

designated by TxT2P for the packet, and T2POutflow represents the actual T2P level

depleted (leaked) from the bucket to transmit the physical layer packet (see Figure 7-33,

“Leaky bucket control mechanism” (p. 7-117)).

Leaky bucket control mechanism diagram

Figure 7-33 Leaky bucket control mechanismT2PInflow

(new resourcebased on RNCassigned priorityto flow)

BucketLevel

(unusedaccumulated

resource)

Potential Output(maximum allowable

withdrawal)

T2POutFlowActual T2P withdrawalData

BucketLevelSat

(maximum allowedbucket size)

Call Processing Power controlLeaky bucket control mechanism

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-117

Page 526: 1xev-Do Rf Engineering

The leaky bucket control mechanism serves as a regulator to maintain a long term average

T2P resource usage, while allowing a degree of instantaneous deviation. This regulation is

required especially for bursty traffic such as VoIP traffic (which, when accounting for the

voice activity factor, may be considered bursty). An illustration of bursty traffic is shown

in Figure 7-34, “Supporting bursty traffic” (p. 7-118).

Supporting bursty traffic

For this illustration a constant T2PInflow value of 1 is deposited into the bucket for each

transmission cycle. The bursty nature of the traffic being supported in this illustration is

of a nature that the T2POutflow occurs every third transmit cycle. Because transmission

does not occur until the third transmission cycle, the BucketLevel climbs to 1 and then 2

in the first and second cycles. In the third transmit cycle, the burst is transmitted at a

T2POutFlow of 3, two from the bucket accumulation and one from the T2PInflow in the

third transmit cycle. After the burst is transmitted, the bucket is depleted and begins

accumulating a T2Pmagnitude on the next transmission cycle to restart the sequence.

Figure 7-34 Supporting bursty traffic

2

3

1

2

3

1

Time

2

3

1

Time

Time

T2P InFlow

T2P OutFlow

Bucket Level

Call Processing Power controlLeaky bucket control mechanism

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-118 401-614-323Issue 16 October 2009

Page 527: 1xev-Do Rf Engineering

T2POutflow feedback algorithm

An equilibrium must be maintained where the average T2PInFlow is equal to the average

T2POutflow. This equilibrium is known as conversion, where the T2PInFlow converges

to T2POutFlow. If the T2POutFlow is greater than the T2PInflow, the bucket resource

will be inadequate to support the flow commensurate with its QoS. If the T2PInFlow is

greater than the T2POutflow, the bucket resource will overflow, and performance is less

than optimal. To ensure equilibrium, T2POutflow is fed back to determine the T2PInflow

in the next update instance, which makes the T2PInflow automatically converge to

T2POutflow, provided that loading is steady. The T2POutflow feedback algorithm is as

follows:

Where:

T is a T2PFilterTC (time constant) (default = 96 slots)

∆ is a function of T2PInFlown-1, FRAB, and pilot strength

The ∆ identifies the T2PUp(.) and T2PDn(.) transition functions which are generated as

part of load control to prevent sector overloading.

Call Processing Power controlLeaky bucket control mechanism

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

7-119

Page 528: 1xev-Do Rf Engineering

RAB bit load control and RoT

Load control

As in Rev 0, Rev A relies on the generation of the Reverse Activity Bit (RAB) to control

reverse link loading. To provide quicker response to sector loading, unlike in Rev 0 where

the RAB bit transmitted by each sector once during every frame, in Rev A each sector

transmits the RAB bit once during every slot period. That represents a 16 to 1 time

difference going from once every 26.67 ms to once every 1.667 ms. A 1 RAB bit value

indicates sector loading trend and flow reduction is required. A 0 RAB bit indicates the

opposite and a flow increase is permitted.

Rise over Thermal (RoT)

The RAB bit is generated by each sector as a function of a target Rise over Thermal

(RoT) value.

RAB bit = 0, if RoT <= RoT_target (unloaded)

RAB bit = 1, if RoT > RoT_target (loaded)

The RoT is allocated in the link budget as the Receiver Interference Margin and is the

ratio of the total received power at a base station receiver to the receiver thermal noise

power. In the AT, all the RAB bits received from all the sectors in its active set are

logically ORed and are filtered through a short-term IIR filter having a 4-slot (default)

time constant (TC) and long-term IIR filter with a 384-slot (default) TC. The output of

each filter is sampled every 4-slot period (6.67 ms), producing a quick RAB (QRAB)

from the short-term filter, identifying short-term loading and a filtered RAB (FRAB) from

the long-term filter, identifying long-term loading.

The QRAB and FRAB values are used to produce delta (∆) T2PUp(.) and T2PDn(.)

transition functions that regulate the T2PInFlow. The QRAB value determines whether

the sector is loaded. When the QRAB is 1, the sector is determined busy, and the

T2PDn(.) transition function is used to slow down the T2PInFlow into the token bucket.

Conversely, when QRAB is 0, T2PUp(.) transition function is used to increase the

T2PInFlow into the token bucket.

Call Processing Power controlRAB bit load control and RoT

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

7-120 401-614-323Issue 16 October 2009

Page 529: 1xev-Do Rf Engineering

Glossary

...................................................................................................................................................................................................................................

A AAA (Authentication, Authorization and Accounting)

Authentication, Authorization and Accounting (AAA) is a way of checking user access to a

network. It is a very important function particularly when the service provider is not providing

access to the network. Authentication: verify the user identity, e.g., check user identification with

a password or other mechanism. Authorization: verify what the user is allowed to do, e.g., which

services he can access or which levels of quality of service he is allowed to use. Accounting: bill

for all the above according to different principles such as time, data volume, application used, etc.

AcAck (Access Acknowledge)

Access Terminal

See “AT” (p. GL-2)

ACK (ACKnowledge)

Amessage used to confirm the reception of another message.

ACKnowledge

See “ACK” (p. GL-1)

Advance Mobile Phone System

See “AMPS” (p. GL-1)

AF (Assured Forwarding)

ADiffServ traffic class that enables a DiffServ traffic conditioning block to support different

levels of forwarding assurances for IP traffic.

ALN (Alternative Location Notification)

AMPS (Advance Mobile Phone System)

A�orth American standard for mobile telephones.

AN directed IFHO

: For ATs that do not support OFS (i.e., MSM5500 chipset based ATs), IFHO is based on AT

measurements of pilot strengths of the current active set. See “MAIFHO” (p. GL-11) for more

information

ANID (Access Node ID)

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

GL-1

Page 530: 1xev-Do Rf Engineering

AP (Application Processor)

AnAP is a central processing unit (CPU) that provides generic computing facilities to host a wide

range of applications in an Alcatel-Lucent CDMAwireless network. The APs perform the

call-processing and underlying OA&M functions for theMicrocells andModular cells in an

Alcatel-Lucent CDMA network. Pairs of APs host the Radio Cluster Server (RCS) application for

Alcatel-Lucent CDMAMicrocells andModular cells. The APs provide an integrated

high-availability hardware and software platform that offers increased reliability, availability, and

maintainability for its subtending network elements.

Application Processor

See “AP” (p. GL-1)

ARQ (Automatic Repeat Request)

Communication technique in which the receiving device detects errors and requests

retransmissions.

AS (Active Set)

Assured Forwarding

See “AF” (p. GL-1)

AT (Access Terminal)

ATI (Access Terminal Identifier)

Authentication, Authorization and Accounting

See “AAA” (p. GL-1)

Automatic Repeat Request

See “ARQ” (p. GL-2)

...................................................................................................................................................................................................................................

B Base Transceiver Station

See “BTS” (p. GL-3)

BCMCS (BroadCast and MultiCast Service)

BE (Best Effort)

Packets are sent without adhering to any particular rules and the network will deliver as many of

these packets as possible and as soon as possible, subject to other resource policy constraints.

BER (Bit Error Rate)

The ratio of the number of errored bits divided by the number of transmitted bits.

Glossary

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

GL-2 401-614-323Issue 16 October 2009

Page 531: 1xev-Do Rf Engineering

Best Effort

See “BE” (p. GL-2)

Binary Phase Shift Keying

See “BPSK” (p. GL-3)

Bit Error Rate

See “BER” (p. GL-2)

BPSK (Binary Phase Shift Keying)

Two-condition phase shift keying in which the phase shift takes two different values differing by

180 degrees or ""pi"" radians.

BTS (Base Transceiver Station)

The name for the antenna and radio equipment necessary to provide wireless service in an area.

Also called a base station or cell site.

...................................................................................................................................................................................................................................

C Call/Session Control Function

See “CSCF” (p. GL-4)

CANID (Current ANID)

CBR (CDMA Baseband Radio)

Receives the digitally combined baseband forward signal from the CCU-20s and converts it to a

low-powered level, modulated RF signal.

CC (Control Channel)

CCU (CDMA Channel Unit)

CDMAChannel Unit. A generic term for a unit that holds channel elements in a CDMA system.

CDF (Cumulative Distribution Function)

CDM (CDMA Digital Module)

The functions of the CDMADigital Module (CDM) are as follows: communicate with the MSC

via T1 or E1 data links, convert the MSC formatted information on the downlink, and provide

other cell site control functions.

CDMA Baseband Radio

See “CBR” (p. GL-3)

CDMA Channel Unit

See “CCU” (p. GL-3)

Glossary

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

GL-3

Page 532: 1xev-Do Rf Engineering

CDMA Digital Module

See “CDM” (p. GL-3)

CDMA Modem Unit

See “CMU” (p. GL-4)

CE (Channel Element)

Channel Element. A CDMACE contains the circuitry necessary to perform forward and reverse

link CDMA spread spectrum processing to support one CDMA channel. It can be configured as an

overhead channel (pilot, sync, access or page) or a traffic (for example, voice) channel, or for test

purposes, as an OC�S channel. The pilot, sync, and access channels are all supported on a single

CE.

Central Processing Unit

See “CPU” (p. GL-4)

Challenge Handshake Authentication Protocol

See “CHAP” (p. GL-4)

Channel Elements

See “CE” (p. GL-4)

CHAP (Challenge Handshake Authentication Protocol)

This security protocol allows access between data communications systems prior to and during

data transmission. CHAP uses challenges to verify that a user has access to a system.

CIC (Customer Information Center)

Source for locating and obtaining delivery of Alcatel-Lucent Technologies customer information

products.

CMCS (Conversational Media Control Signaling)

CMU (CDMA Modem Unit)

The CMU contains the channel elements that provide the signal spreading and de-spreading. In

the transmit path, the CE spreads the signal and passes it on to the UCR.

Common Timing Unit

See “CTU” (p. GL-5)

CPU (Central Processing Unit)

The Central Processing Unit is the main processing unit in a system. In this context the main

centralized processing unit can be a single PC or a pool of PCs or a processor on a

multi-processor (embedded) system.

CRC (Cyclic Redundancy)

Method of checking transmission errors applied to a block of information. It involves a bit string

(computed from the data to transmit) associated with each transmitted block, and ensures the

check on reception.

Glossary

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

GL-4 401-614-323Issue 16 October 2009

Page 533: 1xev-Do Rf Engineering

CSCF (Call/Session Control Function)

The collection of 3 SIP proxies used for IMS call handling:- P-CSCF - I-CSCF - S-CSCF

CTU (Common Timing Unit)

The CTU is the reference frequency and CDMA time-based unit that receives the timing signal

from the GPS to maintain synchronization for the 9218 Macro with the other Base Stations in the

CDMA network.

Customer Information Center

See “CIC” (p. GL-4)

Cyclic Redundancy

See “CRC” (p. GL-4)

...................................................................................................................................................................................................................................

D DARQ (Delayed Acknowledge Request)

DDGF (Double Density Growth Frame)

DHCP (Dynamic Host Configuration Protocol)

The Dynamic Host Configuration Protocol (DHCP) is an Internet protocol for automating the

configuration of computers that use TCP/IP. DHCP can be used to automatically assign IP

addresses, to deliver TCP/IP stack configuration parameters such as the subnet mask and default

router, and to provide other configuration information such as the addresses for printer, time and

news servers.

DNS (Domain Name Server)

The Domain �ame System (D�S) is used in the Internet for translating names of network nodes

into addresses.

DO (Data Only)

Domain Name Server

See “D�S” (p. GL-5)

DOS (Data Over Signaling)

Double Density Growth Frame

See “DDGF” (p. GL-5)

DRC (Data Rate Control)

DS (Direct Spread)

Glossary

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

GL-5

Page 534: 1xev-Do Rf Engineering

DSC (Data Source Control)

DV (Data Voice)

Dynamic Host Configuration Protocol

See “DHCP” (p. GL-5)

...................................................................................................................................................................................................................................

E Eb (Error Bit)

EF (Expedited Forwarding)

ADiffServ traffic class that must be treated as the highest priority of all traffic by the DS traffic

conditioning block without preempting other traffic

Effective Radiated Power

See “ERP” (p. GL-6)

EMFPA (Enhanced Multi-Flow Packet Application)

ERP (Effective Radiated Power)

The actual power radiated by an antenna in the direction where it offers the highest gain, which

includes transmitter output power, transmission line loss and antenna gain.

EVC (Evolution Controller)

Expedited Forwarding

See “EF” (p. GL-6)

...................................................................................................................................................................................................................................

F FA (Foreign Agent)

A router on a mobile node's visited network which provides routing services to the mobile node

while registered. The foreign agent detunnels and delivers datagrams to the mobile node that were

tunneled by the mobile node's home agent.

FCS (Frame Check Sequence)

Extra characters added to a frame for error control purposes. Used in HDLC, Frame Relay, and

other data link layer protocols.

FDD (Frequency Division Duplex)

Separation of the radio paths (in UMTS) for uplink- (from the mobile to the Transceiver-station)

and downlink-direction (from the Transceiver-station to the mobile) by using two different

frequencies; the alternative is Time Division Duplex (TDD).

Glossary

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

GL-6 401-614-323Issue 16 October 2009

Page 535: 1xev-Do Rf Engineering

FEC (Forward Error Correction)

The Forward Error Correction is a technique by means of which redundancy is transmitted

together with transported data, using a pre-determined algorithm. The receiving device has the

capability of detecting and correcting multiple bit errors that could occur during transmission

thanks to the redundancy. The signal transmitted with FEC is more ""robust"" thus allowing

operators to build up longer distance connections without the deployment of many repeater

stations.

FER (Frame Error Rate)

The FER is defined as the number of frames with errors divided by the total number of frames

transmitted. This provides a way to measure the quality of voice calls.

File Transfer Protocol

See “FTP” (p. GL-7)

FM (Frequency Modulation)

Angle modulation in which the instantaneous frequency deviation varies in accordance with a

given function, generally linear, of the instantaneous value of the modulating signal.

FMS (Flexent Mobility Server)

Foreign Agent

See “FA” (p. GL-6)

Forward Error Correction

See “FEC” (p. GL-6)

FRAB (Frame RAB)

Frame Check Sequence

See “FCS” (p. GL-6)

Frame Error Rate

See “FER” (p. GL-7)

Frequency Division Duplex

See “FDD” (p. GL-6)

Frequency Modulation

See “FM” (p. GL-7)

FSC (Frame Sequence Check)

FTC (Forward Traffic Channel)

Glossary

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

GL-7

Page 536: 1xev-Do Rf Engineering

FTP (File Transfer Protocol)

File Transfer Protocol (FTP) is a very common method of moving files between two Internet sites.

FTP is a special way to log in to another Internet site for the purposes of retrieving and/or sending

files.

...................................................................................................................................................................................................................................

G GAUP (Generic Attribute Update Protocol)

GRE (Generic Routing Encapsulation)

...................................................................................................................................................................................................................................

H HA (Home Agent)

A router on a mobile node's home network which tunnels datagrams for delivery to the mobile

node when it is away from home, and maintains current location information for the mobile node.

HARQ (Hybrid-ARQ)

See ARQ

HDLC (High level Data Link Control)

An ISO standard bit-oriented data link control procedure under which all data transfers take place

in frames containing a control field, an information field and a frame check sequence for error

detection. CCITT later adopted HDLC for its link access protocols used in X.25 networks, the n?7

common channel signaling system and ISD� subscriber access.

HiCap (High Capacity)

High capacity (link, system, access,...) usually denotes the capability to deal with high bit rates. It

is a generic term used in many contexts

High Capacity

See “HiCap” (p. GL-8)

High level Data Link Control

See “HDLC” (p. GL-8)

HLR (Home Location Register)

It is the main database of permanent subscriber information for a mobile network. It contains

location, subscription, and authentication information.

Home Agent

See “HA” (p. GL-8)

Home Location Register

See “HLR” (p. GL-8)

Glossary

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

GL-8 401-614-323Issue 16 October 2009

Page 537: 1xev-Do Rf Engineering

Home Subscriber Server

See “HSS” (p. GL-9)

HSS (Home Subscriber Server)

The Home Subscriber Server describes the many database functions that are required in next

generation mobile and fixed-mobile converged networks. These functions will include the HLR

(Home Location Register), AUC (Authentication Center), IM-HSS (IPmultimedia Home

Subscriber Server), SLF (Subscription Locator Function), D�S (Domain �ame Servers) and

security and network access databases.

Hybrid-ARQ

See “HARQ” (p. GL-8)

...................................................................................................................................................................................................................................

I IFHO (Inter-Frequency HandOff)

IMS (IP Multimedia Sub-system)

IPMultimedia Subsystem (IMS) is a Voice/video over IP architecture based on Internet standards

protocols (RTP, SIP) and which introduces the notion of domain (“@myoperator”, much like

e-mail). Domains are to be managed by operators. IMS enables the interoperability between IMS

domains and with legacy telephony (through border nodes) while proprietary VoIP tendency was

to be designed for a single operator.

IMSI (International Mobile Serial Identifier)

A code which uniquely identifies a subscription and serves as a key to derive subscriber

information such as directory number(s) from the home location register.

IMT (International Mobile Telecommunication)

International Mobile Serial Identifier

See “IMSI” (p. GL-9)

International Telecommunication Union

See “ITU” (p. GL-10)

Internet Protocols

See “IP” (p. GL-9)

Internet Service Provider

See “ISP” (p. GL-10)

IOU (I/O Unit)

IP (Internet Protocols)

Internet Protocol (IP) specifies the format of packets (or datagrams) and the addressing scheme

Glossary

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

GL-9

Page 538: 1xev-Do Rf Engineering

for sending information over the Internet or some other network. Most networks combine IP with

a higher level protocol Transmission Control Protocol (TCP). TCP/IP establishes a virtual

connection between a destination and a source. On its own, IP allows information to be addressed

and dropped into the system, but there is no direct link between the sender and the recipient.

IP Multimedia Sub-system

See “IMS” (p. GL-9)

IP Security

See “IPSec” (p. GL-10)

IPSec (IP Security)

A IETF network layer security standard used to encrypt and authenticate Internet Protocol packet

data.

ISP (Internet Service Provider)

An Internet Service Provider (ISP) is a company or organization that provides Internet access to

the public or to other organizations, usually for a fee. Most offer a full set of Internet services

(access to e-mail, newsgroups, File Transfer Protocol (FTP), and Telnet, at a minimum) for either

an hourly rate or for a flat fee for a fixed number of hours of access.

ITU (International Telecommunication Union)

The International Telecommunications Union (ITU) is a group of representatives from 161

countries headquartered in Geneva, Switzerland. The ITU publishes recommendations that

influence telecom engineers, designers, manufacturers, and service providers around the world.

...................................................................................................................................................................................................................................

L LAN (Local Area Network)

ALocal Area �etwork (LA�) is a group of computers and associated devices that share a

common communications line and typically share the resources of a single processor or server

within a small geographic area (for example, within an office building or a group of buildings).

Usually, the server has applications and data storage that are shared in common by multiple

computer users.

LCP (Link Control Protocol)

Protocol that establishes, configures, and tests data-link connections for use by PPP.

Link Control Protocol

See “LCP” (p. GL-10)

LMT (Local Maintenance Terminal)

Local Area Network

See “LA�” (p. GL-10)

LoLat (Low Latency)

Glossary

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

GL-10 401-614-323Issue 16 October 2009

Page 539: 1xev-Do Rf Engineering

LSB (Least Significant Bits)

...................................................................................................................................................................................................................................

M MAC (Medium Access Control)

Protocol used to share a physical connection between multiple users, so that each can access part

of the bandwidth of the physical pipe. As an example, Carrier Sense Multiple Access with

Collision Detection (CSMA/CD) is the classical way to share the bandwidth of an Ethernet bus

between several stations.

MAIFHO (Mobile Assisted IFHO)

For ATs that can perform Off Frequency Searching (OFS) while in the connected state (i.e.,

MSM6500 chipset based ATs), IFHO is based on AT measurements of the pilot strength on the

target carrier. See “A� directed IFHO” (p. GL-1) for more information

MAP (Mobile Application Part)

A part of CCITT signaling system �o 7 which ensures the internetworking signaling between

mobile-service switching centers and location registers and equipment identity registers.

Maximum Transmission Unit

See “MTU” (p. GL-12)

MC (Multi-Carrier)

Radio transmission mode which (contrary to ""classic"" radio transmission which uses only one

HF carrier per link) uses up to several hundred separate carriers for the transmission between one

sender and one receiver, e.g. in OFDM (Orthogonal Frequency Division Multiplexing).

MCR (Multi-Carrier Radio)

The MCR is the Base Station multi-carrier transceiver. It is a 15 MHz bandwidth radio. The radio

is capable of processing up to 11 contiguous 1.25 MHz CDMA carriers. Two versions of the MCR

support the Cellular and PCS band classes. The Cellular MCR transmits and receives up to 8

contiguous carriers spread over no more than 15 MHz total bandwidth anywhere in the Cellular

band. The PCS MCR transmits and receives up to 11 contiguous carriers spread over no more

than 15 MHz total bandwidth anywhere in a block in the PCS band. The MCR supports internally

all functionality's supported by the TDU/ETDU used in the 9218 Macro and 9216 Compact cells.

On the forward link, the MCR function is to combine the digital I and Q signals from the CMU to

RF in the transmit path and from RF to digital in the receive path.

Media Gateway

See “MGW” (p. GL-12)

Media Gateway Control Function

See “MGCF” (p. GL-12)

Medium Access Control

See “MAC” (p. GL-11)

MFFU (Modular Filter and Fusing Unit)

Glossary

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

GL-11

Page 540: 1xev-Do Rf Engineering

MFPA (Multi-flow Packet Application)

MGCF (Media Gateway Control Function)

A function within a network that supports the call control function for distributed switching

systems.

MGW (Media Gateway)

A gateway that supports both bearer traffic and signaling traffic.

MIP (Maintenance Interface Panel)

MO (Mobile Originated)

Qualifies a call or short message originated from the mobile station.

Mobile Application Part

See “MAP” (p. GL-11)

Mobile Assisted IFHO

See “MAIFHO” (p. GL-11)

Mobile Originated

See “MO” (p. GL-12)

Mobile Terminated

See “MT” (p. GL-12)

MSB (Most Significant Bits)

MT (Mobile Terminated)

Qualifies a call or short message sent by the network to the mobile station (by opposition to a call

or short message sent by the mobile station to the network).

MTMR (Maximum Throughput With Min Rate Control)

MTU (Maximum Transmission Unit)

Maximum packet size, in bytes, that a particular interface can handle.

Multi-Carrier

See “MC” (p. GL-11)

Multi-Carrier Radio

See “MCR” (p. GL-11)

MUP (Multi-Users Packet)

Glossary

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

GL-12 401-614-323Issue 16 October 2009

Page 541: 1xev-Do Rf Engineering

...................................................................................................................................................................................................................................

N NACK (Negative ACKnowledgement)

See �AK

NAK (Negative ACKnowledgement)

A packet sent from a receiver to a sender, informing the sender that the data is missing or corrupt.

When a device receives a packet, it sends back a packet to the sending device. If all the data

arrived without corruption, the packet is an acknowledgment (ACK). If some of the data is

missing or corrupt, a �AK results requesting that the sender retransmits the data.

Negative ACKnowledgement

See “�AK” (p. GL-13)

Network Timing Protocol

See “�TP” (p. GL-13)

NID (Network ID)

NTP (Network Timing Protocol)

Internet protocol used to synchronize time between network equipment.

NTT (Nippon Telephone and Telegraph)

...................................................................................................................................................................................................................................

O Off Frequency Search (OFS)

OFS (Off Frequency Search)

OLCS (Online Customer Support)

OM (Oscillator Module)

Open System Interconnection

See “OSI” (p. GL-14)

Operating System

See “OS” (p. GL-13)

OS (Operating System)

The operating system provides services to handle certain operations in a uniform way independent

Glossary

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

GL-13

Page 542: 1xev-Do Rf Engineering

of the underlying hardware architecture. The services that are generally supported are:

multi-tasking, interrupt handling, memory handling, database handling and software debug

features.

Oscillator Module

See “OM” (p. GL-13)

OSI (Open System Interconnection)

Pertaining to the logical structure for communications networks standardized by the International

Standards Organization (ISO). Adherence to the standard enables any OSI-compliant system to

communicate with any other OSI-compliant system for a meaningful exchange of information.

...................................................................................................................................................................................................................................

P Packet Control Function

See “PCF” (p. GL-14)

Packet Data Serving Node

See “PDS�” (p. GL-14)

Packet Error Rate

See “PER” (p. GL-14)

PANID (Previous ANID)

PC (Personal Computer)

A Personal Computer (PC) is a low-cost, standalone data processing installation designed for a

single user.

PCF (Packet Control Function)

Packet Control Function

PCS (Personal Communications Services)

Services for digital Radio Frequency (RF) equipment conveying both voice and data over wireless

networks.

PCT (Power Control Threshold)

PCU (Power Converter Unit)

The Power Converter Unit (PCU) converts supplied +24 VDC to DC at several voltage levels for

the CDMAmodular cell.

PDSN (Packet Data Serving Node)

A Packet Data Serving �ode (PDS�) is responsible for the establishment, maintenance and

termination of a Point to Point Protocol (PPP) session towards the mobile station. It may also

assign dynamic IP addresses in addition to supporting mobile IP functionality.

Glossary

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

GL-14 401-614-323Issue 16 October 2009

Page 543: 1xev-Do Rf Engineering

PER (Packet Error Rate)

The number of erroneous packets divided by the total number of packets transmitted, received or

processed over some stipulated period.

Personal Communications Services

See “PCS” (p. GL-14)

Personal Computer

See “PC” (p. GL-14)

PET (Paging Escalation Timer)

PF (Proportional Fair)

PFMR (Proportional Fair With Minimum Rate Control)

Phost (Power from its host or serving sector)

PHY (Physical Layer)

PIC (Pilot Interference Cancellation)

PN (Pseudo Noise)

A noise-like code used in the encryption and decryption of CDMA signals.

Point-to-Point Protocol

See “PPP” (p. GL-15)

Power Converter Unit

See “PCU” (p. GL-14)

PPP (Point-to-Point Protocol)

Point-to-Point Protocol (PPP) is a protocol for communication between two computers using a

serial interface, typically a personal computer connected by phone line to a server. PPP uses the

Internet Protocol (IP). It is considered as a member of the TCP/IP suite of protocols. The

underlying session establishment protocol has now been adopted in broadband variants such as

PPP over Ethernet.

PRC (Power Control)

PRL (Preferred Roaming List)

Glossary

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

GL-15

Page 544: 1xev-Do Rf Engineering

Pseudo Noise

See “P�” (p. GL-15)

PTT (Push-to-Talk)

Push-To-Talk is a Walkie-Talkie like service that provides voice messaging to a closed user group

at the touch of a button. PTT uses voice-over-packet techniques to minimize spectrum usage. PTT

is part of the ""IP Multimedia Subsystem (IMS) services"".

Push-to-Talk

See “PTT” (p. GL-16)

PZID (Packet Zone ID)

...................................................................................................................................................................................................................................

Q QoS (Quality of Service)

The Quality of Service (QoS) is a measure of how good the data is delivered to the end user (how

much packet loss, jitter, delay, etc.). It is used to differentiate telecommunication services based

on measurable parameters evaluated or controlled via network monitoring. QoS expresses and

verifies the capability of a network to fulfill a Service Level Agreement or to grant that some

specific parameters (technology-dependent) do not exceed pre-defined limits.

QPSK (Quadrature Phase Shift Key)

Four-condition phase shift key in which the phase shift takes values that are multiples of 90

degrees or ""pi""/2 radians.

QRAB (Quick RAB)

Quadrature Phase Shift Key

See “QPSK” (p. GL-16)

Quality of Service

See “QoS” (p. GL-16)

...................................................................................................................................................................................................................................

R RA (Reverse Activity)

RAB (Reverse Activity Bit)

RAC (Reverse Activity Channel)

Radio Access Network

See “RA�” (p. GL-17)

Glossary

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

GL-16 401-614-323Issue 16 October 2009

Page 545: 1xev-Do Rf Engineering

Radio Link Protocol

See “RLP” (p. GL-17)

Radio Network Controller

See “R�C” (p. GL-17)

RAN (Radio Access Network)

The access part of a mobile network, including the radio base stations, the radio base station

controllers and their management center.

RAS (Radio Access System)

RATI (Random Access Terminal Identifier)

RCC (Reliable Cluster Computing)

A set of control equipment located in shelf 0 of the primary Radio Channel Frame in an

AUTOPLEX Series II. The RCC houses a duplexed CSC.

Real-time Transport Protocol

See “RTP” (p. GL-18)

Received Signal Strength Indication

See “RSSI” (p. GL-18)

Reliable Cluster Computing

See “RCC” (p. GL-17)

RLP (Radio Link Protocol)

An automatic repeat request protocol used to reliably transfer user data between a mobile station

and the interworking function. RLP covers the Layer 2 functionality of the ISO OSI Reference

Model (IS 7498).

RNC (Radio Network Controller)

UMTS Terrestrial Radio Access �etwork (UTRA�) network element providing access and

mobility services to radio network subscribers. The Radio �etwork Controller (R�C) is the

interface between the �odes B and the Core �etwork (C�) (for circuit and packet) to manage

voice and data communications.

RObust Header Compression

See “ROHC” (p. GL-17)

ROHC (RObust Header Compression)

Compresses protocol headers to save resources on the radio interface.

RoT (Rise Over Thermal)

Glossary

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

GL-17

Page 546: 1xev-Do Rf Engineering

RPC (Reverse Power Control Channel)

RRI (Reverse Rate Indicator)

RSM (RLP and Signaling Manager)

RSSI (Received Signal Strength Indication)

A quantitative measure of the RF signal strength of one RF channel.

RTC (Reverse Traffic Channel)

RTP (Real-time Transport Protocol)

The RTP (Real-time Transport Protocol) is designed to provide end-to-end network transport

functionality for applications transmitting real-time data, such as audio, video or simulation data,

over a packet-based network. RTP provides functionality such as payload type identification,

sequence numbering, time stamping to these applications. With the associated RTCP (Real-time

Transport Control Protocol) the quality of the packet delivery can be monitored.

...................................................................................................................................................................................................................................

S SC (Single Carrier)

SCME (System Capacity, Monitoring, and Engineering)

Secure SHell

See “SSH” (p. GL-19)

Session Initiation Protocol

See “SIP” (p. GL-18)

Short Message Service

See “SMS” (p. GL-19)

SID (System ID)

Signal-to-Noise Ratio

See “S�R” (p. GL-19)

SIP (Session Initiation Protocol)

Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol suite for

creating, modifying, and terminating sessions with one or more participants. These sessions

include Internet telephone calls, multimedia distribution and multimedia conferences.

Glossary

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

GL-18 401-614-323Issue 16 October 2009

Page 547: 1xev-Do Rf Engineering

SLP (Signaling Link Protocol)

SMS (Short Message Service)

A service for sending text messages of up to 160 characters to mobile phones that use Global

System for Mobile (GSM) communication.

SNP (Signaling Network Protocol)

SNR (Signal-to-Noise Ratio)

In analog and digital communications, signal-to-noise ratio (S/� or S�R) is a measure of signal

strength relative to background noise. The ratio is measured in dB.

SSH (Secure SHell)

Developed by SSH Communications Security Ltd., Secure Shell is a program to log into another

computer over a network, to execute commands in a remote machine, and to move files from one

machine to another. It provides strong authentication and secure communications over insecure

channels. It is a replacement for rlogin, rsh, rcp, and rdist.

...................................................................................................................................................................................................................................

T TC (Time Code)

TCP (Transmission Control Protocol)

Transmission Control Protocol (TCP) is a set of rules (protocol) used along with the Internet

Protocol (IP) to send data in the form of message units between computers over the Internet.

While IP takes care of handling the actual delivery of the data, TCP takes care of keeping track of

the individual units of data (called packets) that a message is divided into for efficient routing

through the Internet.

TDD (Time Division Duplex)

Access method in which the same carrier is used for downlink and uplink transmissions.

TDM (Time Division-multiplexed)

Multiplexing in which a separate periodic time interval is allocated to each tributary channel in a

common aggregated channel.

TFU (Time Frequency Unit)

The TFU is the frequency reference and CDMA time-base unit that synchronizes the base station

with the other Base Stations in the CDMA network.

Time Division Duplex

See “TDD” (p. GL-19)

Time Division-multiplexed

See “TDM” (p. GL-19)

Glossary

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

GL-19

Page 548: 1xev-Do Rf Engineering

Time Frequency Unit

See “TFU” (p. GL-19)

TP (Traffic Processor)

Transmission Control Protocol

See “TCP” (p. GL-19)

...................................................................................................................................................................................................................................

U UATI (Unicast Access Terminal Identifier)

UCR (Universal CDMA Radio)

In the transmit path, the UCR receives the digitally combined baseband forward signal from the

CMU and converts it to a low-powered level modulated RF signal. The receive path is the

opposite. The UCR receives an RF signal and converts it to digital signals suitable for the channel

elements.

UDP (User Datagram Protocol)

The User Datagram Protocol (UDP) is a minimal, datagram-oriented, transport network protocol

above the IP network layer that does not guarantee data ordering or delivery. Because it is

datagram-oriented, each send operation by the application results in the transmission of a single

IP datagram. This contrasts with the Transmission Control Protocol (TCP) which is byte stream

oriented and guarantees the delivery and ordering of the bytes sent. Because it is a byte stream

oriented, a single send operation may result in a no IP datagrams (buffering), a single IP datagram,

or multiple IP datagrams.

ULNM (Unsolicited Location Notification Message)

Universal CDMA Radio

See “UCR” (p. GL-20)

Universal Radio Controller

See “URC” (p. GL-20)

URC (Universal Radio Controller)

The URC controls the 9218 Macro and interfaces the T1 or E1 facilities to the 9218 Macro.

URCm (Universal Radio Controller-M)

User Datagram Protocol

See “UDP” (p. GL-20)

UTP (Universal Traffic Processor)

Glossary

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

GL-20 401-614-323Issue 16 October 2009

Page 549: 1xev-Do Rf Engineering

...................................................................................................................................................................................................................................

V Virtual Private Network

See “VP�” (p. GL-21)

Visitor Location Register

See “VLR” (p. GL-21)

VLR (Visitor Location Register)

Database where mobile subscriber data are registered according to their actual localization.

Generally a VLR is associated with one MSC, and contains all subscriber that are located in the

geographical area controlled by the MSC.

Voice Over IP

See “VoIP” (p. GL-21)

VoIP (Voice Over IP)

VoIP is a set of facilities for managing the delivery of voice information using the Internet

Protocol (IP). It means sending voice information in a packet mode rather than in a circuit mode

used by the Public Switched Telephone �etwork (PST�).

VPN (Virtual Private Network)

A network exhibiting at least some of the characteristics of a private network, even though it uses

the resources of a public switched network.

VSHO (Virtual Soft HandOff)

VT (Video Telephony)

Glossary

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

GL-21

Page 550: 1xev-Do Rf Engineering
Page 551: 1xev-Do Rf Engineering

Index

Numerics

10logRb, 5-19

16 watts/carrier, 4-25

16QAM, 3-21

1xEV-DO

3G-1X overlay solution, 1-24

air interface, 3-5

Basic PTT, 7-58

channel structure, 3-6

characteristics, 1-24

collocation with Series II, 4-30

controller, 4-34

deployment, 4-38, 6-2

introduction, 1-20

multiple carriers, 4-24

paging, 7-60

power sharing with 3G-1X, 3-9

single EVM, 4-24

slot structure, 3-10

1xEV-DO Basic PTT, 7-58

20 watts/carrier, 4-25

3G-1X

comparison, 1xEV-DO, 1-12

overlay solution, 1-24

power sharing with 1xEV-DO,

3-9

850MHz, band class 0, 6-3

8PSK, 3-21

9218 Macro

cabinet, 4-10

card location, 4-27

.............................................................

A AAA, 4-37

authentication, 2-8

AAA server, 7-18

access channel generation, 3-100

access mode, 7-7

access probe

figure, 7-10

sequence, 7-10

structure, 7-10

translation parameters, 7-8

access terminal

See: AT

ACK

channel, 3-76

channel gain, 7-72

active data sessions, 5-69

active set, 7-81

active set pilot P� offsets, 7-81

active set, pilot P� offsets, 7-82

active users, total, 5-76

activity factor, random, 3-63

address assignment, IP, 2-7

air interface, 3-1

1xEV-DO, 1-12

introduction, 3-5

air link

AT, 7-7

management, 7-7

algorithm

for rate control scheduling,

3-58

neighbor list selection, 7-86

proportional fair scheduling,

3-57

Rev 0 scheduling, 1-28, 3-57

Rev A scheduling, 1-29, 3-65

scheduling, 1-28

Alternative Location �otification,

2-77

A� directed

sector-carrier views, 7-100

A�ID, 2-77

antenna

gain, 5-14

isotropic, max path loss, 5-27

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

IN-1

Page 552: 1xev-Do Rf Engineering

AP, 4-32

server, 4-34

application layer, 2-20

Rev A, 2-30

Application Processor

See: AP

architecture

IA-856A, 2-23, 2-29

layer, 2-23

protocol, 7-5

radio access network, 2-1

Rev 0, 2-23

Rev 0 layers, 2-26

Rev A, 2-29

TIA-856A, 7-5

area covered, data rate, 5-29

AT

access mode, 7-7

class, 7-91

dual band, 6-15

eHRPD, 2-45

hybrid, 2-68

hybrid AT, 2-67

idle state, 7-15

initialization, 7-13

maximum transmit power, 5-7

monitor sub-state, 7-22

non-IFHO handoff, 7-94

normal setup, 7-34

path loss, 5-6

performance, 5-31

persistent test, 7-9

PPP connection, 2-35

protocol stack, 2-18

receiver power, 5-42

RF conditions, 5-31

terminal, 2-67

AT directed handoff

See: MAIFHO

authentication, 7-18

AAA, 2-8

Authentication, Authorization, and

Accounting

See: AAA

.............................................................

B backoff

inter-probe, 7-11

inter-sequence, 7-12

band

cellular, 6-5

channel allocation, 6-11

channel numbers, 6-7

channels preferred, 6-13

distribution, cellular, 6-5

frequency, 6-3

guard, 6-11

PCS, 6-10

band class

single EVM support, 4-24

band class 0, 6-15

cellular, 6-3

channel allocation, 6-7

recommended A-band

frequency assignments, 6-8

recommended B-band

frequency assignments, 6-9

single EVM support, 4-24

band class 1, 6-15

channel allocation, 6-11

PCS, 6-10

band class 6

single EVM support, 4-24

base station

noise, 5-55

power sharing 3G-1X and

1xEV-DO, 3-9

Base Station Cabinet, 4-4

OneBTS, 4-10

structure, 4-5

base transceiver station

See: BTS

bc0

See: band class 0

bc1

See: band class 1

BCMCS

channel interlace, 7-104

distribution, 7-102

dynamic registration, 7-104

introduction, 7-102

Best Effort, 7-59

border

handoff, 2-80

PCF, 2-80

PPP reconfiguration trigger,

2-74

PSD�, 2-80

system, 2-80

boundaries

service node, 7-53

BPSK, 3-21

BroadCast andMultiCast Service

See: BCMCS

BTS, 2-5

support for single EVM, 4-24

Index

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

IN-2 401-614-323Issue 16 October 2009

Page 553: 1xev-Do Rf Engineering

budget

forward link, 5-29

forward link, budget, 5-39

forward link, Rev A,

1536-3072kbps, 5-40

link, 5-34

reverse link, 5-4

bursty traffic, 7-118

.............................................................

C calculate

link budget, 5-34

transmit power, 5-42

calculation pole capacity, 5-57

call processing, 7-1

overview 1xEV-DO, 7-5

TIA-856A, 7-5

call-blocking, 5-71

candidate set management, 7-85

CA�ID, 2-77

capacity

calculation, pole, 5-57

calculation, pole point, 5-69

coverage trade-off, 5-50

erlang, 5-75

flow fairness, 3-67

forward link, 5-79

overview, 5-49

pole, 5-52

quality, coverage trade-off,

1-22

reverse link, 5-55, 5-64

RF, 5-1

target, determining, 5-71

card location 9218 Macro, 4-27

carrier

spacing, 6-13

waveform, 6-3, 6-3

carriers

6, 4-18

dual band, 6-15

five, 4-16

single EVM support for

multiple, 4-24

CDM module, 4-6, 4-8, 4-9

CDMA2000, 1-15

multi-carrier, 1-11

cell

adding 1xEV-DO, 4-29

Base Station Cabinet, 4-4

card location, 4-27

collocation 1xEV-DO and

PCS, 4-29

collocation 1xEV-DO and

Series II, 4-30

multi-mode, 4-3

cell/sector interference, 5-44

cellular

band, 6-5

band distribution, 6-5

class 0, 6-3

waveform, 6-3

channel

access, 3-100

ACK, 3-76

activity factor, 5-62

allocation, band, 6-11

auxiliary pilot, 3-98

average number reverse links,

5-75

band, 6-7

bit, 3-99

bit size vs slot duration, 3-28

control, 3-37

control channel structure, 3-37

data, 3-77, 3-100

data rate, 3-27

DRC, 3-77, 7-72

enhanced access, 3-101

forward link, 3-8, 5-31, 5-32,

7-22

forward link data, 1-26

forward traffic, 3-12

gain, 5-59

gain DRC, 5-60

gain, ACK, 7-72

gain, traffic, 5-59

idle state pilot, 7-30

interference total, 5-46

interlace BCMCS, 7-104

MAC, 3-40, 3-41, 3-104

multiplexing MAC, 3-43

physical layer, 3-24

pilot, 3-39, 3-76, 3-104

pilot Ec/�t, 5-55, 5-59

pilot uplink, 1-16

preferred for band class 1, 6-13

rate, 3-72

resource allocation, 7-71

Rev 0 access, 3-99

Rev 0 reverse link, 3-72

reverse access, 3-102

reverse link, 3-86

reverse link data, 1-30

Index

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

IN-3

Page 554: 1xev-Do Rf Engineering

reverse link traffic, 3-71

reverse traffic, 3-74, 3-75

reverse traffic packet bit size,

3-79

RPC, 7-110

RRI, 3-91

structure, 3-72

structure for 1xEV-DO, 3-6

supplemental, 1-19

traffic, 7-35

usage, data channel, 3-8

waveform, 6-3

channel activity factor, 5-62

channel numbers, 6-7

CHAP, 7-18

circuit pack location, 4-27

CLI, command syntax, 3-107

closed loop power control, 7-108

co-channel

interference, 5-56

command

syntax for CLI, 3-107

TAA, 3-110

communication

PCS distribution, 6-10

peer-to-peer, 2-34

component

AT, 5-6

hardware, 4-1

maximum path loss, 5-6

compression

header, 2-56, 2-57

transmission, 2-56

VoIP, 2-56

computing

DRC offset, 3-50

interference total, 5-44

path loss delta, 5-43

configuration

double duplex, 4-30

duplex, 4-29

negotiation procedure, 7-41

open a session, 7-39

connection

architecture, 7-5

establishing PPP, 7-43

IP, 2-37, 2-38, 2-41

layer, 2-27, 7-5

layer, Rev A, 2-30

mobile, 2-41

network, 2-38, 2-40

PPP, 7-43

PPP between AT and PDS�,

2-35

private, 2-38, 2-40

protocol, 2-40, 7-5

setup sub-state, 7-34

simple IP, 2-40

stack, 2-40

contextual paging, 7-63

control channel, 3-37

controller, 4-34

radio, URC-II, 4-12

coverage

capacity trade-off, 5-50

capacity, quality trade-off, 1-22

computing path loss delta, 5-43

data rate, 1-6, 5-29

deployment, 4-38

design, 4-38

fade, 5-26

interference, limited case, 5-45

probability, 5-26

Rev A, 1-35

RF, 5-1

standalone, 4-38

.............................................................

D data channel, 3-8, 3-77, 3-100

data flow, network

network, 2-4

data rate, 5-29

bit size vs slot duration, 3-28

channel, 3-27

code symbol bit size, 3-77

coverage, 1-6

dynamic control, 1-26

Eb/�t, 5-23

IMT-2000, 1-6

increase, 1-22

new for Rev A, 1-13, 3-103

physical layer, 3-77

preamble bit insertion, 3-35

Rev A, 1-13

Rev A, low, 5-51

reverse link, 3-92, 3-95

reverse link budget, 5-11

reverse link traffic, 3-72

RF environment, 3-49

Data Rate Control

See: DRC

Data Source Control

See: DSC

Index

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

IN-4 401-614-323Issue 16 October 2009

Page 555: 1xev-Do Rf Engineering

data, command syntax, 3-34

DCRATE values, 3-108

definition

paging, 7-51

delay

budget, 2-62

budget for mobile to wireline,

2-63

budget landline to mobile, 2-64

budget mobile to mobile, 2-64

end-to-end, 2-63

end-to-end guideline, 2-60

end-to-end landline to mobile,

2-64

end-to-end mobile to mobile,

2-64

end-to-end VoIP diagram, 2-61

erlang capacity, 5-75

guideline, 2-60

guideline diagram, 2-61

mobile, 2-63, 2-64

queue, 5-71

speech frame estimates, 2-61

to mobile, 2-64

VoIP, 2-60

VoIP diagram, 2-61

delta

path loss value, 5-42

path loss, computing, 5-43

density

spectral noise, 5-55

total effective noise, 5-15

deployment, 6-2

coverage design, 4-38

overlay, 4-38

detection, overload, 7-112

Direct DOS

DOS method type, 7-51

distance based handoff, 7-99

distance based paging

operation, 7-65

dormant/active, 7-47

DOS

definition, 7-51

divisions, 7-68

message delivery, 7-69

methods, 7-51

QoS, 7-68

QoS paging attempt logic, 7-69

restrictions, 7-68

DRC

channel, 3-77

channel gain, 5-60, 7-72

computing offset, 3-50

gain, 5-60

length, 7-72

offset lookup table, 3-49

Rev A, 3-49

Rev A transmission format,

3-15

DRC cover, 7-73

DRCLock, channel, 7-110

DSC

forward link handoff, 3-51

Rev A, 3-51

selection, 3-52

timing, 3-51

dual band

ATs, 6-15

band class 0, 4-25, 6-15

band class 1, 6-15

band class 6, 4-25

BTS's, 6-15

carriers, 6-15

features, 6-15

setup, 6-15

duplex

configuration, 4-29

configuration, double, 4-30

duration, sub-frame, 3-89

dynamic rate control, 3-49

dynamic registration, BCMCS,

7-104

.............................................................

E Eb/�t

data rate, 5-23

required, 5-21

required values, 5-21

reverse link, 5-21

vehicle speed, 5-21

Ec/�t

pilot channel, 5-55, 5-59

Effective Isotropic Radiated Power

See: EIRP

eHRPD

support, 2-45

EIRP, 5-14

EMFPA, 2-45

encapsulation, routing

routing, 2-36

encoder, turbo, 3-79

end-to-end

budget, 2-63, 2-64

Index

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

IN-5

Page 556: 1xev-Do Rf Engineering

delay, 2-60, 2-63, 2-64, 2-64

guideline, 2-60

guideline diagram, 2-61

landline to mobile budget, 2-64

mobile, 2-64

mobile to wireline delay

budget, 2-63

protocol, 2-59

protocol diagram, 2-59

stack, 2-59

stack diagram, 2-59

VoIP, 2-59, 2-60

VoIP diagram, 2-59, 2-61

enhancement

Rev A, 1-45

upper layer, 1-47

enhancements

paging, 7-60

environment

data rate, 3-49

radio, 1-6

erlang

B and C models, 5-73

capacity, 5-75

data traffic load, 5-72

general model, 5-72

model, 5-72

escalation

paging, 7-58

paging de-escalation, 7-63

Ethernet

additional ports, 2-12

ethernet

router, 4-36

EVDO paging

See: paging

EVM

single sector configuration,

4-24

evolution from IS-95 to 3G-1X,

1-16

.............................................................

F factor

channel activity, 5-62

repetition, 5-32

fade

coverage, 5-26

log-normal, 5-25

probability, 5-26

shadow, 5-7

fair, PF algorithm, 3-57

fairness, flow capacity, 3-67

fast connect, 7-37

feature

enhanced, Rev A, 1-39

multi-carrier, 4-14

RA�, 1-41

Rev A release schedule, 1-35

Rev A, basic, 1-37

test application, 3-106

voice over IP, 1-42

filter, MFFU, 4-36

flow, 3-66

flow queue, 3-66

FMS

cabinet, 4-32

frame, 2-5

mobility server, 2-5, 4-32

FMS frames

R�C, 2-6

format

code rate and transmission

type, 3-19

DRC and Rev A transmission,

3-15

Rev 0 transmission, 3-13

Rev Amultiple transmission,

3-15

forward channel

bit size vs slot duration, 3-28

data rate, 3-27

forward link

budget, 5-29

budget spreadsheet, 5-36

budget, Rev A, 5-38, 5-39

budget, Rev A,

1536-3072kbps, 5-40

capacity, 5-79

channel, 3-8

control channel, 7-22

data rate, 1-13

data traffic, 1-26

Eb/�o value, 5-31

frame/slot, 3-6

handoff, 7-76

handoff with DSC, 3-51

limitation, 5-4

receiver sensitivity, 5-47

reverse link compared, 5-53

signaling channel, 5-32

slot structure, 3-10

spreadsheet, 5-36

test application, 3-107

Index

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

IN-6 401-614-323Issue 16 October 2009

Page 557: 1xev-Do Rf Engineering

traffic channel, 3-12

frame configurations

three carriers, 4-23

frame offset, 7-72

frequency bands, 6-3

.............................................................

G g-fair scheduling, 3-63

gain

ACK channel, 7-72

antenna, 5-14

channel, 5-59

DRC, 5-60

DRC channel, 5-60, 7-72

handoff, 5-24

traffic channel, 5-59

generating a MAC channel

MAC channel, 3-41

generic routing encapsulation

See: GRE

GRE

encapsulation, 2-36

protocol, 2-36

routing, 2-36

guard band, 6-11

guideline

delay, 2-60

delay diagram, 2-61

end-to-end, 2-60

end-to-end diagram, 2-61

VoIP, 2-60

VoIP diagram, 2-61

.............................................................

H handoff, 7-76

1xEV-DO and 3G-1X, 7-97

AT, 7-94

border, 2-80

distance based, 7-99

forward link, 7-76

forward link with DSC, 3-51

gain, 5-24

idle inter-PCF, 2-80

inter-PCF, 2-79, 7-97

inter-system, 2-79

non-IFHO, 7-94

PCF, 2-80

PDS� from 3G-1X to

1xEV-DO systems, 2-79

PDS� from 3G-1X to

1xEV-DO systems, idle, 2-80

PSD�, 2-80

reverse link, 7-97

system, 2-79, 2-80, 2-80

virtual, 7-89

virtual soft, 3-54

VoIP, 3-51

header

compression, 2-56, 2-57

transmission, 2-56

VoIP, 2-56

header, compression

compression, 2-56

hierarchy

paging, 7-53

High Rate Packet Data

Evolved, 2-45

host-to-network interface, 2-23

HRPD, 2-48

HSGW, 2-45

hybrid

AT, 2-67, 2-68

terminal, 2-67

.............................................................

I I-Phase, 3-86

IA-856A

architecture, 2-23, 2-29

identifier

terminal, 2-36

UATI, 2-36

unicast, 2-36

idle mode, 7-20

idle state, 7-15

pilot channel, 7-30

protocol, Aev A, 7-26

sets, 7-30

idle, time slot, 3-11

IFHO

A� directed, 7-99

benefit, 7-92

decision process, 7-92

directed, 7-95

distanced based, 7-99

flow chart, 7-92

mobile-assisted, 7-94

multiple carriers, 7-91

neighbor list, 7-93

non-IFHO handoff, 7-94

thresholds, 7-99

validity check, 7-100

IMS, 2-53

interface, 2-54

RA�, 2-54

Index

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

IN-7

Page 558: 1xev-Do Rf Engineering

IMT-2000

ITU vision, 1-6

services, 1-9

standards, 1-8

information rate, 5-19

initialization state, AT, 7-13

inner loop power control, 7-109

inter-frequency handoff

See: IFHO

inter-operability support, 1-10

inter-probe, 7-11

inter-sequence, 7-12

inter-system

handoff, 2-79

intercell interference, 5-62

interface, 3-1

IMS, 2-54

protocol, 2-14

RA�, 2-54

interference

computing total, 5-44

controlling in each sector, 7-75

density, 5-15

determining margin, 5-18

determining receiver margin,

5-52

edge coverage, limited case,

5-45

margin, 5-17

ratio, 5-62

traffic channel, total, 5-46

users, 5-56

interlace

BCMCS channel, 7-104

multi-slot, 3-45, 3-47

slot data, 3-45

interleaver, turbo, 3-79

interleaving bits, 5-22

internet

IP, 2-42

layer, 2-21

mobile, 2-42

mobile access, 2-43

mobile IP, 2-43

protocol, 2-43

RA� to VP�, 2-39

stack, 2-43

internet protocol

See: IP

IP

address assignment, 2-7

assignment, 2-73

connection, 2-37, 2-38, 2-40,

2-41

internet, 2-42, 2-43

mobile, 2-7, 2-34, 2-41, 2-42,

2-43, 2-73

network, 2-38, 2-40, 4-37

network elements, 4-37

private, 2-38, 2-40

protocol, 2-40, 2-43

reference, 2-16

simple, 2-7, 2-34

stack, 2-40, 2-43

voice over, 1-42

IS-95

evolution to 3G-1X, 1-16

turbo coder, 1-17

isotropic antenna path loss, 5-27

isotropic power, EIRP, 5-14

ITU

3G vision, 1-5

IMT-2000 minimum data rate,

1-6

.............................................................

K keep alive, 7-47

.............................................................

L Last Active Set, 7-52

Last Seen R�C, 7-52

Last_Active_Set, 7-58, 7-60

Last_Seen_R�C, 7-60

latency

acceptable queue delay, 5-71

packet size, 1-44

power boost transmission, 3-97

power control, 7-114

Rev 0, 1-13

Rev A, 1-44

Rev A compared to Rev 0,

1-32

layer

application, 2-20

architecture, 2-23

connection, 2-27

internet, 2-21

MAC, 2-28

physical, 2-28, 3-37

physical, packet bit sizes, 3-24

security, 2-27

session, 2-26

stream, 2-26

subtype, MAC, 1-33

transport, 2-20

leaky bucket, 7-117

Index

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

IN-8 401-614-323Issue 16 October 2009

Page 559: 1xev-Do Rf Engineering

limitation, forward and reverse

link, 5-4

link command, 3-108

load constraints, reverse link,

7-111

load control, 7-120

location

9218 Macro cards, 4-27

circuit pack, 4-27

measurement, 2-82

report, 7-15

tracking, 2-75

update protocol, 2-72, 2-76

Location Update Feature

See: LUP

log-normal, fade, 5-25

lookup

DRC offset, 3-49

low-latency

power boost, 3-97

LTE, 2-45

LUP, 2-77

.............................................................

M MAC

channel, 3-40

channel generation, 3-41

channel multiplexing, 3-43

enhanced access, 3-104

enhancement, 1-45

indices, 7-73

layer, 2-28

layer packets, 3-29, 3-32

layer Rev A, 2-31

layer subtypes, 1-33

protocol, 1-33

subtype 3, 3-96

walsh codes, 7-73

MAC index, 3-33

MAIFHO, 7-99

maintenance

pilot drop timer, 7-78

PPP, 2-71

session, 2-71, 7-45

MCDO, 2-48

message

examples, 7-22

�eighborList, 7-86

route update, 7-16

TrafficChannelAssignment,

7-22

UATIAssignment, 7-22

UATIRequest, 7-15, 7-16

message distance

RUR, 7-66

MFFU, 4-36

migration

1xEV-DO, 1-12

1xEV-DO Rev A, 1-13

Mixed

DOS method type, 7-51

QoS paging logic, 7-69

mixed mode

hardware, 4-25

mobile originated

DOS, 7-68

mobile-assisted IFHO, 7-94

mobility server, 2-5

FMS, 4-32

model maps, OSI to TCP/IP

OSI to TCP/IP, 2-16

modular cell

collocation 1xEV-DO and

PCS, 4-29

collocation 1xEV-DO and

Series II, 4-30

modulation

16QAM, 3-21

8PSK, 3-21

BPSK, 3-21

code, 3-19, 3-91

QPSK, 3-21

reverse link, 3-90

type, 3-21

monitor

AT, 7-22

monitor sub-state, 7-22

mult-carriers

three carriers, 4-22

Multi-Carrier, 2-47

multi-carrier

CDMA2000, 1-11

feature, 4-14

multi-mode cells, 4-3

multi-slot

data interlacing, 3-45

interlace with early

termination, 3-47

packet transmission, 3-45

Multi-User Packet

See: MUP

multicarrier

five, 4-16

multiple carriers, IFHO, 7-91

Index

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

IN-9

Page 560: 1xev-Do Rf Engineering

multiple user, MAC layer, 3-32

multiplexing

MAC channel, 3-43

packet, 3-27

MUP, 3-68

.............................................................

N negotiation

configuration procedure, 7-41

open a session, 7-39

neighbor list, 7-93

selection algorithm, 7-86

�eighbor R�C, 7-52, 7-60

neighbor set, 7-86

�eighborList, 7-86

message, 7-86

network

architecture, radio access, 2-1

connection, 2-40

data flow, 2-4

data transfer, 2-19

IP, 2-38, 2-40, 4-37

private, 2-38, 2-40

protocol, 2-40

R1SR R�C, 2-12

RA�, 4-3

Rev A, 2-53

security, RA�, 2-8

stack, 2-40

noise, 5-16

base station, 5-55

density, spectral, 5-55

total, 5-15

total thermal, 5-46

normal

AT setup, 7-34

fade, 5-25

normal packet, 3-47

normal termination, 3-45

.............................................................

O octet timestamp, 3-66

offset

DRC, 3-50

DRC lookup, 3-49

frame, 7-72

pilot P�, 7-82

P�, 7-81

RAB, 7-74

Rev ADRC, 3-49

one URCIIs, 4-22

OneBTS cabinet, 4-10

open loop power control, 7-108

operation

1xEV-DO, 7-5

suspend mode, 7-28

OSI

reference, 2-16

to TCP/IPmodel, 2-16

outer loop power control, 7-108

overlay design, 6-2

overload control

implementation, 7-112

Rev A, 7-114

.............................................................

P packet, 3-103

bit size for control channel,

3-37

MAC layer, 3-29, 3-32

multi-slot transmission, 3-45

multiplexing, 3-27

normal, transmission, 3-47

packet size, 3-79

physical layer, 3-79, 3-99

physical layer bit size, 3-24

Rev 0 bit, 3-24

reverse traffic data channel,

3-79

Packet Control Function

See: PCF

packet data

early termination, 3-47

transmission, 1-26, 1-28, 3-47

Packet Data Service �ode

See: PDS�

packet size

latency, 1-44

physical layer, 1-32

Rev 0 transmission, 3-13

Rev A scheduling, 1-29

packet sizes

new, 3-103

page mask, 7-28

paging, 7-48

areas, abbreviations, 7-52

attempts with QoS, 7-56

counts, 7-59, 7-64

de-escalation, 7-63

default, 7-55

definitions, 7-51

efficiency improvement, 7-63

escalation, 7-58

escalation strategy, 7-59

EVDO considerations, 7-53

Index

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

IN-10 401-614-323Issue 16 October 2009

Page 561: 1xev-Do Rf Engineering

examples, 7-58

hierarchy, 7-53

new methods, 7-60

parameters, 7-62

priorities, 7-53

priority, 7-60

QoS, 7-56, 7-63

time, 7-54

timeout, 7-63

paging attempt

definition, 7-51

parameters

paging, 7-62

path loss, 5-6

building/vehicle penetration

loss, 5-27

computing delta, 5-43

delta value, 5-42

PCF, 4-34

border, 2-80

handoff, 2-80

handoff 3G-1X to 1xEV-DO,

2-79, 2-80

inter-PCF handoff, 7-97

PSD�, 2-80

system, 2-80

PCS

band, 6-10

collocation with 1xEV-DO,

4-29

distribution, 6-10

forward link budget

spreadsheet, 5-36

reverse link, 5-9

reverse link budget, 5-11

spreadsheet, 5-9

PDS�, 4-37

inter-PCF handoff, 2-79

PPP connection, 2-35

peer-to-peer communication

communication, 2-34

penetration

building, 5-27

performance

AT, 5-31

Rev A, 5-67

PF scheduling algorithm, 3-57

physical layer, 2-28

control channel, 3-37

enhancements, 1-45

packet bit size, 3-77, 3-99

Rev A, 2-31

subtype, 1-32

pilot

auxiliary, 3-98

burst timing, 3-39

channel, 3-39, 3-104

channel Ec/�t, 5-55, 5-59

drop timer maintenance, 7-78

dynamic, 7-79

idle state, 7-30

P�, 7-81

P� offset, 7-82

sets, 7-77

uplink channel, 1-16

pilot channel

noise density, 5-55

RRI, 3-76

pilot signal

slewing, 7-100

P�

offset, 7-81, 7-82

pilot, 7-81

point-to-point protocol

See: PPP

pole capacity, 5-52

pole point capacity calculation,

5-69

power

customer control, 4-25

power boost, low-latency, 3-97

power control, 5-22

closed loop, 7-108

forward, 1-19

inner loop, 7-109

latency, 7-114

open loop, 7-108

outer loop, 7-108

Rev 0, 7-108

Rev A, 7-114

power level for termination target,

5-64

PPP

AT to PDS�, 2-35

connection, 7-43

establishing a connection, 7-43

maintenance, 2-71

point-to-point, 2-21

reconfiguration, 2-74

session, 2-71

trigger, 2-74

preamble

access probe, 7-10

Index

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

IN-11

Page 562: 1xev-Do Rf Engineering

bit insertion for data rate, 3-35

data, 3-34

MUP, 3-68

new for Rev A, 3-103

Rev A, 3-101

Rev o, 3-99

priorities

paging, 7-53

priority

fairness, 3-67

neighbor list, 7-86

system, 2-69

priority paging, 7-60

example, 7-60

private network

connection, 2-38

profile IDs, 7-57

protocol, 2-29

air link management, 7-7

AT stack, 2-18

connection, 7-5

encapsulation, 2-36

GRE, 2-36

idle state, 7-26

interface, 2-14

internet, 2-21, 2-43

IP, 2-40, 2-43

layer, 7-5

location update, 2-72

location update procedure,

2-76

MAC layer, 1-33

management, 7-7

mobile, 2-43

network, 2-40

PPP, 2-21

private, 2-40

RA� interface, 2-34

Rev A application layer, 2-30

Rev A connection layer, 2-30

Rev AMAC layer, 2-31

Rev A physical layer, 2-31

Rev A stream layer, 2-30

routing, 2-36

stack, 2-40, 2-43, 2-59

stack diagram, 2-59

stack interface, 2-18

TCP, 2-20

TIA-856A, 7-5

VoIP, 2-59

VoIP diagram, 2-59

protocol stack

connection, 2-40

PSD�

border, 2-80

handoff, 2-80

idle inter-PCF handoff, 2-80

PCF, 2-80

system, 2-80

PTT

examples, 7-58

FlowProfile, 7-57

obsolete paging counts, 7-64

paging enhancements, 7-60

slotted timer, 7-64

.............................................................

Q QoS, 3-65, 7-60

DOS, 7-68

flexible scheduler, 3-58

flow capacity, 3-67

paging controls, 7-63

profile IDs, 7-57

Rev A scheduling, 1-29

reverse link channels, 5-75

scheduler flexibility, 3-68

QoS paging, 7-56, 7-68

definition, 7-51

logic, 7-69

QPSK, 3-21

spreading, 3-80

quadrature phase shift keying

See: QPSK

quality

capacity, coverage trade-off,

1-22

managing, 3-65

signal, 5-19

queue, 3-66

delay, 5-71

.............................................................

R RAB

length, 7-74

offset, 7-74

radio

controller, URC-II, 4-12

environment, 1-6

RAS, 2-4

radio access network

architecture, 2-1

Radio Access �etwork

See: RA�

radio access system

See: RAS

Index

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

IN-12 401-614-323Issue 16 October 2009

Page 563: 1xev-Do Rf Engineering

Radio Cluster Controller

See: RCC

radio link protocol

See: RLP

RA�, 4-3

architecture, 2-1

features, 1-41

IMS core, 2-54

interface, 2-54

internet connectivity to VP�,

2-39

network security, 2-8

protocol interface, 2-34

RAS, 2-4

rate

dynamic control, 1-26

ITU IMT-2000 vision, 1-6

preamble, 3-35

Rev A, low, 5-51

reverse link budget, 5-11

RCC, 4-36

real time

limitation voice transmission,

1-22

redundancy, 3-45

incremental for reverse link,

3-87

registration report, 7-15

repage timer, 7-64

resources

paging, 7-54

restrictions

DOS, 7-68

Rev 0

access channel, 3-99

architecture, 2-23, 2-26

bits per packet, 3-24

capacity, 5-49

overload control, 7-111

power control, 7-108

reverse link, 3-72

reverse link limitations, 3-81

scheduling algorithm, 1-28,

3-57

transmission format, 3-13

Rev A

application layer, 2-30

architecture, 2-29

basic features, 1-37

bit packing, 3-25

capacity, 5-49

changes from Rev 0, 3-71

changes introduced, 3-83

connection layer, 2-30

coverage, 1-35

data rate, 5-51

DRC offset, 3-49

DRC transmission format, 3-15

DSC, 3-51

enhanced, 1-39

enhanced access channel,

3-101

enhancement, 1-45

features, 1-32

forward link budget, 5-39

forward link budget,

1536-3072kbps, 5-40

forward link budget, 4.8-76.8

kpbs, 5-38

idle state protocol, 7-26

latency, 1-44

MAC layer, 2-31

network, 2-53

overload control, 7-114

performance, 5-67

physical layer, 2-31

power control, 7-114

release 27, 1-35

release schedule, 1-35

reverse link budget, 5-11

scheduler flexibility, 3-68

scheduling algorithm, 1-29,

3-65

stream layer, 2-30

transmission format, 3-15

Rev A�etworks

PTT, 7-58

RevB, 2-47

reverse link

3G-1X similarity, 5-4

average number, 5-75

budget, 5-4, 5-9

capacity, 5-55, 5-64

channel coding, 3-86

data channel, 1-30

data rate, 1-13, 3-72, 3-92,

3-95

Eb/�t, 5-21

forward link compared, 5-53

handoff, 7-97

I-Phase, 3-86

limitation, 5-4

limitation for Rev 0, 3-81

loading constraints, 7-111

Index

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

IN-13

Page 564: 1xev-Do Rf Engineering

modulation, 3-90

payload size, 3-90

PCS budget, 5-9

redundancy, 3-87

Rev 0, 3-72

Rev A, 5-11

silence period, 7-9

throughput, 5-63

traffic, 3-71

reverse traffic

channel, 3-74

channel generation, 3-74

data channel, 3-79

sub-channel, 3-75

RF

AT, 5-31

capacity and coverage, 5-1

environment data rate, 3-49

Rise over Thermal

See: RoT

RLP, 2-35

R�C

DSC selection process, 3-52

eHRPD, 2-45

Ethernet connections, 2-12

Group, 7-52, 7-60

Handoff Enhancement, 1-37

Last Active, 7-52

Last Seen, 7-52, 7-60

�eighbor, 7-52, 7-60

page mask usage, 7-28

paging areas, 7-52

paging example, 7-58

paging parameters, 7-55

R1SR, 2-12

scheduling flexibility, 3-25

Security, 2-13

twelve per service node, 2-6

R�C group

service node, 7-53

RoT, 7-120

router

ethernet, 4-36

RouteuUpdate message, 7-16

RPC channel, 7-110

RRI

channel, 3-91

pilot, 3-76

RUM, 7-99

RUM process, 7-65

RUR

deriving minimum distance,

7-66

DOS method type, 7-51

message distance, 7-66

paging radius, 7-66

QoS paging logic, 7-69

radius, 7-66

.............................................................

S scheduler

flexibility for Rev A, 3-68

flexible, 3-58

scheduling

algorithm, 1-28

algorithm for Rev 0, 3-57

algorithm for Rev A, 3-65

algorithm, Rev 0, 1-28

algorithm, Rev A, 1-29

g-fair, 3-63

rate control algorithm, 3-58

sector

capacity, Rev 0/Rev A, 5-49

cell interference, 5-44

controlling interference, 7-75

maximize throughput, 3-57

throughput, 5-80

security

layer, 2-27

level, 2-13

RA�, 2-8

sensitivity

forward link receiver, 5-47

Series II

collocation with 1xEV-DO,

4-30

server

AAA, 4-37

AP, 4-34

service measurement

throughput target, 3-61

service node

boundaries, 7-53

logical frame numbering

increase, 2-6

R�C group, 7-53

twelve R�C, 2-6

session

maintenance, 7-45

session layer, 2-26

TIA-856A, 7-39

setup

connect, 7-37

Index

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

IN-14 401-614-323Issue 16 October 2009

Page 565: 1xev-Do Rf Engineering

normal, AT, 7-34

sub-state, 7-34

shadow fade, 5-7

signaling

channel, 5-32

forward link, 5-32

SIP, 2-59

silence period, reverse link, 7-9

single user, MAC layer, 3-29

SIP

VoIP, 2-59

six carriers, 4-18

hardware, 4-18

sleep mode control cycle

control cycle, 7-24

sleep sub-state, 7-24

slot data, 3-45

slotted timer, 7-64

soft handoff, 3-54

gain, 5-24

specification, AT, 5-31

speech frame

delay estimates, 2-61

spreading

quadrature, 3-80

walsh code, 3-80

spreadsheet

forward link, 5-36

forward link budget, PCS, 5-36

PCS reverse link budget, 5-9

stack

connection, 2-40

end-to-end, 2-59

end-to-end diagram, 2-59

internet, 2-43

IP, 2-40, 2-43

mobile, 2-43

network, 2-40

private, 2-40

protocol, 2-40, 2-43, 2-59

protocol diagram, 2-59

VoIP, 2-59

VoIP diagram, 2-59

standalone

deployment, 4-38

design, 6-2

standards

evolution, wireless, 1-10

IMT-2000, 1-8

start all tests

See: TAA

stream layer, 2-26

Rev A, 2-30

sub-channel

time-share, 3-7

traffic, 3-75

sub-frame, 3-84

duration, 3-89, 3-89

frame, 3-89

maximum, 3-89

structure, 3-84

sub-state

AT, 7-22

idle mode, 7-20

monitor, 7-22

setup, 7-34

sleep, 7-24

subtype

MAC, 3-96

MAC layer, 1-33

physical layer, 1-32

supplemental channel, 1-19

suspend mode of operation, 7-28

syntax, CLI, 3-107

.............................................................

T T2P

T2PInflow, 3-95

target level, 3-93

target level diagram, 3-93

TAA, 3-110

target

capacity, determining, 5-71

maximum throughput, 3-59

minimum throughput, 3-59

service measurement

throughput, 3-61

T2P level, 3-93

T2P level diagram, 3-93

TCP, 2-20

TCP/IP OSI model maps

OSI model maps, 2-16

terminal

AT, 2-67

hybrid, 2-67

identifier, 2-36

UATI, 2-36

unicast, 2-36

termination

early packet transmission, 3-47

early, multi-slot, 3-47

Index

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

IN-15

Page 566: 1xev-Do Rf Engineering

normal packet termination,

3-47

normal, with data interlacing,

3-45

power savings, 7-114

target, power level, 5-64

termination target, 7-115

test application

feature, 3-106

forward link, 3-107

thermal

noise, total, 5-46

RoT, 7-120

three carriers

dependencies, 4-23

frame configurations, 4-23

throughput

maximum target, 3-59

minimum target, 3-59

reverse link, 5-63

sector, 3-57, 5-80

target service measurement,

3-61

TIA-856A

architecture, 7-5

layer, 7-39

time-share, sub-channel, 3-7

timeout

paging, 7-63

timer

contextual repage, 7-64

slotted, 7-64

timer, pilot drop, 7-78

timestamp, octet, 3-66

topic type attribute

How to set for fact topics, 2-46

total interference, computing, 5-44

TPC/IP

IP, 2-16

reference, 2-16

traffic, 5-65

channel gain, 5-59

channel request, 7-35

channel resource allocation,

7-71

forward link data, 1-26

forward link Eb/�o value, 5-31

generation of reverse traffic,

3-74

load, data, 5-72

model for active data session,

5-69

physical, 3-79

reverse channel, 3-74

reverse link, 3-71

reverse link data, 1-30

reverse link data rates, 3-72

sub-channel, 3-75

total interference, channel,

5-46

traffic data channel, 3-24

transition point, 7-115

transmission

compression, 2-56

early termination, 3-47

eliminate voice, 1-22

format code, 3-19

format for DRC and Rev A,

3-15

format for Rev A, 3-15

header, 2-56

limitation of real time, 1-22

low-latency, 3-97

multi-slot, 3-45

packet data, 1-26, 1-28

Rev 0, 3-13

termination for normal packet,

3-47

type, 3-19

VoIP, 2-56

transmission control protocol

See: TCP

transmit

power, 3-9

power sharing 3G-1X and

1xEV-DO, 3-9

transmit power

AT, 5-7

AT maximum, 5-7

calculation, 5-42

transport layer, 2-20

trigger

PPP, 2-74

reconfiguration, 2-74

turbo coder, 1-17

.............................................................

U UATI

identifier, 2-36

terminal, 2-36

unicast, 2-36

UATIRequest, 7-15, 7-16

UDP, 2-21

Index

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

IN-16 401-614-323Issue 16 October 2009

Page 567: 1xev-Do Rf Engineering

unicast

identifier, 2-36

terminal, 2-36

UATI, 2-36

uplink pilot channel, 1-16

URC-II, 4-12

URCII

one, 4-22

user

multiple, 3-32

single, 3-29

user datagram protocol

See: UDP

users

active versus total, 5-76

theoretical maximum, 5-58

.............................................................

V vehicle speed

bit interleaving, 5-22

Eb/�t, 5-21

power control, 5-22

virtual soft handoff, 3-54, 7-89

vision

ITU, 3G, 1-5

minimum data rate, 1-6

voice

IP, 1-42

real-time transmission, 1-22

VoIP

basic, 2-44

compression, 2-56

delay, 2-60

delay diagram, 2-61

end-to-end, 2-59, 2-60

end-to-end diagram, 2-59, 2-61

guideline, 2-60

guideline diagram, 2-61

handoff, 3-51

header, 2-56

protocol, 2-59

protocol diagram, 2-59

service measurements, 3-51

SIP, 2-59

stack, 2-59

stack diagram, 2-59

transmission, 2-56

.............................................................

W walsh code, 3-33

spreading, 3-80

walsh codes, 7-73

waveform

carrier, 6-3

cellular carrier, 6-3

wireless standards evolution, 1-10

Index

...................................................................................................................................................................................................................................

...................................................................................................................................................................................................................................

401-614-323Issue 16 October 2009

IN-17

Page 568: 1xev-Do Rf Engineering