See red comment inline with text.
-----Original Message-----
From: owner-stds-802-16-mobile@listserv.ieee.org
[mailto:owner-stds-802-16-mobile@listserv.ieee.org] On Behalf Of Yigal
Sent: Wednesday,
August 11, 2004 8:09 PM
To:
STDS-802-16-MOBILE@listserv.ieee.org
Subject: Re: [STDS-802-16-MOBILE]
[Harmonization] Proposed NBR_ADV Enhancements Summary
Please see my comments
below.
-----Original Message-----
From: owner-stds-802-16-mobile@LISTSERV.IEEE.ORG [mailto:owner-stds-802-16-mobile@LISTSERV.IEEE.ORG]On Behalf Of Etemad, Kamran - Contractor
Sent: Tuesday, August
10, 2004 9:44 PM
To: STDS-802-16-MOBILE@LISTSERV.IEEE.ORG
Subject: [STDS-802-16-MOBILE] [Harmonization] Proposed NBR_ADV Enhancements
Summary
All,
Per my action item from previous call, I have summarized in the following the
feedback we got about our proposed changes to the NBR-ADV message.
Please provide your feedback on the reflector so that we can attempt to reach
conclusion on these points by the end of this week.
1. Addition of three logical levels of preference for each neighbor;
This ideas was in line with other field in the message providing auxiliary
logical information about neighbor's loading and QoS support to help MSS
identify the best candidates for hand off. I think the proposed idea was
considered to be useful for traffic management in certain deployment scenarios
such as overlay/underlay and hierarchical cell structure. however the
suggestion was to remove any references to public, private ... networks and
state it as say level 1, level 2 and level 3 preference, with implications as
defined in the contribution. We agree with these points raised during the call.
2. Making BS_ID's as an optional field or TLV for OFDMA PHY, and using Preamble
prefix as key parameter to differentiate BS's during the neighbor scan.
This was also considered a reasonable message optimization to significantly
reduce the message size in most like case, when all or most BS's are OFDMA
based.
3. Removing DCD and UCD fields from the message
We could not clearly define or at least quantify the benefit of having these
field for neighbors as the mobile typically does not know and need the content
of DCD and UCD of aneighbor untill it starts synching with that BS.
So we may keep these fields as optional or if there is not a strong and
justified objection remove it from the message.
[Yigal] Here is one strong objection: These
fields where added in order for MSS to be able to work right away with neighbor
BS, and skip the stage that require it to acquire DL and UL parameters (which
may take long seconds). These fields must not be removed.
4. We suggested that the PHY Profile ID be designed to effectively support
interfrequency hand over in multi-carrier configuration with reuse factors of 1
or higher.
This issue was discussed in the last call and the new design seem to be on the
right track to meet our goal.
However we are looking into inefficiencies associated with indicating each
carrier of neighbor BS and even other carriers of the serving BS as separate
BS's with different BS_ID.
[Yigal] I fail to see the merit of such a
system, while I see quite a lot a complications. I don't think we should add
weight to the NBR-ADV message unless there is very strong evidence that
somebody is going to deploy multiple BW networks, and that a radio to support
such networks is feasible.
{David
McGinniss}
Sprint intends to deploy multi-carrier systems as we do
now. In dense areas multi carrier cells with load balancing and multi
carrier PA’s are critical too the use of 802.16 technology. Support
for this will be a clear differentiator between systems provided by vendors. Small
footprint multi-carrier systems with 1X3 support are highly desired.
I hope this
summarizes our key points and allows productive exchanges on the reflector.
I suggest comments be provided to these point in their order above, if
possible.
Looking forward your comments and talking to you on the call.
Regards,
Kamran