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

Re: [STDS-802-16] ??: [STDS-802-16] [M MR-AH-UM] The s eparation of control and data in relaying



Hello,
One issue with this approach is that how an MS can be synchronized with the MMR-BS and RS simultaneously, so it can read control from MMR-BS and data from RS. 

Anyway, my suggestion is to keep the usage model at a high level only describing usage and necessary information explaining it. We should not get into details such as the separation of control and data. This would help us avoiding technical issues around the details. We should surely discuss the separation of control and data plane when we discuss the solutions and proposals. 

Best Regards,
Yousuf 

>-----Original Message-----
>From: ext Wang Haiguang [mailto:wanghg@I2R.A-STAR.EDU.SG] 
>Sent: Tuesday, June 06, 2006 5:05 AM
>To: STDS-802-16@LISTSERV.IEEE.ORG
>Subject: Re: [STDS-802-16] ??: [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.
>