Re: [STDS-802-16] =?big5?Q?=B5=AA=CE`:?= [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.