| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Dear all, Thank you for the inputs from Anh Tuan, Eunkyung, and Eldad. I have combined our thoughts and summarized the following texts in Dark Blue We may wish to start our 2nd round of discussion based on the texts below. - What are the trigger conditions of mode changes, and who can initiate the changes? Trigger conditions of mode change and the initialization of change: 1. For HR-BS acting as HR-RS, trigger condition: (a) HR-BS lost backhaul connection. Initiated by HR-BS. (b) Requested by HR-MS. Initiated by HR-MS. 2. For HR-MS acting as HR-BS, trigger condition: HR-BS is unavailable. Initiated by candidate HR-MS to be operated as HR-BS. 3. For HR-MS acting as HR-RS, trigger condition: When the traffic to destination node cannot be relayed by HR-BS. Initiated by HR-BS upon requests of origin HR-MS (centralized scheme) or initiated by origin HR-MS when HR-BS is unavailable(distributed scheme) - What is a mode change anyway? Is it a clean switch between two (BS/RS/MS) roles or a station can perform a combined/dual role? 1. For HR-BS acting as HR-RS, even after mode change, HR-BS shall maintain its functionality as HR-BS such as central scheduling etc. 2. For HR-MS acting as HR-BS, after mode change, it will continue to support local source and sink. 3. For HR-MS acting as HR-RS, after mode change, it will continue to support local source and sink. - What are the supported topologies after a mode change, assuming 16e or 16m baselines? The network topologies after mode change will be backward compatible to 16e/16m topologies. - What are the steps taken during/after a mode change? 1. For HR-BS acting as HR-RS, procedure for mode change: Step 1. Informs subordinate stations that mode change starts Step 2. Establishes relay link including configuration Step 3. Informs explicitly or implicitly subordinate stations that mode change is done 2. For HR-MS acting as HR-BS, procedure for mode change: Step 1. Selection of HR-MS as candidate of HR-BS Step 2. Informs subordinate stations that mode change is done by broadcast Step 3. subordinate stations perform network re-entry 3. For HR-MS acting as HR-RS, procedure for mode change: Initiated by HR-BS: Step1. Identify HR-MS to work as HR-RS Step2. Confirmation of HR-MS to work as HR-RS Step3. Informs origin node and destination node that mode change starts Step4. Establishes relay link including configuration Step5. Informs explicitly or implicitly subordinate stations that mode change is done Initiated by HR-MS(in the case when HR-BS is unavailable): Step1. Identify HR-MS to work as HR-RS Step2. Confirmation of HR-MS to work as HR-RS Step3. Informs origin node and destination node that mode change starts Step4. Establishes relay link including configuration Step5. Informs explicitly or implicitly subordinate stations that mode change is done - Should mode change always be regarded as temporary? and if that is the case, what is the time scale, in comparison to that of a MS connection? The role change is temporary. Although when the HR-stations will revert back to its original role may be left to implementers to decide, The following conditions are recommended for defining the Exit from Multi-Mode, 1. For the case HR-BS acting as HR-RS, for trigger condition (a), as HR-BS will maintain its functionality as HR-BS, once HR-BS recover its backhaul connection, the relay function will be switch off; for trigger condition (b), once HR-MS completed its transmission of traffic, the relay function will be switched off. 2. For the case HR-MS acting as HR-BS, HR-MS will revert to its role as HR-MS once there is an alternative HR-BS to take over its role. 3. For the case HR-MS acting as HR-RS, once HR-MS completed its transmission of traffic, the relay function will be switched off. Thank you and best regards, Alina From: Zeira, Eldad [mailto:Eldad.Zeira@INTERDIGITAL.COM] Hi Eunkyung, All Thanks for initiating the discussion, please see my comments below. Hope this helps, Eldad Office +1 631 622 4134 Mobile +1 631 428 4052 Based in NY area 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) - When there is no infrastructure station [Eldad: and no forwarding HR-MS] (which is for HR-MS acting as HR-BS) - 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] - What is a mode change anyway? Is it a clean switch between two (BS/RS/MS) roles or a station can perform a combined/dual role? [ekkim] we need to define the topologies at first. However, HR-MS acting as HR-RS/HR-BS has to maintain MS and RS/BS functionalities at the same time. [Eldad] I’m not sure what is the functionality of HR-MS that has to be maintained while it is an HR-BS or HR-RS. The only one that comes to mind is the ability to provide local source and sink. Is that your intention? It has always been my opinion that local source and sink capability doesn’t require a standards change. We do however already have this requirement for the HR-RS. - What are the supported topologies after a mode change, assuming 16e or 16m baselines? [ekkim] What I think the backward compatibility is the main concern. Thus, even the role changes, the topology should be a line of 16e or 16m. - What are the steps taken during/after a mode change? [ekkim] HR-BS or HR-MS acting as HR-RS is a little clear relatively comparing with HR-MS acting as HR-BS. Following is the expected steps for mode change to relay station. Step1. Informs subordinate stations that mode change starts Step2. Establishes relay link including configuration Step3. Informs explicitly or implicitly subordinate stations that mode change is done In addition, HR-MS acting as HR-BS may start BS operation by itself when any base station is not detected. Any other condition is FFS. - Should mode change always be regarded as temporary? and if that is the case, what is the time scale, in comparison to that of a MS connection? [ekkim] I don’t catch what you mean. [Eldad] My thinking is that role change isn't permanent i.e. an HR-station that has changed its role can revert to its original role. I think the decision and conditions to do so should be left to implementation. We may choose to specify signaling to support it though. That is just my opinion, and I am open to other approaches. Very sorry for the plain text message as I have difficulty in sending HTML mail through Outlook Web Access. I am trying to fix this. [ekkim] Thanks and I am looking forward to fixing it asap. :) Best regards, Anh Tuan |