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

Re: [STDS-802-16] [802.16n][DC] Discussion on definition of HR-MS DC and Forwarding to Network



Hi, Anh-Tuan, Ming-Tuo and all,

Please see my comments inline. 

Regards.

Haiguang


-----Original Message-----
From: Anh Tuan Hoang [mailto:mbox.hoang@gmail.com]
Sent: Sun 4/24/2011 9:48 AM
To: STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16] [802.16n][DC] Discussion on definition of HR-MS DC and Forwarding to Network
 
Hi all,

I just want to modify part of my previous email.

Best regards,
Anh Tuan

2011/4/24 Anh Tuan Hoang <mbox.hoang@gmail.com>

>  Dear Ming-Tuo and all,
>
> Thank you for the discussions. I am not responding inline, as I only have
> the following general comments:
>
> 1. When we attempt to define some capabilities like HR-MS DC or FTN, the
> only source we should refer to is the SRD. To me, the SRD basically says:
>
> - HR-MS DC means two HR-MSs can talk to each other *without going through* an
> infrastructure station.
>
> - HR-MS FTN means one HR-MS can forward data/control messages between
> another HR-MS and an infrastructure station.
>
> 2. When we are trying to give a "deeper/clearer definition", like, how
> similar FTN is to relay, and how many hop/how many forwarded HR-MSs can be
> supported, we have actually delved into the "technical solutions". And this
> leads to the confusion because different parties may, subconsciously :-),
> give their "deeper definition" that just aligns with their "proposed
> solution". I guess this is also what Eldad tried to to suggest when saying
> "...*The amount of similarity will be determined by technical
> contributions."*
> So I suggest, for definitions, we should aim at somethings very close to
> (or just use) the SRD. We then can have a discussion topic on, say, "Pros
> and cons of implementing DC/FTN based on xyz approaches...". This is where
> the more details can be analyzed.
>
> Best regards,
> Anh Tuan
>
>
> 2011/4/23 Ming-Tuo ZHOU <mingtuo@nict.com.sg>
>
>>  Dear Hai-Guang, Eledad, Sungcheol, and all,
>>
>>
>>
>> Thank you very much for discussion. I have several questions: question 4
>> and 5.
>>
>>
>>
>> Hai-Guang, I am not clear about multi-hop in forwarding to network and
>> numbers of HR-MS supported in Forwarding to network, could you please see my
>> comments/question and make me more clear. Thank you a lot.
>>
>>
>>
>>
>>
>> Best regards,
>>
>> Mingtuo
>>
>>
>>
>> *From:* Zeira, Eldad [mailto:Eldad.Zeira@INTERDIGITAL.COM]
>> *Sent:* 2011?4?23? 4:28
>>
>> *To:* STDS-802-16@LISTSERV.IEEE.ORG
>> *Subject:* Re: [STDS-802-16] [802.16n][DC] Discussion on definition of
>> HR-MS DC and Forwarding to Network
>>
>>
>>
>> Hi Sungcheol, please see my opinion on your comment to question 3 below.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Eldad
>>
>> Office   +1 631 622 4134
>>
>> Mobile +1 631 428 4052
>>
>> Based in NY area
>>
>>
>>
>> *From:* Chang, Sungcheol [mailto:scchang@etri.re.kr]
>> *Sent:* Friday, April 22, 2011 4:41 AM
>> *To:* STDS-802-16@LISTSERV.IEEE.ORG
>> *Subject:* Re: [STDS-802-16] [802.16n][DC] Discussion on definition of
>> HR-MS DC and Forwarding to Network
>>
>>
>>
>> Hi all,
>>
>>
>>
>> Please see my comments to question 3.
>>
>>
>>
>> Best regards,
>>
>> Sungcheol Chang, Ph.D.
>>
>> Mobile Access Technology Research Team, ETRI
>>
>>
>>
>> *From:* Zeira, Eldad [mailto:Eldad.Zeira@INTERDIGITAL.COM]
>> *Sent:* Friday, April 22, 2011 2:43 AM
>> *To:* STDS-802-16@LISTSERV.IEEE.ORG
>> *Subject:* Re: [STDS-802-16] [802.16n][DC] Discussion on definition of
>> HR-MS DC and Forwarding to Network
>>
>>
>>
>> Hi Mingtuo, Haiguang
>>
>>
>>
>> Thanks for this discussion. I mostly agree with Haiguang's opinion but
>> have one question for clarification and several suggestions.
>>
>>
>>
>> Eldad
>>
>> Office   +1 631 622 4134
>>
>> Mobile +1 631 428 4052
>>
>> Based in NY area
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: Wang Haiguang [mailto:hwang@I2R.A-STAR.EDU.SG]
>> Sent: Thursday, April 21, 2011 8:56 AM
>> To: STDS-802-16@LISTSERV.IEEE.ORG
>> Subject: Re: [STDS-802-16] [802.16n][DC] Discussion on definition of HR-MS
>> DC and Forwarding to Network
>>
>>
>>
>> Dear Ming-Tuo and all,
>>
>>
>>
>> Thanks very much to Ming-Tuo bring this topic to the group.
>>
>> It is very important to have a common understanding these
>>
>> issues.
>>
>>
>>
>> I try to reply the questions based on my understanding.
>>
>>
>>
>> Please see my answer inline.
>>
>>
>>
>> Regards.
>>
>>
>>
>> Haiguang
>>
>>
>>
>>
>>
>>
>>
>> -----Original Message-----
>>
>> From: Ming-Tuo ZHOU [mailto:mingtuo@nict.com.sg]
>>
>> Sent: Thu 4/21/2011 6:20 PM
>>
>> To: STDS-802-16@LISTSERV.IEEE.ORG
>>
>> Subject: [STDS-802-16] [802.16n][DC] Discussion on definition of HR-MS DC
>> and Forwarding to Network
>>
>>
>>
>> Dear 16n participants,
>>
>>
>>
>>
>>
>>
>>
>> I'd like to trigger discussion of definition of HR-MS direct communication
>> and HR-MS forwarding to network, since from many discussions it seems there
>> are some confusion regarding them. In my opinion, it is necessary to have a
>> clear common understanding of these two functions for development of
>> technical details in a more smooth way. Anyone is welcome to bring his/her
>> understanding of these two functions by replying this email. I hope after
>> several rounds of email discussion, we can achieve some consensus regarding
>> these two functions.
>>
>>
>>
>>
>>
>> The discussion may be started by answering follow questions:
>>
>>
>>
>> 1. what is HR-MS direct communication (DC)?
>>
>>
>>
>> Haiguang: HR-MS direct communication means, the two HR-MSs involved in the
>> communication are the producer and consumer of the data packets. That is,
>> the source HR-MS pass the data packet down from upper layer to MAC and the
>> destination HR-MS pass the packet to upper layer from MAC after receiving
>> from the air.
>>
>>
>>
>> Clarification: the producer and consumer here are from the view of MAC. It
>> does not mean the packet is originated from the source HR-MS and terminated
>> at the destination HR-MS.
>>
>>
>>
>> Eldad: suggest the following text (editorial cleanup, I think it means the
>> same)
>>
>>
>>
>>
>>
>> The two HR-MS that are in direct communications with each other are the
>> source and the sink of data. Packets are passed from upper layers to MAC at
>> the source and back to upper layers at the sink HR-MS.
>>
>>
>>
>>
>>
>> 2. what is HR-MS forwarding to network (FTN)?
>>
>>
>>
>> Haiguang: HR-MS forwarding means the forwarding HR-MS either forwards the
>> data packet to HR-BS or to the HR-MSs that access the network via the
>> forwarding HR-MS.
>>
>>
>>
>> The forwarded packet will not be passed to upper layer. Instead, it is
>> forwarded to next hop at MAC layer.
>>
>>
>>
>> Eldad: again I agree with the principle and suggest the following
>> wording:
>>
>>
>>
>> An HR-MS that forwards data to infrastructure node or to another
>> forwarding HR-MS that is attached to an infrastructure node (if multi-hop is
>> supported) does so without passing any data to or from higher layers.
>>
>>
>>
>> Ming-Tuo: Haiguang (and all), do you think multi-hop HR-MS forwarding is
>> allowed supported in 16n?

Haiguang: I am not sure how complex it will be. 

>>
>>
>>
>>
>> 3. what's difference between HR-MS DC, HR-MS FTN, and HR relay/local
>> forwarding?
>>
>>
>>
>> Haiguang: The differences are:
>>
>> * For HR-MS DC, at the source HR-MS, the data packets are from upper layer
>> and are passed to upper layer protocol at the destination HR-MS.
>>
>> * For HR-MS FTN, the data packet is forwarded to next hop at MAC layer.
>> The data packets are not handled by upper layer protocol. HR-MS who forwards
>> data packet is still an HR-MS. It only has a very simple relay function and
>> can only support very few nodes, one or two.
>>
>>
>>
>> >From other HR-MSs' view, HR-MS performing the relay function is still an
>> HR-MS.
>>
>>
>>
>> HR relay is a kind of infrastructure station designed for the purpose of
>> relay. It is complex and like a BS. It is designed to support many MS in
>> network access.
>>
>>
>>
>>
>>
>> * Local forwarding means the infrastructure station between MS and BS
>> forwards data packets from downstream HR-station to destination HR-MS
>> without passing it to upstream infrastructure stations.
>>
>>
>>
>> A general case is a HR-RS forwards the data packets from one of its HR-MS
>> (source) to another HR-MS which is the destination.
>>
>>
>>
>> Eldad:
>>
>> - Not sure what is the meaning of "From other HR-MSs' view, HR-MS
>> performing the relay function is still an HR-MS." - could you please
>> clarify?
>>
>>
>>
>> - >From the SRD, an HR-RS is " A relay that complies with the
>> requirements for relays in this amendment". This is an amendment to 802.16n
>> or 2009, which means that an HR-RS is an RS or ARS as amended by 802.16n. I
>> don't think we need to define it any further, although we'll need to specify
>> how to implement the requirements we have agreed to in the SRD.
>>
>>
>>
>> Haiguang:
>>
>> My meaning is that the HR-MS should aware that the MS forwards data
>> control for it is an HR-MS. It is not a relay station.
>>
>>
>>
>> Sungcheol Chang:
>>
>>
>>
>> From the discussions and the definitions in the 16n SRD, the definitions
>> of direct communication and HR-MS forwarding are clearly different in
>> respect of data flow.
>>
>>
>>
>> But I still confuse that the technical difference between HR-MS forwarding
>> and HR-RS functionalities.
>>
>> Even though HR-RS is an infrastructure node and HR-MS is a user terminal
>> in nature, I think their names are not important. If devices should receive
>> packets transmitted by HR-MS, a receiving function within devices is to
>> receive the packets. Whatever the devices are called like HR-MS or HR-RS.
>> Their receiving functionalities are similar in nature.
>>
>> I want to know what the technical differences are because we are in
>> developing the AWD text proposal.
>>
>>
>>
>> What happen if we replace 1) HR-MS with HR-RS 2) forwarding HR-MS with
>> HR-RS in the following definition?
>>
>> The definition of forwarding: "An HR-MS that forwards data to
>> infrastructure node or to another forwarding HR-MS that is attached to an
>> infrastructure node (if multi-hop is supported) does so without passing any
>> data to or from higher layers."
>>
>>
>>
>> What happen if we assume a forwarding HR-MS as a HR-RS serving one
>> sub-ordinate HR-MS only? Under this assumption, please list the technical
>> difference between a forwarding HR-MS and a HR-RS serving one sub-ordinate
>> HR-MS only. Personally, if we achieve a forwarding HR-MS functionality with
>> simple modification of HR-RS including signaling procedures, I prefer the
>> modification rather than defining new function and transmission schemes
>>
>>
>>
>> Also I'd like to know what forwarding HR-MS is more simple than HR-RS. I
>> understand that HR-RS has more functionalities than HR-BS and HR-RS is a
>> infrastructure node. There are two views about complexity. The one is
>> hardware complexity because HR-RS is designed to serve multiple HR-MS. This
>> complexity is not important issue in respect of functionalities. The other
>> is functional complexity. HR-RS support two interfaces for relay operation:
>> 1) interface between HR-BS and HR-RS, 2) interface between HR-MS and HR-RS.
>> It's clear that forwarding HR-MS has two interfaces also. The relay
>> specification describes relay function in HR-RS, which is required to relay
>> data and packets to HR-BS or HR-MS. Even though more than HR-BS
>> functionalities, the HR-RS functionalities are selected ones required for
>> relay operation. From this understanding, please list what forwarding HR-MS
>> is more simple than HR-RS. It will help me to understand what the forwarding
>> function is.
>>
>>
>>
>> *[Eldad] the SRD states clearly that forwarding is a functionality of the
>> HR-MS not the HR-RS (see excerpt below). Obviously there will be
>> similarities between the forwarding function and a relay function as both
>> support 2 interfaces. That doesn't mean that the two are the same. The
>> amount of similarity will be determined by technical contributions. For
>> example only, frame structure can resemble relays (i.e. transmission in both
>> UL and DL zones) or be in UL only (as some proposed).*
>> 6.1.3.2  HR-MS forwarding to network
>>
>> HR-MS forwarding is defined as the case where the origination and
>> termination of data are at the HR-MS and network respectively and vice
>> versa.
>>
>> HR-Network shall support HR-MS forwarding of user data and control
>> signaling between HR-MS and HR-BS and between HR-MS and HR-RS.  The control
>> signaling and data transmission for the HR-MS to HR-MS direct link shall at
>> least be capable of operating within the frequency band that the HR-BS
>> operates.
>>
>> An association establishment shall be supported.
>>
>>
>>
>> Ming-Tuo: Haiguang, I am not so clear bout  "It only has a very simple
>> relay function and can only support very few nodes, one or two."  -- you
>> mean in Forwarding to Network, the a data packet can only be forwarded to
>> only one or two HR-MSs? Eldad, Sungcheol and all, what's your opinion?

Haiguang: I mean the number of HR-MSs attached to one forwarding HR-MS could be
          limited. However, there could be many HR-MS within a cell perform the
          forwarding function. That's my consideration. It may help in simplifying
          the design of HR-MS forwarding protocol. But if we can come out
          elegant solution that one forwarding HR-MS can support many HR-MSs, I am
          fine with that.   



>> (Ming-Tuo) 4. Is HR-MS forwarding to network is allowed in case that both
>> HR-MS and the forwarding HR-MS are out of coverage of any HR infrastructure
>> station?

Haiguang: For this point, I have to say that I did no see this case from the
          use case discussion. 


>>
>>
>>
>> (Ming-Tuo) 5. In "Forwarding to network", what the meaning of "Network" -
>> if there is no backbone connect, is the "Network" there?
>>
Haiguang: I think "forwarding to the network" refers to data flow direction,
          from HR-MS --> HR-BS/HR-RS or other stations. But if it may cause
          confusion, we can replace it with a better terms.  
>>
>>
>>
>> Finally, the following is expected to be made:
>>
>>
>>
>> [Consensus:                                          ]
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Thank you very much.
>>
>>
>>
>>
>>
>>
>>
>> Best regards,
>>
>>
>>
>>
>>
>>
>>
>> Ming-Tuo Zhou
>>
>>
>>
>> 16n DC RG co-chair
>>
>>
>>
>>
>>
>
>