A20-20030818-009 Lucent EVDV Handoff

7/30/2019 A20-20030818-009 Lucent EVDV Handoff

1/20

1Lucent Technologies

NYL

8/27/2003

Lucent TechnologiesBell Labs Innovations

Discussion of 1xEV-DV RAN

Standardization: PDCH Handoffs

Nancy Y. Lee

[email protected]


2/20


NYL

8/27/2003

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


3/20


NYL

8/27/2003

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


4/20


NYL

8/27/2003

Outline

IOS Interfaces



PDCH Hard Handoff




5/20


NYL

8/27/2003

Likely Configurations and Handoff Types

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

Vendor X

Cells

Lucent

Cells

Vendor YIOS BS

Vendor X

MSC 3

Lucent

MSC 1

Lucent

MSC 2

A

BD F

E

A

Vendor X

MSC 4

C1

C2

Lucent

Market

Vendor X or

Vendor X/Vendor Y

Market

D

G

Soft HO/Cell SelectionA Intra-Vendor, Intra-MSC SHO/CS

B Intra-Vendor, Inter-MSC SHO/CSC Inter-Vendor SHO/CS

Hard HOD Intra-Vendor, Inter-MSC HHO

E Inter-Vendor, Intra-MSC HHOF Inter-Vendor, Inter-MSC HHO

(ANSI-41)

G Intra-Vendor, Inter-BSC, Intra-MSC

HHO


6/20


NYL

8/27/2003

Summary of PDCH SHO/HHO Cases

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.

HHO to FCH:OK

HHO to PDCH:

Defer

Inter

(ANSI-41)InterHardF1/F2

Unlikely to exist in practical applicationsN/A?Intra

(Inter-BSC)InterHardE

If Vendor Y wants A1 support, seerecommendations for Case F.

Proprietary orA1?

Intra(Inter-BSC)

Intra(Vendor Y)

HardG

Proprietary or

A1?

Not

Recommended

N/A

(Proprietary)

N/A

(Proprietary)

Open Interface

Support?

Hard

Soft

Soft

Cell

Select/

Soft

HO

Type

If Vendor Y wants A1 support, see

recommendations for Case F.Inter

Intra

(Vendor Y)D

Extremely complex and difficult to ever

standardize.

C2 unlikely to exist in practical applications.

Inter/IntraInterC1/C2

No standards issues.Support for cell selection is a vendor

implementation decision.

InterIntraB

No standards issues.IntraIntraA

Comments

MSC

Change?

Vendor

Change?Case


7/20


NYL

8/27/2003

Outline

IOS Interfaces



PDCH Hard Handoff




8/20


NYL

8/27/2003


1xEV-DV PDCH (Packet Data Channel) is a high speed channel that carriesbearer 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 thePDCH

Forward PDCH (F-PDCH) is a shared high speed channel that may carry bothsignaling 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 servingsector (selected cell) and points to it

Cell switching = MS changes the serving sector by transmitting a switchingpattern for a switching interval specified by the source BS

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


9/20


NYL

8/27/2003

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


10/20


NYL

8/27/2003

Outline

IOS Interfaces



PDCH Hard Handoff




11/20


NYL

8/27/2003

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


12/20


NYL

8/27/2003

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.


13/20


NYL

8/27/2003

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?


14/20


NYL

8/27/2003

Outline

IOS Interfaces



PDCH Hard Handoff




15/20


NYL

8/27/2003

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 toensure 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-PDCHresources (Walsh codes, MAC IDs, etc.)

Flow control between source and target when a target cell is theselected cell

PDU buffer size at target cell is implementation dependent

How and where will MS NACKs (retransmissions) be handled


16/20


NYL

8/27/2003

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 targetBS?

Many different switching patterns

Different switching interval strategies: short switching duration or long switching

duration with early termination?


17/20


NYL

8/27/2003

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 todigest 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 controlledmode with multiple legs when signal is weaker

Standardization issues:

Rate control / scheduling by source BS but source BS needs to know target BSresource 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


18/20


NYL

8/27/2003

Outline

IOS Interfaces



PDCH Hard Handoff




19/20


NYL

8/27/2003

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.


20/20


NYL

8/27/2003

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 lowestcommon 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.

Date post:	14-Apr-2018
Category:	Documents
Upload:	dodnikova
View:	217 times
Download:	0 times

A20-20030818-009 Lucent EVDV Handoff

Documents