| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
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 ________________________________ From: Lu Liru, Alina
[mailto:liru@nict.com.sg] Sent: Wed 4/13/2011 4:01 PM To:
STDS-802-16@LISTSERV.IEEE.ORG Subject: [STDS-802-16]
[802.16n][MM][MultiMode] Discussion on Relay Function for HR-BS for OFDMA Air
Interface Dear 16n participants, This email is to initiate the
discussion for Multi-mode operation for the topic Relay Function for HR-BS for
OFDMA Air Interface The following texts in Blue
provides the consolidated texts based on each party's proposal for the above
topic. If you disagree certain point, please highlight the texts. and provide
alternative texts in different color subsequently. If you want to insert texts,
please use INSERT[***]. Please make the modification based on the VERSION I
texts provided below. We shall work on the same version of texts and I will
collect all your inputs and form a VERSION II if any. Thank you for your cooperation! **********************************************************
VERSION I: <<Relay function for
HR-BS>>********************************************************** 17.2.1.a HR-MS Multi-mode
capability registration A HR-MS that is capable of role
change to HR-RS and/or HR-BS shall register this capability to the
super-ordinate HR-BS at network entry, together with the basic capability
negotiation phase. HR-MS should indicate to the super-ordinate HR-BS if it is
unavailable to perform a role-change. 17.2.1.b Relay function for
HR-BS HR-Network shall support HR-BS
communication with another HR-BS in order to support the relaying function to
provide continuous network connectivity. HR-BS shall operate a relay
function to support the relaying of messages when its backhaul communication is
unavailable or when relay support is requested from HR-MS. The HR-BS acting as
RS mode can operate in either TTR mode or STR mode. The procedures for RS mode
change consist of three steps: a) inform subordinate MSs that
backhaul services are unavailable b) establish a relay link with a
neighbor HR-BS c) reconfigure the physical
frame Prior to/during/and after
carrying out mode switching, the HR-BS shall perform appropriate PHY-level
configurations and MAC-level control/signaling to maintain connectivity for its
subordinate stations. The origin cell HR-BS shall use
its relay function to communicate with the HR-BS in the destination cell to
enable the communication between stations covered within two cells. HR-BS shall
maintain its BS functionality such as central scheduling even when it is
operating its relay function. If the HR-BS recovers from the failure of
backhaul, it informs network or notifies neighbour HR-BS through the backhaul
network interface. The HR-BS may transmit MAC
context information (e.g., path information) of the HR-MSs during establishing
relay link to neighbour HR-BS to allow HR-MS to select alternative path. **********************************************************
ENG of VERSION I: <<Relay function for
HR-BS>>********************************************************** Best regards, Alina Liru LU (? ??), Ph.D Research Scientist Wireless Communications
Laboratory National Institute of
Information and Communications Technology Tel: (65) 6771 1006 Fax: (65) 6779 5753 |