| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Dear Kamran and all:
Please see my inline comment on PHY Profile ID and Multi-FA systems.
Thanks.
Regards,
Jung-Won Kim ---------------------------------------------------------------- Jung-Won Kim, Ph.D.
Senior Engineer NTP System Lab. 1 Telecommunication Systems Division Samsung Electronics Co., Ltd.
Office: +82-31-279-3356 Mobile: +82-10-9530-3356 Email: jungwon74.kim@samsung.com
-----Original Message-----
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.
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.
Jung-Won’s Comment: As I explained in the previous my email, putting another BS-ID to the co-located FA is unavoidable since all the HO related messages use the BS-ID to distinguish another logical entity. However, the increased overhead is minimal since the following field (preamble index, DCD/UCD change counts and TLV information, if you insist, you can include the preamble index without violating any rules since there is a length field in it.) can be omitted by setting the Co-located Indicator bit 1. If you want to do so, then the actual increased overhead would be limited about 20 to 24 bits (Arithmetically, it should be 32 bits. However, since you have to include the number of FA field and so on, the estimated actual overhead increase would be around 20 bits). Additionally, this way of implementation gives the flexibility. At this point, it is hard to imagine what the real 802.16 system would be. As some have claimed, the system may be composed of only single sector single FA BS. As you and I have claimed, the system may be composed of all kinds of configurations. Right now, the standard has some inclination of oversimplifying the network architecture. Yet, we should provide some flexibility.
I totally agree with you that the NBR-ADV has a lot of rooms to be optimized. However, at this time, we should first focus on if the right information elements are in the NBR-ADV. After this process is finished, I think the optimization can be done without any risk of missing some very important elements.
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 |