Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-16-MOBILE] [Handoff] Minutes from 6/30 telecon; C80216e-04/225



Title: Message
I still have reservations about enacting the change to achieve saving a single OFDMA slot on the transaction, but since does not preclude the use of MSS MAC Address, nor interfere with drop recovery, including the new 6.3.20.4 language changes, I will vote to Approve.
 
Thanks,
Phil
 
----- Original Message -----
Sent: Friday, July 02, 2004 11:07 PM
Subject: Re: [STDS-802-16-MOBILE] [Handoff] Minutes from 6/30 telecon

Hi all,
 
Here is a follow-up on the action item on C80216e-04_225:

"* 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."

Regarding issues 1) and 3) on backward compatibility and mandatory use of SS MAC address:

  • We think that the issues can be resolved by restricting the use of HO_ID for non-contention based ranging for HO purpose. Basically, we can modify the proposed text change in C80216e-04_144 (HO Optimization Flags - HO adhoc consensus contribution), Remedy 1, page 4, as follows: " ... Non-contention based MSS Initial Ranging, as part of the MSS re-entry process, shall be considered the same as Invited Initial Ranging as defined in 6.3.9.5, except that the MSS RNG-REQ message will use HO_ID, if HO_ID is assigned in MOB-BSHO-REQ or MOB-BSHO-RSP, or MSS MAC Address if HO_ID is not assigned in MOB-BSHO-REQ or MOB-BSHO-RSP,  instead of Basic CID, which will not have been sent at the time of the RNG-REQ management message ..."
  • As proposed in C80216e-04_225, the BS can choose to assign or not to assign HO_ID in MOB-BSHO-REQ/RSP messages. Similarly, we can modify the Fast_UL_ranging_IE to use either the MAC address or the HO_ID. 

Regarding issue 2) on symbol space saving, the Fast_UL_ranging_IE is part of the UL_MAP message. UL_MAP message size should be kept as small as possible as it occupy a lot of UL resource. The use of HO_ID will save 40 bits out of the original 92 bits, i.e. 43% of saving for each occurence of Fast_UL_ranging_IE. Similarly, the use of HO_ID will save 5 bytes from each of RNG-REQ and RNG-RSP message. Consider a RNG-REQ message of size 22 bytes (HMAC tuple) + 6 bytes (Serving BS ID) + 6 bytes (MAC address) + 1 byte (HO indication) + 6 bytes (MAC header) = 41 bytes. If the most robust burst profile of QPSK+1/2 coding is used, the RNG-REQ will occupy 7 OFDMA slots. If HO_ID is used instead of MAC address, a saving of 5 bytes will reduce the UL resource to 6 OFDMA slots.

If we can agree on the use of HO_ID for non-contention based handover purpose, the similar concept can also be applied to non-contention based association. In that case, the MOB_SCN-RSP message will need to be modified to include the assignment of HO_ID.

Your comment on the above is appreciated.

Regards,

Mo-Han

-----Original Message-----
From: Iyer, Prakash [mailto:prakash.iyer@INTEL.COM]
Sent: Thursday, July 01, 2004 4: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