Download
1 / 4
40 likes | 123 Views
Active call hand-in. X30-20090330-00x__QC_ActiveCall_Handin. The case for Active call Hand-in. Offloading macro system is a win-win for all users; especially in spectrum constrained regions femto cells providing services in poor coverage will witness Hand-in reducing call drops
E N D
Active call hand-in X30-20090330-00x__QC_ActiveCall_Handin
The case for Active call Hand-in • Offloading macro system is a win-win for all users; especially in spectrum constrained regions • femto cells providing services in poor coverage will witness Hand-in reducing call drops • Handout from femtocell to macro will be frequent enough to justify Hand-in • Common usage scenario: User walks into his backyard or steps out to take out the trash; He hands out due to either a weaker femto or stronger macro. When the user walks back into his home, he will be on macro for the duration of the call until the call is terminated or dropped • Not having Hand-in will cause voice quality degradations due to femto interference • More prominent when femto and macro share the same frequency. Call might also drop • When femtocells have dedicated frequency, the femto beacons on macro frequency will cause interference and may lead to a dropped call depending on duration and strength of the femto beacon
Active Hand-in Proposed Solution • Hand-in Solution can support Legacy Handsets with no Software or Hardware upgrades/modification to legacy network • Populate Macro Neighbor List Message with femto PNs (similar to macro PNs) • Configure macro BSC to map femto PN to a dummy cell ID that includes the index of PN • Note this is just a configuration. You will do it for each of the PNs allocated to femto cells only. • This is shown in step 3 and 4 in the next slide • Also note that the actual cell ID of the femtocell is different from the above dummy cell ID. • The MSC_ID associated with the MFIF serving the femtocells in that geographical region would be configured in the macro BS to be associated with the femto PN offsets • MFIF and femto cell will handle the rest • MFIF recognizes that the dummy cellID maps to a unique PN offset • The MFIF can narrow down the list of candidate femtocells under that serving macrocell with that PN offset further using additional intelligence • For example, the call was anchored at the MFIF since the user originated the call at the femtocell and is ping ponging between femtocell and macrocell • The user is allowed to camp on one or a very few femtocell under the coverage of that macrocell
5. Measurement Request to Femto AP1(contains AT RL_LCM) 4. IS-41: <CELL_ID= Index of PN ‘b’> 3. A1-Handoff Required<MSC_ID = MFIF, CELL_ID = index of PN ‘b’> *6. Femto AP2 monitors AT RL and reports detection and RSSI to MFIF 5. Measurement Request toFemto AP2 (contains AT RL_LCM) 6. Femto AP1 unable to acquire AT RL 0. Femto Pilots as part of regular Neighbor List Message 2. MS sendsregular PSMM • MS observes Femto Pilot Proposed Solution MSC + Support Legacy Handsets + No change to Air Interface + No impact to macro BSC + No change to A interface • MFIF may need to send Measurement Request to multiple Femto AP with that PN Offset (ambiguity due to femto PN reuse) MFIF Macro BSC Femto AP2 Cell_ID =2, PN = b Femto AP1 Cell ID = 1, PN = b *Note: In step 6, Femto reports RL signal strength of the detected MS. This uniquely identifies the Femto to MFIF in scenarios where multiple Femtos with same PN can hear the MS. For example, MS is at cell edge. The rest of the procedures following step 6 are similar to existing procedures for InterMSC Handoff (See steps 12 onwards in the call flows in next slide
