Lucent Technologies

Bell Labs Innovations

Discussion of 1xEV-DV RAN Standardization: PDCH Handoffs

Nancy Y. Lee nylee@lucent.com

NYL 8/27/2003 Lucent Technologies 1

Outline

IOS Interfaces Network configuration and handoff types The 1xEV-DV Packet Data Channel (PDCH) PDCH Hard Handoff PDCH Soft Handoff and Cell Selection Conclusions and Recommendations

NYL 8/27/2003 Lucent Technologies 2

IOS Interfaces and PDCH Handoff Impacts

A1/A2 IVHHO Inter-Vendor F-PDCH and R-PDCH HHO

A3/A7 signaling IVSHO leg add/drop and SCH burst scheduling Inter-Vendor F-PDCH and R-PDCH active set leg add/drop Inter-Vendor SHO, Cell selection, queue synchronization?

A3 bearer IVSHO and SCH burst traffic Define new frame formats for F-PDCH and R-PDCH traffic Inter-Vendor SHO, Cell selection, queue synchronization?

A10/A11 packet data mobility A10 no change A11 authorization and accounting?

Plus:

ANSI-41 carries A1 signaling information for IV Inter-MSC HHO No changes expected

NYL 8/27/2003 Lucent Technologies 3

Outline

IOS Interfaces Network configuration and handoff types The 1xEV-DV Packet Data Channel (PDCH) PDCH Hard Handoff PDCH Soft Handoff and Cell Selection Conclusions and Recommendations

NYL 8/27/2003 Lucent Technologies 4

Likely Configurations and Handoff Types

Lucent Market Vendor X or Vendor X/Vendor Y Market
Vendor X Cells
C1

Soft HO/Cell Selection

A B C Intra-Vendor, Intra-MSC SHO/CS Intra-Vendor, Inter-MSC SHO/CS Inter-Vendor SHO/CS

Lucent MSC 1
Lucent Cells
A

A
C2

Vendor X MSC 3

Hard HO
E

D E F G

Intra-Vendor, Inter-MSC HHO Inter-Vendor, Intra-MSC HHO Inter-Vendor, Inter-MSC HHO (ANSI-41) Intra-Vendor, Inter-BSC, Intra-MSC HHO

Vendor Y IOS BS

Notes: A and B are Proprietary E uses A1/A2 F uses A1/A2 + ANSI-41 C uses A3/A7 C2 and E are very rare
5

Lucent MSC 2
NYL 8/27/2003

Vendor X MSC 4
Lucent Technologies

Summary of PDCH SHO/HHO Cases

Case A HO Type Cell Select/ Soft Soft Vendor Change? Intra MSC Change? Intra Open Interface Support? N/A (Proprietary) N/A (Proprietary) Not Recommended Proprietary or A1? N/A? HHO to FCH: OK HHO to PDCH: Defer Proprietary or A1?
Lucent Technologies

Comments No standards issues. No standards issues. Support for cell selection is a vendor implementation decision. Extremely complex and difficult to ever standardize. C2 unlikely to exist in practical applications. If Vendor Y wants A1 support, see recommendations for Case F. Unlikely to exist in practical applications HHO to FCH then target adds F-PDCH: no issues. Alternative: dormant handoff. Open interfaces for PDCH HHO recommended for later phase of IOS due to schedule impact. MSC-BSC interfaces may or may not be A1/A2.

Intra

Inter

C1/C2 D E

Soft Hard Hard

Inter Intra (Vendor Y) Inter

Inter/Intra Inter Intra (Inter-BSC)

F1/F2

Hard

Inter

Inter (ANSI-41)

G
NYL 8/27/2003

Hard

Intra (Vendor Y)

Intra (Inter-BSC)

If Vendor Y wants A1 support, see recommendations for Case F.

6

Outline

IOS Interfaces Network configuration and handoff types The 1xEV-DV Packet Data Channel (PDCH) PDCH Hard Handoff PDCH Soft Handoff and Cell Selection Conclusions and Recommendations

NYL 8/27/2003 Lucent Technologies 7

The 1xEV-DV Packet Data Channel (PDCH)

1xEV-DV PDCH (Packet Data Channel) is a high speed channel that carries bearer traffic and optionally signaling traffic Has its own active set (may be different from FCH active set) CPCCH (Common Packet Control Channel) is a dedicated control channel for the PDCH

Forward PDCH (F-PDCH) is a shared high speed channel that may carry both signaling and bearer traffic F-PDCH has cell selection, not soft handoff Only one cell (sector) in the active set transmits F-PDCH to the MS at a time Cell selection = MAC layer control mechanism whereby the MS picks the serving sector (selected cell) and points to it Cell switching = MS changes the serving sector by transmitting a switching pattern for a switching interval specified by the source BS

Reverse PDCH (R-PDCH) has both cell selection and soft handoff

NYL 8/27/2003 Lucent Technologies 8

The 1xEV-DV Packet Data Channel (contd)

EVDV configurations dont have to have a forward FCH or DCCH. Example: F-PDCH + F-CPCCH + R-FCH

Can HHO F-PDCH to F-FCH. The target BS (the new source BS) would then send UHDM to establish the F-PDCH. Pros: have to support this anyway in case the target BS only supports 3G-1X Cons: requires an extra over-the-air UHDM, but IVHHOs are rare

NYL 8/27/2003 Lucent Technologies 9

Outline

IOS Interfaces Network configuration and handoff types The 1xEV-DV Packet Data Channel (PDCH) PDCH Hard Handoff PDCH Soft Handoff and Cell Selection Conclusions and Recommendations

NYL 8/27/2003 Lucent Technologies 10

Forward Link (F-PDCH) Inter-Vendor Hard Handoff

Considerations: Affected boundaries are rare. Dropped F-PDCH does not imply dropped packet data session!
MS may have other active physical channels (FCH, DCCH) to hand off Dormant HO: If supervision occurs and inter-MSC boundary corresponds to a packet zone boundary, then MS will reoriginate

TSG-A has never dealt with IVHHO of a packet data channel

TSG-A decided that IVHHO support not needed for 3G-1X SCH TSG-A decided that IVHHO support not needed for 1xEV-DO Forward Traffic Channel

NYL 8/27/2003 Lucent Technologies 11

Forward Link IVHHO (contd)

Standardization Issues: Should IOS support handoff to F-PDCH, handoff to F-FCH, or both? If both, who decides source or target?
HHO to F-FCH is simpler and more general What call flows should be included in the IOS?

Queue synchronization
Will unsent data be dropped or sent to the target BS? If so, by the source BS, PCF, or PDSN? Will the source BS be allowed to continue sending data to the MS after sending Handoff Required to the MSC? After sending Handoff Direction to the MS? If so, when and how will the source BS inform the target BS of the last successfully transmitted PDU?

Issues are certainly resolvable, but it will take time. Minimize number of issues to avoid getting bogged down.

NYL 8/27/2003 Lucent Technologies 12

Reverse Link (R-PDCH) Inter-Vendor Hard Handoff

Considerations: Affected boundaries are rare. Dropped R-PDCH does not imply dropped packet data session!
MS may HHO other physical channels (FCH, DCCH) Dormant HO: If supervision occurs and inter-MSC boundary corresponds to a packet zone boundary, then MS will reoriginate with DRS=1

HHO will effectively re-initialize the R-PDCH

Standardization issues: What does MS do with ARQ transactions that were in progress at the source BS?

NYL 8/27/2003 Lucent Technologies 13

Outline

IOS Interfaces Network configuration and handoff types The 1xEV-DV Packet Data Channel (PDCH) PDCH Hard Handoff PDCH Soft Handoff and Cell Selection Conclusions and Recommendations

NYL 8/27/2003 Lucent Technologies 14

Forward Link (F-PDCH) Inter-Vendor Cell Selection

Considerations: IOS doesnt support IVSHO of other forward high speed data channels (3G-1X F-SCH and EVDO Forward Traffic Channel) PDCH active set is on average smaller than for voice
Only transmit when a leg has strong CQI. Voice needs a larger active set to ensure at least one good leg at all times. Small active set means inter-vendor cell selection is less likely.

Standardization Issues: How much should the source BS know about its neighbors F-PDCH resources (Walsh codes, MAC IDs, etc.) Flow control between source and target when a target cell is the selected cell
PDU buffer size at target cell is implementation dependent How and where will MS NACKs (retransmissions) be handled

NYL 8/27/2003 Lucent Technologies 15

Forward Link (F-PDCH) Inter-Vendor Cell Selection (contd)

Standardization Issues (contd): Queue synchronization

New serving sector retransmitting a PDU or skipping PDUs is bad. Move or drop data queued at the old serving sector? Drop or transfer state information for transactions in progress on the ARQ?

Starting clean with new ARQ transactions creates the possibility of duplicate transmissions

Identifying the serving sector (selected cell)

Many different methods; proprietary and highly implementation dependent

Cell switching
How will source BS know the CQI pattern recognition capabilities of the target BS?

Many different switching patterns Different switching interval strategies: short switching duration or long switching duration with early termination?

NYL 8/27/2003 Lucent Technologies 16

Reverse Link (R-PDCH) Inter-Vendor SHO and Cell Selection

Considerations: R-PDCH air interface standard is still wide open; TSG-A may not have time to digest and do its work Likely to end up with vendor-specific combinations of autonomous, scheduled, and rate controlled modes for R-PDCH
Mix will be implementation dependent and vary with MS location and signal strength: e.g., scheduled mode with no SHO one leg when signal is stronger vs. rate controlled mode with multiple legs when signal is weaker

Standardization issues: Rate control / scheduling by source BS but source BS needs to know target BS resource availability (e.g., power headroom) in real time
3G-1X SCH burst scheduling approach wont work; need a new scheme What information needs to be shared and how frequently

Hybrid ARQ may require faster inter-BS communication (< 10ms) than A3/A7 supports How and where will NACKs (retransmissions) be handled

NYL 8/27/2003 Lucent Technologies 17

Outline

IOS Interfaces Network configuration and handoff types The 1xEV-DV Packet Data Channel (PDCH) PDCH Hard Handoff PDCH Soft Handoff and Cell Selection Conclusions and Recommendations

NYL 8/27/2003 Lucent Technologies 18

Conclusions

F-PDCH IVHHO: defer to a future release. To date, TSG-A hasnt seen the need for packet data channel IVHHO. Not needed for initial deployment: affected boundaries are rare. Simpler alternatives: HHO to F-FCH or dormant handoff. Issues could jeopardize the 1Q04 deadline. Useful optimization to consider for a future release.

R-PDCH IVHHO: defer to a future release. To date, TSG-A hasnt seen the need for packet data channel IVHHO. Not needed for initial deployment: affected boundaries are rare. Simpler alternatives: HHO to F-FCH or dormant handoff. R-PDCH air interface standards remain too open. Wont have enough time to do the work and meet 1Q04 date. Useful optimization to consider for a future release.

NYL 8/27/2003 Lucent Technologies 19

Conclusions (contd)

F-PDCH IVSHO: not recommended for standardization at this time. F-PDCH will have fewer legs than a voice F-FCH and hence opportunities for IVSHO will be less likely F-PDCH SHO is highly complex and dependent on scheduling strategy, cell switching algorithms, etc. We can do it well in a proprietary implementation, but: Standardizing IVSHO will be lengthy, contentious, and result in a lowest common denominator solution that cripples optimized solutions.

R-PDCH IVSHO: not recommended for standardization at this time. Air interface standard (scheduled approach) may make it not meaningful. Hybrid ARQ may require faster inter-BS communication than A3/A7 supports. Wait and see how air interface standard ends up and then reassess.

NYL 8/27/2003 Lucent Technologies 20