Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-16] [802.16n][MM][MultiMode] Discussion on Relay Function for HR-BS for OFDMA Air Interface



Hi all,

 

I’m catching up on the email discussion and noticed the format has somewhat been changed to plain text instead of the agreed HTML.

 

To improve readability (and help myself along the way), I’ve changed the format back to HTML and with the following color codes for inline comments:

 

- [Alina]

- [Anh Tuan]

- [DJ]

- [ekkim]

- [Eldad]

- [WL]

 

My comments are also placed inline as below.

 

Regards,

Wai Leong

 

-----Original Message-----
From: Zeira, Eldad [mailto:Eldad.Zeira@INTERDIGITAL.COM]
Sent: Friday, April 22, 2011 4:54 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

 

Hi All,

 

Please see some further comments embedded in the text.

 

Eldad

Office   +1 631 622 4134

Mobile +1 631 428 4052

Based in NY area

 

 

-----Original Message-----

From: Lu Liru, Alina [mailto:liru@NICT.COM.SG]

Sent: Thursday, April 21, 2011 7:34 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 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.

 

[Eldad] Not sure which HR-BS functions the HR-RS needs to fulfill. An

HR-RS is attached to another HR-BS which can provide BS functionality in

the same way that it does e.g. for ARS. To me once HR-BS becomes an

HR-RS it is an HR-RS (itself an RS or ARS with 16n amendments)

 

- 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

 

[WL] We might want to avoid the inefficient situation where a few HR-MS in the same area changing to HR-BS simultaneously. A HR-BS prior to failure can resolve the “conflict” with an instruction to one HR-MS like: “in case of HR-BS failure and no other infrastructure, change to HR-BS to serve other MS”.

 

- 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.

 

[Eldad] I'll agree with Anh Tuan. Note we have agreed to it in the SRD

where the two appear as distinct features. While both enhance

reliability, HR-BS (or HR-MS) becoming a relay protect from loss of an

HR-BS or backhaul. HR-MS forwarding enhances the coverage reliability

i.e. the reliability that an HR-MS (with tough propagation conditions)

can still communicate.

It is not expected that all features will be implemented for all

applications.

 

[WL] I suggest that “forwarding” should not be used alone. It should either be “HR-MS forwarding” (a DC topic) or “local forwarding”. The latter is to be discussed together with “relaying” in another MM topic, headed by Xin Zhang.

I believe Anh Tuan and Eldad are referring to “HR-MS forwarding” whereas Alina and ekkim may be talking about “local forwarding”.

In reply to when a HR-MS changes mode to HR-RS: I believe it should be instructed by HR-BS for the purpose of extending/resuming coverage. The instruction can be either an immediate change (e.g. change mode now to serve other HR-MS), or a delayed change (e.g. change mode after HR-MS detects some SPOF event).

 

- 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

 

[WL] These steps only apply to a HR-BS. What does “informs implicitly” mean?

 

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.

 

[WL] Please refer to my earlier comment on avoiding a few HR-MS to change to HR-BS simultaneously.

 

- 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.

 

[Eldad] During the SRD discussions we have defined MS-RS or MS-BS role

change in order to provide SPOF (single point of failure) protection

e.g. backhaul loss. For this case the MS-as-BS or RS will need to serve

many other HR-MS in order to maintain connectivity over a large area.

Therefore we have to assume high transmission power, high antenna gain

etc. As a result we can assume that not all HR-MS have the capability to

become HR-BS - but those that do likely have the battery for that. As an

example for PPDR, handheld radios will not be able to become HR-RS or

HR-BS but car mounted HR-MS can. 

Improved BS power consumption has been proposed as a separate project

and NOT approved.

 

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