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

RE: stds-802-16-mobile: Handoff Ad Hoc group

Phillip,
 
As you stated in your document, the MOB_BEA_ADV msg is much too large. I would suggest to make another effort here and maybe fragment the message and transmit it is pieces. One possible cut is to have the "header" portion (BS ID, Operator ID, Network Type etc.) along with some of the slow changing info of the BEA_ADV TLV transmitted once in a while. You may also consider transmitting the neighbor info in pairs and have the entire message come up at the receptor side in a slower rate, but consuming lower bandwidth off the link.
We all are looking forward to review your contribution.
Ofer
-----Original Message-----
From: Phillip Barber [mailto:pbarber@broadbandmobiletech.com]
Sent: 14 October, 2003 7:52 AM
To: Changhoi Koo; stds-802-16-mobile@ieee.org
Subject: Re: stds-802-16-mobile: Handoff Ad Hoc group

I hope to have my contribution ready for submittal to the reflector for peer review by the end of this week.  I look forward to your comments.
 
Thanks,
Phillip Barber
----- Original Message -----
Sent: Tuesday, October 14, 2003 12:38 AM
Subject: Re: stds-802-16-mobile: Handoff Ad Hoc group

Dear Phillip Barber.
 
I would appreciate your effort on AdHoc activities
I think we need a clean-up version including your comments as followings and it would be good reference to peer review your contribution..
Even I have a couple of comments on your contribution, it would not be better at this point according to your mail.
And I'd like to know your schedule when are you going to distribute a clean-up version so that I can have a chance to revise my comments
Thanks
Changhoi Koo
----- Original Message -----
Sent: Tuesday, October 14, 2003 6:29 AM
Subject: stds-802-16-mobile: Handoff Ad Hoc group

Itzik,
 
Just wanted to drop a note and let the Handoff Ad Hoc group know that I am--taking into consideration Vladimir and your comments from Session 27 in Denver--re-working my contribution number 54 into r4 of the current 16e document.  I hope to have my submittal ready for the reflector by the end of this week for peer review.
 
Based on comments at Session 27, I plan two changes to my contribution 54 proposal.  First, For those who wish to use Association as a mechanism to set initial power settings for 6.2.9.5 Ranging instead of using the refined method based on received signal characteristics interpreted during dowlink/uplink synchronization as presented in the current iteration of the 16d document, I plan to continue to include Association, but as an optional, passive activity with application to 6.2.9.5.  I will provide appropriate language.  I had previously espoused removal of Association in its entirety.   Second, I will clean-up my sleep-mode changes to work with contributed changes as of Session 27.  Itzik, could you make a stab at providing my corrected formula and send it to me for inclusion?  I will also clean-up my hand-over flow diagrams to reflect these changes, including your comments regarding other-Target BS notifications.
 
Thanks,
Phillip Barber