| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Yigal,
Please find below my response to your comments/questions:
Comment #1: One of the requirement to support SHO and FBSS is that the context information is either transferred or shared through the backbone, among BSs in the Active Set, such that network re-entry procedures can be omitted. Please refer to the description in page 12 of the contribution, last paragraph of section 6.3.20.2.6.1 and last paragraph of section 6.3.20.2.6.2.
Comment #2: The SHO and FBSS support is optional and the capability can be negotiated. Please refer to page 15 of the contribution, section 11.7.10.2 where a new SBC-REQ/RSP TLV is introduced for this purpose.
Comment #3: The MSS keeps synchronization with the BSs in the Active Set by the following mechanism. First, the BS involving in SHO/FBSS should be time synchronized. This would be the case anyway for TDD operation. Second, one of the requirement to establish Active Set is that the BSs in the Active Set should have relative propagation delay within the cyclic prefix. Third, the MSS perform periodic ranging with Anchor BS which will adjust the timing/frequency/power of the MSS to take into consideration of the reception at each BS in the Active Set.
Regards,
Mo-Han
-----Original Message-----
From: Eliaspur, Yigal [mailto:yigal.eliaspur@INTEL.COM]
Sent: Sunday, July 04, 2004 4:06 AM
To: STDS-802-16-MOBILE@listserv.ieee.org
Subject: Re: [STDS-802-16-MOBILE] [Handoff] Minutes from 6/30 telecon
Hi All,
I have several questions/comments regarding contribution C80216e-04_171 - Soft handover and fast BS switching procedure.
1. The contribution specified CIDs update mechanism in FBSS mode during Anchor BS switching. However, it does not specify a solution for other differentiation parameters switching between the BSs, for example: encryption keys, SAIDs, capability supported etc. In other words, the mechanism for adding/dropping Active-BS /Anchor-BS is not fully defined- should I make network reentry with it or should I assume the context creation is done through the backbone only. In the later case there is the potential problem described above when some others MAC/PHY resources (other then CID) needed to be updated in the MSS.
2. There is no capability negotiation between the MSS and the BS in the proposed contribution for supporting SHO and/or FBSS. Is the intension for any 16e MSS to support both advanced HO techniques as mandatory features? I don't think it's a reasonable requirement - thus I strongly recommend adding such capability.
3. One of the requirements of the MSS is to "keep synchronization with (all) serving BS(s) at all times" - in SHO it means with all the Active Set members. The Contribution does not specify the method to maintain such synchronization - is the intension to use the scanning mechanism with the association phase to keep the MSS ranged to all its Active Set members? Or should it be maintained implicitly by the SHO procedure.
Thanks
- Yigal
Yigal Eliaspur
Broadband Wireless Division
Intel Corp.
yigal.eliaspur@intel.com
Voice: +972-547-884877
-----Original Message-----
From: owner-stds-802-16-mobile@listserv.ieee.org [mailto:owner-stds-802-16-mobile@listserv.ieee.org] On Behalf Of Iyer, Prakash
Sent: Thursday, July 01, 2004 11:13 PM
To: STDS-802-16-MOBILE@listserv.ieee.org
Subject: [STDS-802-16-MOBILE] [Handoff] Minutes from 6/30 telecon
Next telecon - Thursday, 7/8, 6 AM U.S. Pacific time. Bridge info to follow. Contributions to be considered for possible harmonization / consensus by handoff adhoc : Summary - We did not make progress toward consensus on any of the contributions in this category. However, we did have good discussion on most of them and decided to continue over the reflector.
* C80216e-04_167r1 Enhancement of Scanning and Association using SCAN-REQ&RSP Two clarifications / changes were requested: 1) add text to clarify that this is to pre-load contention free ranging on the target BS and 2) a TLV based solution per neighbor. Discussions to continue on the reflector.
* C80216e-04_224 Simplified Scanning Procedure
Previous history - this concept was rejected by carriers as it makes load information transparent to all - including non-subscribers. Everyone seemed to agree that this is a good feature to add to the spec - question is how? Given the desire to not bloat NBR-ADV messages, several options were discussed and we ended up with 4 alternatives:
1) Change proposal to use TLVs so it can be skipped if necessary. Negative is size (3 bytes versus 1 byte in current proposal)
2) Keep current proposa but BS that want to skip advertising this information can set the value of Available radio resource to all 1s. But it does not save bits in the NBR-ADV.
3) Use a management / configuration message (such as a .11k site report) to provide this information as it changes infrequenctly. Could perhaps be handled in .16f/g
4) Would current support in MOB-HO-REQ/RSP not suffice. Answer seems to be no - at you only get this for the target BS and the MSS may have to retry multiple times to find its preferred BS Discussions to continue on the reflector.
* C80216e-04_209 The Improvement of Scanning Method Using Preambles in IEEE 802.16e The motiviation for this was not clear - more clarification was sought. However, the solution could apply to all PHY modes. Also requested clarification on system assumptions; for example, do BS have to be transmit synchronized for this scheme to work?
Min-Sung to respond to these questions on the reflector.
* C80216e-04_140 Modification of HO process SDLs
Did not discuss during the call.
* C80216e-04_142 Comments on Preferred Base Stations for Handoff
- A lot of discussion on whether this was an implementation / policy issue versus a spec issue. A suggestion was made to check if contribution 04_171 is applicable here. The authors believe that signaling may be needed between an MSS and BS. Discussions to continue on the reflector.
* C80216e-04_151 Minimizing IP Connectivity Delay During Network (Re)Entry Ran out of time, did not discuss. Authors to solicit input on the mailing list.
* C80216e-04_156 Safety Channel Handover Procedure
A lot of discussion around whether this was related to handoffs or if it was a frequency relocation procedure that was loosely related to handoffs. There were some concerns on the complexity introduced by defining new threshold values. Generally the idea seems good, some clarity was sought on usage models. Masoud and Phil to send out specific questions to the reflector; Jungje to respond.
* C80216e-04_202 Enhanced CID update in Registration
Much of the discussion revolved around motiviation for this solution and estimates for how many bits this would save. Samsung to send out a response to the reflector.
* C80216e-04_225 Initial Ranging Overhead Reduction
A lot of discussion on this contribution. Questions / concerns raised include: 1) Backward compatibility with .16d (need to look into this based on recommended changes), 2) are we saving symbol space with this change, 3) SS MAC address is mandated in RNG-REQ message. Mo-Han to drive discussion on this contribution on the reflector.
* C80216e-04_171 r1 Soft handover and fast BS switching procedure, C80216e-04_166r1 Fast BS Switching using FPCH Jungwon said that the contributions are still being harmonized. Target is to complete harmonization by the Tuesday deadline. Several concerns with regard to system arch complexity, FBSS overhead, bloating messages even when a system does not support these features came up. Plan is to review the harmonized contribution next week (Thursday). Meanwhile all handoff adhoc participants are requested to read the 2 contributions listed above and send out comments / questions to the reflector ASAP. Review (corrections / tweaks) current HO adhoc consensus contributions: Summary - There were no comments on any of the contributions below. We will wait for reply comments and respond based on that.
* C80216e-04_146 NBR-ADV changes
* C80216e-04_157 A method of scanning neighbor BSs periodically
* C80216e-04_144 HO Optimization Flags
* C80216e-04_154 Resource retaining time and Call recovery scheme during HO
* C80216e-04_148r1 Clarification of Paging Announce Message
We also briefly reviewed the list of contributions listed below and decided that they will not be discussed over telecon prior to the plenary. Backbone Messages (mostly informative):
* C80216e-04_52r1 Secure Transport of backbone messages
* C80216e-04_120r1 FYI - BS Architecture Impact on Handoff Consideration Security related HO contributions (handled by security adhoc):
* C80216e-04_50r1 Minimization of Handoff interruption time skipping Reauthorization procedure
* C80216e-04_200 Pre-Authentication support for PKMv2
* C80216e-04_206r1 Pre Authentication for PKMv2
* C80216e-04_226 Addition of SAID_update in harmony with CID_update PHY Related HO Contributions (we have mostly MAC people on our calls):
* C80216e-04_187 Define and Use of HO Ranging Code
* C80216e-04_115r1 Fast cell search for OFDMA
* C80216e-04_110r1 MIMO SHO based Macro diversity transmission for coverage improvement
* C80216e-04_165 OFDMA PHY Layer Support for SHO Based Macro-Diversity Transmission
* C80216e-04_170r1 OFDMA PHY Layer Support for SHO Based Macro-Diversity Transmission Additional components for soft combining -Prakash