| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
All: Please see my comments below. From: Anh Tuan Hoang [mailto:mbox.hoang@GMAIL.COM] Hi Eunkyung and all, I am switching to Gmail because the OWA account has HTML formating problem. Please refer to my inline comments. Best regards, Anh Tuan - I2R On Mon, Apr 18, 2011 at 10:37 AM, Eunkyung Kim <ekkim@etri.re.kr> wrote: Hi Eldad and all, Thank you for the comment. Please see my inline comment. Best Regards, Eunkyung Kim Electronics & Telecommunications Research Institute (ETRI) From: Zeira, Eldad [mailto:Eldad.Zeira@INTERDIGITAL.COM]
Hi Eunkyung, All Thanks for initiating the discussion, please see my comments below. Hope this helps, From: Eunkyung Kim [mailto:ekkim@etri.re.kr] Hi Anh Tuan, Alina and multimode fans, Thank you, Alina, for initiating the email discussion and Anh Tuan, for clarification the issues. I agree with Anh Tuan that we need technical element discussion at first. Please see my inline comment and let me know anything is missed or wrong. Best Regards, Eunkyung Kim Electronics & Telecommunications Research Institute (ETRI) -----Original Message----- Dear Alina, Thank you for initiating the discussion. I think we may not want to work directly on the proposed text, as it will be difficult to manage if different people want to modify the same text in different ways. Rather, I propose that we focus on underlying technical elements of the topic. For multi-mode, we may need to collect opinions on: - What are the trigger conditions of mode changes, and who can initiate the changes? [ekkim] condition may be issues of implementation. However, following is reasonable condition, I think. - When backhaul is unavailable temporally or some specific time (which is the condition for HR-BS acting as HR-RS) [DJ: In this case, the HR-BS needs to act as BOTH HR-BS and HR-RS since the HR-BS still serves mobiles.] - When there is no infrastructure station [Eldad: and no forwarding HR-MS] (which is for HR-MS acting as HR-BS) {DJ: I fully support the need to change HR-MS to HR-BS under this circumstance. Not sure if forwarding HR-MS can help in this case since we still have not decided if HR-MS with forwarding functionality requires the supervision of a BS or not.] - When it is needed to relay some data between stations (which is for HR-MS acting as HR-RS)[Eldad: this in itself isn't a sufficiently clear condition as normally the HR-BS can forward the data if those two HR-MS are attached to it. A better definition should be helpful here] [ekkim] I agree that further discussion on HR-MS acting as HR-RS is needed. [Anh Tuan] I think an HR-MS should only change to HR-RS when there is a need to relay control/data messages between an HR-BS and MULTIPLE out of coverage HR-MSs. This is normally a consequence of a SPOF. In case when we only need to relay control/data between HR-BS and one or a few HR-MSs, a lighter "HR-MS forwarding-to-network" function is preferable.
[Anh Tuan] I guess whether it is a "clean switch" or not also depends on what are the defined set of functionalities for 16n HR-BS/RS. If we end up defining a 16n HR-RS that has some functionalities of HR-MS (or HR-BS) then a clean switch may be sufficient.
[Anh Tuan] I believe this depends on specific scenarios. If the "mode-switching" station connects to a super-ordinate station which is either 16e or 16m, then backward compatibility is a must. Otherwise, if the super-ordinate station is 16n, then I am open to consider different topologies that may be useful in 16n. [DJ]: I agree. Whether it is a clean role switching or “adding” roles depends on the scenarios.
[Anh Tuan] The reason I ask about the time-scale of mode switching is that some contributions provide mechanisms to facilitate HR-MSs to re-connect to original HR-BS when mode-change is reverted. One example is to retain context of HR-MS for a certain time. These mechanisms will only be useful if the time-scale of mode switching is relatively short.
[Anh Tuan] Hope it works :-)
|