Re: [STDS-802-16] ??: [STDS-802-16] [M MR-AH-UM] The s eparation of control and data in relaying
Dear Ad hoc participants,
I will add this topic to the agenda for the meeting tomorrow.
My personal opinion is that I agree with Yousuf. This is getting too much into describing a solution and the usage model document should remain at a higher level.
Regards,
Jerry
-----Original Message-----
From: Matty Levanda [mailto:Mattyl@WINETWORKS.COM]
Sent: Wednesday, June 07, 2006 1:07 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 believe the separation of control and data in relaying is a special case of the cooperative relaying. A short explanation of cooperative relaying demonstrates this.
Starting from the MS point of view, the MS must detect and communicate with one BS or more. The BS it detect can have one antenna or a few antennas (for MIMO). I.e., the BS and all RS should present themselves to the MS as a collection of BS. For the ease of the description, let's name a collection presenting itself as BS, a virtual BS (VBS). A VBS is identified by a unique transmitted preamble. If a collection of BS and 20 RS transmits 10 distinct preambles, the MS can detect 10 BS, so we have 10 VBS.
Note that a RS can take part in one VBS during part of the frame and in another VBS in another part of the frame. This is, however, a complication we need not discuss at present.
Few examples:
1- VBS made of one RS. In this case the MS receives all data and control from this one RS
2- VBS made of several RS, all transmit the preamble. In this case the MS receives all data and control from all RS, all RS send the same waveform, and MS is unable to tell if the VBS has one antenna or more. MS detects one BS with one antenna (antenna 0).
3- VBS made of several RS, some of them transmit the same preamble. In this case the MS regards the VBS as a BS with an antenna array. The RS transmitting the preamble are antenna 0, and other RS are antenna 1,2 and 3.
4- VBS made of BS and several RS, only BS transmits the preamble. In this case the MS regards the VBS as a BS with antenna array. The BS transmitting the preamble is antenna 0, and other RS are antenna 1, 2 and 3. This is the case of separated control and data path discussed in the emails below.
The partition of RS into VBS is controlled by the BS (as the RS fine synchronization).
Best regards,
Matty
-----Original Message-----
From: Yousuf Saifullah [mailto:Yousuf.Saifullah@NOKIA.COM]
Sent: Tuesday, June 06, 2006 2:38 PM
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
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.
>