Active Call Hand-in in cdma2000 1x

AirvanaQualcomm

October 27th, 20083GPP2 Seoul, Korea

Notice ©2008. All rights reserved.The contributors grants a free, irrevocable license to 3GPP2 and its Organizational Partners to incorporate text or other copyrightable material contained in the contribution and any modifications thereof in the creation of 3GPP2 publications; to copyright and sell in Organizational Partner’s name any Organizational Partner’s standards publication even though it may include all or portions of this contribution; and at the Organizational Partner’s sole discretion to permit others to reproduce in whole or in part such contribution or the resulting Organizational Partner’s standards publication. The contributors are also willing to grant licenses under such contributor copyrights to third parties on reasonable, non-discriminatory terms and conditions for purpose of practicing an Organizational Partner’s standard which incorporates this contribution.This document has been prepared by the contributors to assist the development of specifications by 3GPP2. It is proposed to the Committee as a basis for discussion and is not to be construed as a binding proposal on the contributors. The contributors specifically reserves the right to amend or modify the material contained herein and nothing herein shall be construed as conferring or offering licenses or rights with respect to any intellectual property of the contributors other than provided in the copyright statement above.

1x Hand-in Overview

• When MS moves from macro BS into femto AP coverage while on active voice call, how does handoff occur?

• Main problem: Many femtos over a few available PN offsets– Source BS is currently configured with mapping between target

BS/MSC and the corresponding PN offset in the pilot report– Hand-in target is ambiguous if just rely on PN

• Solution needs to– Support of legacy 1x terminals– No change to legacy macro 1x system– Accurately identify handoff target

‘Current’ Solutions• Blind Handoff

– Blindly setup traffic channel in possible target femto(s), and perform handoff

• In the closed access model, this results in a large number of handoff failures

• In open access, this results in wasted PHY resources in a large number of femtos, since only one of the femtos is the likely target.

• Narrowing candidate target set– Use round-trip and/or IS-801 to estimate AT location– Use intelligent PN planning for further optimization

• Standardize additional messages (APIDM, HSIN etc.)• These techniques do not satisfy every goal in the

previous slide

What can we do for hand-in without changing legacy macro 1x BS or MS?

• Observations on the air-interface– If MS reports Pilot Strength measurement to macro BS containing PN from a

femto in proximity (say Femto 1), then Femto 1 should be able to see RL signal from MS also

– Another Femto AP (say Femto 2) which emits the same PN as Femto 1 will either• Cannot detect RL signal from MS because it is too far, or• Detect RL signal but since Femto 2 is much farther away from MS, therefore

– Detected RL power from Femto 1 (based on the MS RL Long Code Mask) would be much stronger than Femto 2

– Estimated path loss from Femto 1 to MS would be much smaller than Femto 2 to MS

– We refer to this concept in general as Proximity Detection• Observations on the network

– MFIF and Femto APs are all new entities– All information needed to detect MS RL signal (e.g., MS Long Code Mask) are

already in messages for supporting hand-off (e.g., Handoff Request and IS-41 FacDir2 messages)

– MFIF knows PNs that Femtos under it are using

A possible solution• Combine Proximity Detection (to determine handoff

target) with existing IS-41 Handoff Procedures– MFIF can be enhanced to initiate hand-in with many Femto APs

(which uses the same ambiguous PN) at the same time– Femto APs can detect and report proximity metrics (e.g., RL pilot

strength of the mobile RL LCM and path loss) before committing to handoff

– MFIF can compare proximity metrics from multiple femtos and decide to handoff to the femto AP that has the best metric

• Additional standard needed to report proximity metrics from femto to MFIF but no changes to 1x macro system

MS Source BS

24. Voice

1. Voice

19. BS Ack Order

23. Clear Complete T315

18. Handoff Completion Msg

Source MSC

Target MFIF/MSC

Target FemtoAP2

20. HO Complete

17. Reverse Traffic Channel Frames or Traffic Channel Preamble

13. Handoff Command

5. HO Request(+ ‘Ambiguous Flag’)

4. IS-41: FACDIR2(CELL_ID = ‘a’)

22. Clear Command

T7

16. Handoff Commenced

3. Handoff Required(CELL_ID = ‘a’)

8. HO Request Ack (+ proximity metric)

21. IS-41: MSONCH

7. Null forward traffic channel frames

12. IS-41: facdir2 (CELL_ID = ‘a’)

14. HO Direction Msg

15. MS Ack Order

2. PSMM(PN = a)

Target FemtoAP1

6. Target Femto decode RL Frames

5'. HO Request(+ ‘Ambiguous Flag’)

6'. Target Femto decode RL Frames

7'. Null forward traffic channel frames

8'. HO Request Ack (+ proximity metric)

9. Target MFIF picks HO Request Ack that has the

best proximity metric

10. Clear Command

11. Clear Complete

Resource Deallocated

CELL_ID = ‘a’ is a dummy CELL_ID that

MFIF/MSCe knows that corresponds to any femto AP under the

source BS with PN = a.

A possible call flow – note that existing macro 1x does not change

Possible Further Enhancements• Macro BS uses IS-41 Handoff Measurement Request to

target femto AP before deciding to handoff• In a dense deployment, hand-in candidate ambiguity can

be further reduced based on heuristics– Use of Downlink Radio Environment information to further restrict

target femto candidates– How often the MS uses a particular target femto?

• Frequency of use• Most recent use

– Is the MS home femto within the source cell coverage?