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

Re: [STDS-802-16] =?big5?Q?=B5=AA=CE`:?= [STDS-802-16] [M MR-AH-UM] The s eparation of control and data in relaying



Dear all.

I also agree with Dr Ren and Gang's comments.
We have presented the same idea in the meeting 43# (proposal 008r2 slides
9 - 11).
It requires the MS/SS within the coverage of RS and has a good link to BS.

It might be able to considered as a layer 2 routing issue.

Best regards.

Haiguang

-----Original Message-----
From: frank_ren@ITRI.ORG.TW [mailto:frank_ren@ITRI.ORG.TW]
Sent: 2006年6月6日 17:43
To: STDS-802-16@listserv.ieee.org
Subject: Re: [STDS-802-16] 答复: [STDS-802-16] [MMR-AH-UM] The s eparation
of control and data in relaying


Dear all,

I agree Gang's proposal and the concept was presented in 2nd MMR-SG meeting
(Refer to "IEEE C802.16mmr-05/023" and "IEEE C802.16mmr-05/027r2").

The special case will introduce a requirement to enable an RS to send
preamble and MAP or not.
   - For coverage extention case, the RS shall be enabled to send preamble
     and MAP.
   - For throughput enhancement only, the RS can be disable to send
premable
     and MAP to save the overhead of control relaying.


Fang-Ching (Frank) Ren

---------------- Original Message ----------------
> CTO Shen Gang <Gang.A.Shen@ALCATEL-SBELL.COM.CN> 2006-06-06 05:10:06 PM
wrote:

收件人: STDS-802-16@listserv.ieee.org

主旨: [STDS-802-16] 答复: [STDS-802-16] [MMR-AH-UM] The s eparation of
control and data in relaying

Dear Tousuf and  all,



The separation of  control and data is only dedicated for the throughput
enhancement relay, where  MS is located within the BS coverage and it can
receive BS’s control message  directly.

It's not neccessary for RS to forward control messages  from BS to MS.
However, RS should receive BS's control messages dedicated  for itself for
scheduling and resource allocation.



For the case that RS is  deployed for extending the coverage, BS control
messages are relayed.



Could we regard the separation of control and data as a  special case of
routing, where data traffic and control messages follow  different paths?



Best Regards,



Gang Shen

-----原始郵件-----
發件人: Yousuf.Saifullah@nokia.com  [mailto:Yousuf.Saifullah@nokia.com]
發送時間: 2006年6月6日  1:00
收件人: CTO Shen Gang; STDS-802-16@listserv.ieee.org
主題:  RE: [STDS-802-16] [MMR-AH-UM] The separation of control and data in
relaying


Hi Gang,
If we will not involve relay in the control messages, how  are we going to
cover the case, where RS is deployed for extending the  coverage?

Regards,
Yousuf


From: ext CTO Shen Gang  [mailto:Gang.A.Shen@ALCATEL-SBELL.COM.CN]
Sent: Sunday, June 04,  2006 9:43 PM
To: STDS-802-16@listserv.ieee.org
Subject:  [STDS-802-16] [MMR-AH-UM] The separation of control and data in
relaying


All,



Do we want  to talk about the separation of control and data in relaying?
That is, the  control information (preamble, MAP, and etc.) from BS is
directly  transmitted to MS without relay involved. And data is relayed for
throughput  enhancement. This is dedicated for throughput enhancement
relay, where MS is  located within the coverage of BS to get the BS
broadcast information  directly. This broadcast information is always
transmitted with the most  robust modulation scheme (which has the highest
possible reach).



The  separation of control and data may provide some advantages:

1, Simple RS  design: all the control and scheduling functions are located
in BS, and RS  only takes responsibility of data forwarding under BS
coordination.

2, Bandwidth  saving: RS does not need to forward these broadcast
information

3, No delay  for MAP information: if RS is required for relaying MAP or
other control  messages to MS, some extra delay is inevitable.

4, easy  handover within one BS coverage.



Best  Regards,



Gang  Shen
-----原始郵件-----
發件人: Zion Hadad  [mailto:zionh@RUNCOM.CO.IL]
發送時間: 2006年6月2日 19:15
收件人:  STDS-802-16@listserv.ieee.org
主題: Re: [STDS-802-16] [MMR-AH-UM]  Announcing 6/1/06 Meeting of Multihop
Relay Usage Model Ad Hoc  Group



All,

Do we want to  talk about the Relay separation/isolation between Rx to Tx:
in Frequency,  Time, Space (antenna directivity or physical separation) or
any mixed  between them? The type of isolation will enforce the relay
coverage gain  (or interference), delay, cost etc. this will lead to the
best fit for  each coverage area type, this will lead to the question if we
want one  size (solution) that feet all? If we want to keep this question
open then  we have to reflect that in the document.

Zion






From:Asa  Masahito-c22106 [mailto:asa@MOTOROLA.COM]
Sent: Tuesday, May 30, 2006 4:07  AM
To:  STDS-802-16@LISTSERV.IEEE.ORG
Subject: Re: [STDS-802-16]  [MMR-AH-UM] Announcing 6/1/06 Meeting of
Multihop Relay Usage Model Ad Hoc  Group



Jerry and  all,



My  comments are:



a) Uniformity  of titles in 3.1-3.4

I do not  feel uniformity of title in section 3.

So my  suggestion is

 3.1  Outdoor coverage ....

 3.2  In-building coverage ....

 3.3  Temporally coverage ...

 3.4  Mobile platform coverage ....



Can we say  RS characteristics in this section

since they  are missing in the crrent version?



b) 4.  Performance objective

Is it  possible to describe in general way

why  performance enhancement is expected ?

For  example,

 -  Link is divided into shorter ranges by RSs to increase received signal
strength

 -  RSs are located selecting better condition of field strength for
both receiving and transmitting

 - RS  decodes information and re-transmits it with certain delay and
frequency  scheduling

     to obtain better performance. Interference mitigation is  expected.

 -  etc.



Best  Regards,

Asa








From:Sydir, Jerry [mailto:jerry.sydir@INTEL.COM]
Sent: Sunday, May 28, 2006 2:17  AM
To:  STDS-802-16@listserv.ieee.org
Subject: [STDS-802-16] [MMR-AH-UM]  Announcing 6/1/06 Meeting of Multihop
Relay Usage Model Ad Hoc  Group

Dear Ad Hoc  participants,



As we discussed in the  previous meeting the next meeting of the Multihop
Relay Usage Model Ad Hoc  Group will occur on Thursday June 1,  06:00 –
08:00 PDT (13:00 –  15:00 UTC). (At the meeting we will discuss varying the
meeting times to  accommodate people’s schedules).



The bridge for the meeting is  916-356-2663, Bridge: 1, Passcode: 8272405.



I have updated the draft to  include modifications to the outline that we
agreed to in the May 25  meeting and to incorporate some preliminary text
into the sections (based  on content from session 43 contributions). I
encourage participants to  review the draft and to discuss the draft via
email before the meeting. I  will send out an agenda for the meeting on
Wednesday. The new draft is in  the temp directory in the upload server in
the following location:  C80216j-06_UMAHtemp_r1.doc  .



I look forward to a productive  discussion and to making progress toward
our goal of creating a harmonized  contribution.



Best  Regards,

Jerry  Sydir

本信件可能包含工研院機密資訊,非指定之收件者,請勿使用或揭露本信件內容,並請
銷毀此信件。
This email may contain confidential information. Please do not use or
disclose it in any way and delete it if you are not the intended recipient.