| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
-----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.
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