Re: [STDS-802-16] [802.16n] [MM] Proposed harmonized text for multi-mode

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

On Thu, May 5, 2011 at 12:11 PM, ZHANG Xin <zhangxin@nict.com.sg> wrote:

Dear all,

Please see my inline comments below. Thank you!

Best Regards,

Xin Zhang

From: Zeira, Eldad [mailto:Eldad.Zeira@INTERDIGITAL.COM]
Sent: Thursday, 5 May, 2011 2:27 AM

To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] [802.16n] [MM] Proposed harmonized text for multi-mode

Hi, All

The advantage of living 12 hours behind you is that I get to see all your views before I have to make my own… please see below.

Eldad

Office   +1 631 622 4134

Mobile +1 631 428 4052

Based in NY area

From: Eunkyung Kim [mailto:ekkim@etri.re.kr]
Sent: Wednesday, May 04, 2011 10:36 AM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] [802.16n] [MM] Proposed harmonized text for multi-mode

Hi Alina,

You seem to miss my previous comment.

I have copied my comment right after your comment.

Best Regards,

Eunkyung Kim

Electronics & Telecommunications Research Institute (ETRI)

From: Lu Liru, Alina [mailto:liru@NICT.COM.SG]
Sent: Wednesday, May 04, 2011 6:52 PM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] [802.16n] [MM] Proposed harmonized text for multi-mode

Dear Anh Tuan and all,

Thank you for your inputs. Please see the texts I revised inline.

Thanks and regards,

Alina

From: Anh Tuan Hoang [mailto:mbox.hoang@GMAIL.COM]
Sent: Wednesday, 4 May, 2011 1:26 PM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] [802.16n] [MM] Proposed harmonized text for multi-mode

Hi Eldad and all,

Thanks for the useful comments on the proposed text for multimode. Based on yesterday CC, I have edited the text as shown inline. If you would like to modify, please do so with version number, e.g., P1v2- for version 2 of paragraph 1, together with some justifications. Hopefully we can output some harmonized text for MM RG.

Best regards,

Anh Tuan

On Tue, May 3, 2011 at 9:46 PM, Zeira, Eldad <Eldad.Zeira@interdigital.com> wrote:

Thanks Anh Tuan,

Please see comments below – hope this helps

Eldad

Office   +1 631 622 4134

Mobile +1 631 428 4052

Based in NY area

From: Anh Tuan Hoang [mailto:mbox.hoang@GMAIL.COM]
Sent: Tuesday, May 03, 2011 7:39 AM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] [802.16n] [MM] Agenda for 16n MM RG 2nd Conference Call - Proposed harmonized text for multi-mode

Hi all,

Based on email discussions for multi-mode topic, I would like to propose that the following text to be considered for harmonization. Alina and others, please comment.

Proposed text:

++++++++++++++++++

Paragraph 1:

P1v1: [Upon loosing backhaul connection, an HR-BS (affected HR-BS) shall be able to operate as a relay station to communicate with another HR-BS (supporting HR-BS) that has connection to backhaul. To the supporting HR-BS, the affected HR-BS is treated as a normal HR-RS. To the subordinate stations of the affected HR-BS, the affected HR-BS may continue to act as an HR-BS or completely operate as a normal HR-RS.]

[Eldad] could you clarify – what is the difference between how an ARS and an ABS look to their MS?

[Anh Tuan] If I understand correctly from our 2nd CC discussion, I2R/ETRI/NICT seem to be ok with the last sentence while InterDigital has some concern. The suggestion was to remove the last sentence, with the understanding that we can get back to it with further technical discussions. However, to maintain the history of our email discussion, I would like to propose a modified text as:

P1v2:  [Upon losing backhaul connection, an HR-BS (affected HR-BS) shall be able to operate as a relay station to communicate with another HR-BS (supporting HR-BS) that has connection to backhaul. To the supporting HR-BS, the affected HR-BS is treated as a normal HR-RS. To the subordinate stations of the affected HR-BS, whether the affected HR-BS can continue to act as an HR-BS or it should completely operate as a normal HR-RS is [FFD].]

[Alina] The SRD defines that "HR-Network shall support HR-BS communication with another HR-BS in order to support the relaying function to provide continuous network connectivity." The HR-BS could be the base station similar to the multihop relay base station (MR-BS) as defined in 16j. Both access zone and relay zone are defined so that the relay function is definitely supported and the base station functionality is also maintained. If HR-BS after mode switch only operates as a normal HR-RS. The subordinate stations will hence lose its superordinate station. In that case, a big number of subordinate stations will need perform network searching, reentry or handover etc process. Even handover to the neighbouring base station, it would also be a burden for that BS.

P1v3:  [Upon losing backhaul connection, a HR-BS (affected HR-BS) shall start operate its relay function to communicate with a neighbouring HR-BS (supporting HR-BS) that has connection to backhaul. The affected HR-BS shall maintain its BS functionality to provide connectivity, management and control of subordinate stations such as Relay stations and Mobile Stations.]

[ekkim] I would like to keep the requirement (no supporting interface between RSs) of 16m. Thus, when any HR-RS is attached HR-BS trying to switch as HR-RS, HR-BS acting as HR-RS should have relay link with neighbor superordinate HR-BS but it should be considered as HR-BS still for the subordinate HR-RS/HR-MS.

Therefore, I would like to suggest the last sentence as “To the subordinate stations of the affected HR-BS, the affected HR-BS can continue to act as an HR-BS or it should completely operate as a normal HR-RS.” without any FFD.

In addition, although the condition is informative and helpful to read the spec, it seems not proper way to describe the AWD text. Thus, the following text I would like to propose.

P1v3: [with markup] ~~Upon losing backhaul connection,~~ an HR-BS (affected HR-BS) ~~shall be able to~~ may operate as a relay station to communicate with another HR-BS (supporting HR-BS) that has connection to backhaul. To the supporting HR-BS, the affected HR-BS is treated as a normal HR-RS. To the subordinate stations of the affected HR-BS, ~~whether~~ the affected HR-BS is regarded as either ~~can continue to act as~~ an HR-BS or ~~it should completely operate as a normal~~ an HR-RS.

[without markup] An HR-BS (affected HR-BS) may operate as a relay station to communicate with another HR-BS (supporting HR-BS) that has connection to backhaul. To the supporting HR-BS, the affected HR-BS is treated as a normal HR-RS. To the subordinate stations of the affected HR-BS, the affected HR-BS is regarded as either an HR-BS or an HR-RS.

[Eldad]

While I understand the desire for the HR-MS to keep operating without need for handover, I don’t believe that the extra work in specifying, implementing and testing a new interface is necessary.

Handovers happen all the time for any number of reasons, including mobility, load management and network maintenance. Loss of a backhaul shouldn’t happen too often.

The handover load itself could be minimized if the HR-BS – prior to becoming an HR-RS – sends a handover command to the HR-RS (basically handover to self). Preambles and other HR-RS parameters could be pre-assigned by the network on a contingency basis.

Of course if there’s an easy way of preventing the need for the handover we can accept it, but so far we don’t know if it can be easy or not.

I would like to propose the following text (using v3 as basis):

P1v4: An HR-BS (affected HR-BS) may operate as a relay station to communicate with another HR-BS (~~supporting~~ serving HR-BS) that has connection to backhaul. To the ~~supporting~~ serving HR-BS, the affected HR-BS is treated as a normal HR-RS. To the subordinate stations of the affected HR-BS, the affected HR-BS is regarded as an HR-RS ~~either~~ [ or as an HR-BS]. ~~or an HR-RS~~.

[Xin]

I think the term “affected” is not defined clearly here either. In the SRD, the relay function for BS is supported so as to ensure a continuous network. There are two cases where the relay function of a BS could be turned on based on that description:

1) A normal BS that enables its relay function

2) An affected BS (upon losing backhaul connection) that enables its relay function.

In the second case, the affected BS= reduced-power BS+RS. Since the function of BS> function of RS+backhaul, if we only define the affected BS as the BS that lost backhaul connection, it would not be fair that the BS is viewed as HR-RS. The relay function in this case can be seen as a way to compensate the lost of backhaul connection.

Hence, in summary of my above comments, I would like to suggest the following text for paragraph 1:

P1v5: (with markup) An affected HR-BS (upon losing backhaul connection) may operate as a relay station to communicate with another HR-BS (~~supporting~~ serving HR-BS) that has connection to backhaul. To the ~~supporting~~ serving HR-BS, the affected HR-BS is treated as a normal HR-RS. To the subordinate stations of the affected HR-BS, the affected HR-BS is still regarded as an HR-BS ~~either~~ ~~[ or as an HR-BS].~~ ~~or an HR-RS~~.

P1v5: (without markup) An affected HR-BS (upon losing backhaul connection) may operate as a relay station to communicate with another HR-BS (serving HR-BS) that has connection to backhaul. To serving HR-BS, the affected HR-BS is treated as a normal HR-RS. To the subordinate stations of the affected HR-BS, the affected HR-BS is still regarded as an HR-BS.

[Anh Tuan] I believe Eunkyung text can accomodate both extremes of "pure HR-BS" and "pure HR-RS". However, instead of using "is regarded as...", I propose to use "can be regarded as..." to allow different possiblities. With that, I propse:

P1v6: An HR-BS (affected HR-BS) may operate as a relay station to communicate with another HR-BS (~~supporting~~ serving HR-BS) that has connection to backhaul. To the ~~supporting~~ serving HR-BS, the affected HR-BS is treated as a normal HR-RS.To the supporting HR-BS, the affected HR-BS is treated as a normal HR-RS. To the subordinate stations of the affected HR-BS, the affected HR-BS can be regarded as either an HR-BS or an HR-RS.

+++++++++++++++++

Paragraph 2:

P2v1: [In the absence of any infrastructure station, an HR-MS may be able to operate as a base station to provide connectivity for itself and other HR-MSs. While doing so, the HR-MS shall maintain the MS and base station functionalities. The mode switch to HR-BS can be initiated by the HR-MS itself or this can be directed by the superordinate station of the HR-MS in response to SPOF (e.g., failure of the superordinate station).]

[Eldad] I think we need to define the meaning of “MS functionality”. Part of MS functionality is to be controlled by an ABS. I don’t think we want to retain this part. I think the only part of MS functionality is for local source and sink of data. However we already have a requirement for HR-BS to do that.

In addition, if a super-ordinate node exists and can communicate with the HR-MS why does it need to become an HR-BS?

I would like to suggest therefore:

P2v2: [In the absence of any infrastructure station, an HR-MS may be able to operate as an HR-BS ~~base station~~ to provide connectivity for itself and other HR-MSs. While ~~doing so, the HR-MS shall maintain the MS and base station functionalities~~. The mode switch to HR-BS can be initiated by the HR-MS itself and can be based on network information previously received from the network. ~~or this can be directed by the superordinate station of the HR-MS in response to SPOF (e.g., failure of the superordinate station).]~~

[Anh Tuan] I believe that we agreed in 2nd CC that some MS functionalities need to be retained,e.g., cell searching. I have also explained the reason for the mode switch of HR-MS to be directed by superordinate station (HR-BS/RS) at the point of SPOF. So I proposed the following version:

P2v3: [In the absence of any infrastructure station, an HR-MS may be able to operate as an HR-BS to provide connectivity for itself and other HR-MSs. While doing so, the HR-MS shall maintain certain HR-MS functionalities such as those needed to search for newly available infrastructure stations. The mode switch to HR-BS can be initiated by the HR-MS itself (with or without information previously received from the network) or this can be directed by the superordinate station of the HR-MS in response to SPOF (e.g., failure of the superordinate station).]

[Alina] I think the support for HR-MS to be able operate as a HR-BS is a must. Hence I propose to use 'shall'. Does superordinate station mean 'HR-BS' here?

P2v4: [In the absence of any infrastructure station, an HR-MS shall be able to operate as an HR-BS to provide connectivity for itself and other HR-MSs. While doing so, the HR-MS shall maintain certain HR-MS functionalities such as those needed to search for newly available infrastructure stations. The mode switch to HR-BS can be initiated by the HR-MS itself (with or without information previously received from the network) or this can be directed by the HR-BS in response to SPOF (e.g., failure of the HR-BS).]

[Anh Tuan] The reason we should not use shall is not all HR-MSs will have the capability and will be in suitable conditions (location/power...) to operate as HR-BS.

[ekkim] Why I would like to remove the condition is the same as I mentioned in paragraph 1. I think “may” is better word than “can” in AWD. Question is ”Does superordinate station include HR-BS and HR-RS?” I am not sure whether HR-RS directs the HR-MS to switch as HR-BS. Thus, the following text I would like to propose.

P2v4[with markup]: ~~In the absence of any infrastructure station~~, an HR-MS may ~~be able to~~ operate as an HR-BS to provide connectivity for itself and other HR-MSs. While doing so, the HR-MS ~~shall~~ may maintain certain HR-MS functionalities such as those needed to search for newly available infrastructure stations. The mode switch to HR-BS ~~can~~ may be initiated by the HR-MS itself ~~(with or without information previously received from the network)~~ or ~~this can~~ may be directed by the superordinate ~~station~~ HR-BS of the HR-MS ~~in response to SPOF (e.g., failure of the superordinate station)~~.

[without markup]: An HR-MS may operate as an HR-BS to provide connectivity for itself and other HR-MSs. While doing so, the HR-MS may maintain certain HR-MS functionalities such as those needed to search for newly available infrastructure stations. The mode switch to HR-BS may be initiated by the HR-MS itself or may be directed by the superordinate HR-BS of the HR-MS

[Eldad] agreed with slight editorial changes:

P2v5

An HR-MS may operate as an HR-BS to provide connectivity for itself and other HR-MSs. While ~~doing so~~ operating as an HR-BS, the station, ~~the HR-MS~~ may maintain certain HR-MS functionalities such as those needed to search for newly available infrastructure stations. The mode switch to HR-BS may be initiated by the HR-MS itself or may be directed by the superordinate HR-BS of the HR-MS

[Anh Tuan] I'm ok with the above.

+++++++++++++++++

Paragraph 3:

P3v1: [In response to SPOF (e.g., HR-BS/RS failure or loss of backhaul) or to support coverage extension, an HR-MS may be able to operate as a relay station to provide connectivity for multiple affected/out-of-coverage HR-MSs. While doing so, the HR-MS shall maintain the MS and relay functionalities. A mode switch to HR-RS shall be initiated by the superordinate station of the HR-MS.]

[Eldad] like the HR-BS, an HR-RS is already required to provide local source – sink. Therefore I would like to suggest the text

P3v2: [In response to SPOF (e.g., HR-BS/RS failure or loss of backhaul) or to support coverage extension, an HR-MS may be able to operate as a relay station to provide connectivity for multiple affected/out-of-coverage HR-MSs. ~~While doing so, the HR-MS shall maintain the MS and relay functionalities~~. A mode switch to HR-RS shall be initiated by the superordinate station of the HR-MS.]

[Anh Tuan] I would like to propose:

P3v3: [In response to SPOF (e.g., HR-BS/RS failure or loss of backhaul) or to support coverage extension, an HR-MS may be able to operate as an HR-RS to provide connectivity for multiple affected/out-of-coverage HR-MSs. While doing so, the HR-MS shall maintain certain HR-MS functionalities such as those needed to support HR-MS mobility. A mode switch to HR-RS shall be initiated by the superordinate station of the HR-MS].

[Alina] Similar to paragraph 2, it should be a must for HR-MS to support relay function and suggest to change 'may' to 'shall'. Can the definition for superordinate station be given clearly?

P3v4: [In response to SPOF (e.g., HR-BS/RS failure or loss of backhaul) or to support coverage extension, an HR-MS shall be able to operate as an HR-RS to provide connectivity for multiple affected/out-of-coverage HR-MSs. While doing so, the HR-MS shall maintain certain HR-MS functionalities such as those needed to support HR-MS mobility. A mode switch to HR-RS shall be initiated by the superordinate station of the HR-MS].

[ekkim] similar previous comment.

P3v4 [with markup]

~~In response to SPOF (e.g., HR-BS/RS failure or loss of backhaul) or to support coverage extension,~~ an HR-MS may ~~be able to~~ operate as an HR-RS to provide connectivity for multiple affected/out-of-coverage HR-MSs. While doing so, the HR-MS ~~shall~~ may maintain certain HR-MS functionalities such as those needed to support HR-MS mobility. A mode switch to HR-RS shall be initiated by the superordinate ~~station~~ HR-BS of the HR-MS

[without markup] An HR-MS may operate as an HR-RS to provide connectivity for multiple affected/out-of-coverage HR-MSs. While doing so, the HR-MS may maintain certain HR-MS functionalities such as those needed to support HR-MS mobility. A mode switch to HR-RS shall be initiated by the superordinate HR-BS of the HR-MS.

[Eldad] generally agree except that we need to support mobility, period, not “HR-MS mobility”. I have removed “affected” as we haven’t defined affected by what. See suggested text with a few more editorial changes.

P3v5

An HR-MS may operate as an HR-RS to provide connectivity for multiple ~~affected/~~out-of-coverage HR-MSs. While doing so, the ~~HR-MS~~ may maintain certain HR-MS functionalities such as those needed to support ~~HR-MS~~ mobility. A mode switch to HR-RS shall be initiated by ~~the~~ its superordinate HR-BS ~~of the HR-MS~~

[Anh Tuan] I'm ok with the above, with the word "station" added.

P3v6: An HR-MS may operate as an HR-RS to provide connectivity for multiple ~~affected/~~out-of-coverage HR-MSs. While doing so, the ~~HR-MS~~ station may maintain certain HR-MS functionalities such as those needed to support ~~HR-MS~~ mobility. A mode switch to HR-RS shall be initiated by ~~the~~ its superordinate HR-BS ~~of the HR-MS~~

Best regards,

Anh Tuan

On Mon, May 2, 2011 at 5:36 PM, Hoang Anh Tuan <athoang@i2r.a-star.edu.sg> wrote:

Hi all,

Please be reminded of the coming 2nd Conference Call for MM RG. The details are:
- Time: May 3 2011, 9AM Eastern US, 6AM Pacific, 10PM Japan/Korea
- Duration: 1.5 hours
- Dial in: +1-866-457-0015; pin 8109
- LiveMeeting:
https://www.livemeeting.com/cc/epripremier/join?id=WMMKF7&role=attend&pw=8f%29K-mM%5Dr
<https://www.livemeeting.com/cc/epripremier/join?id=WMMKF7&role=attend&pw=8f%29K-mM%5Dr> Meeting ID: WMMKF7
Attendee Entry Code: 8f)K-mM]r

We would like to propose the following tentative agenda:
1. Taking attendance
2. Approving agenda
3. Reviewing email discussions on the 4 topics of: Multi-mode, Relay/forwarding, Path Management, Multicast by corresponding leaders (Alina Liru Lu, Zhang Xin, Hoang Vinh Dien, Eunkyung Kim). Each topic will be allocated 20 minutes with the aim of reaching some harmonized text or common understanding
4. Any other business
5. Closing

To facilitate the discussion, we would like to ask the leaders of email discussion topics to prepare consolidated text in advance.

Please comment.

Best regards,
Anh Tuan and Eunkyung
802.16n MM RG Co-chairs