Re: [STDS-802-16] [802.16n][MM][MultiMode] Discussion on Relay Function for HR-BS for OFDMA Air Interface
Dear all,
My comments are highlighted in light blue color and inserted
in lines.
Thanks and regards,
Alina
From: Eunkyung Kim [mailto: <mailto:ekkim@etri.re.kr> ekkim@etri.re.kr]
Sent: Thursday, April 14, 2011 9:07 AM
To: <mailto:STDS-802-16@LISTSERV.IEEE.ORG> STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] [802.16n][MM][MultiMode] Discussion on Relay
Function for HR-BS for OFDMA Air Interface
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-----
From: Hoang Anh Tuan [mailto:athoang@I2R.A-STAR.EDU.SG]
Sent: Thursday, April 14, 2011 12:42 AM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] [802.16n][MM][MultiMode] Discussion on Relay
Function for HR-BS for OFDMA Air Interface
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.] [Alina] agree
[ekkim] superordinate HR-BS may consider HR-BS (acting as HR-RS) as a relay
station. However, subordinate HR-MS may consider HR-BS (acting as HR-RS) as
either HR-BS or HR-RS, which is up to mode of HR-BS acting as HR-RS. [Alina]
I think this statement also supports HR-BS(with Relay mode on) shall
concurrently have functionality of HR-BS and HR-RS.
- 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.]
[ekkim] I would like to defer it until the forwarding HR-MS functionality
is defined in detail. Anyway, we need to describe the mode change (HR-MS to
HR-BS) in the case of no infrastructure station (i.e., a standalone
network). [Alina] I agree with DJ and ekkim
- 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. [Alina] Sorry, I
generally agree to make the mode change in the case of relay control/data
but lighter "HR-MS forwarding-to-network is unclear to me, why it is
needed?
[ekkim] as an immunity of SPOF, HR-MS can act as an HR-RS. However, I am
not sure what the difference between relay and forwarding. Please explain
what the meaning and difference are in detail.
[Anh Tuan] Put it simple, "relaying" is performed by an HR-RS while
"forwarding" is performed by an HR-MS. There may be multiple
functionalities/configurations of HR-RS that a forwarding HR-MS does not
have to follow, for example: transmitting of preambles/MAP/SFH, handling of
network entry, distributed scheduling, separation of access/relay zones,
supporting of multiple sub-ordinate HR-MSs... When an HR-MS does forwarding,
essentially, it still functions (and is treated by the super-ordinate
station) as an HR-MS. I believe this differentiation is essential to keep
complexity/cost of HR-MS low.
[Alina] Sorry, I cannot agree with here that relaying" is performed by an
HR-RS while "forwarding" is performed by an HR-MS, if in this case, relay
mode will become 'forwarding mode'. The definitions of relay and forwarding
are still ambiguous.
- 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.
[ekkim] I agree. Source/sink functionality may be included for HR-MS acting
as HR-RS or HR-BS.
[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. [Alina] Agree Anh Tuan
- 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.
[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.
[ekkim] What is the meaning of different topologies? [Alina] My
understanding here is the supported network reference model. such as
HR-BS<>HR-RS<>HR-MS
[Anh Tuan] Well, one possibility is multi-hop relay. We discussed this quite
a lot during the SRD formation.
- 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.
[Alina] Here only defines one scenarios, for different situation maybe
different such as HR-MS acting as HR-BS would have different steps.
- 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.
[ekkim] I agree. Whether permanent or temporal role change is up to
implementation
[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. [Alina] I agree with
Eldad that it is definitely not permanent. However, how long the stations
stay at change mode, it depends on actual applications. We will let
implementer to make their choice on the time duration. But we still need
consider and provide the solution as the options are necessary.
[DJ]: For HR-MS to become HR-BS, should not we consider the battery
power consumption issue? It is unrealistic to assume that when HR-MS become
HR-BS, the HR-MS always can find power sources to sustain its operation,
especially in a disaster event.
[ekkim] battery power consumption issue may not be main issue of 16n.
However, we can consider it.
[Anh Tuan] I agree, somehow we need to factor the battery issue into the
design of HR-MS switching to HR-BS (and HR-RS also).
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. :)
[Anh Tuan] Hope it works :-)
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