RS Grouping and Cooperative Relay Ad-hoc Commentary Resolution Discussion

IEEE 802.16 Presentation Submission Template (Rev. 9) Document Number:

IEEE S802.16j-07/542Date Submitted:

2007-10-26Source:

Senarath Gamini Voice: 613 763 5972Nortel E-mail: gamini@nortel.com

Adrian Boariu Voice:Nokia E-mail: adrian.boariu@nsn.com

Venue: Call for Reply Comments on the Resolutions for P802.16j/D1Base Contribution: IEEE C802.16j D1Purpose:

To provide commentary resolutions for RS grouping and Cooperative Relay Ad-hocNotice:

This document does not represent the agreed views of the IEEE 802.16 Working Group or any of its subgroups. It represents only the views of the participants listed in the “Source(s)” field above. It is offered as a basis for discussion. It is not binding on the contributor(s), who reserve(s) the right to add, amend or withdraw material contained herein.

Release:The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that

this contribution may be made public by IEEE 802.16.

Patent Policy:The contributor is familiar with the IEEE-SA Patent Policy and Procedures:

<http://standards.ieee.org/guides/bylaws/sect6-7.html#6> and <http://standards.ieee.org/guides/opman/sect6.html#6.3>.Further information is located at <http://standards.ieee.org/board/pat/pat-material.html> and <http://standards.ieee.org/board/pat >.

RS Grouping and Cooperative Relay Ad-hoc Commentary Resolution Discussion

{This is a working document}

Chairs: Gamini Senarath and Adrian Boariu

Summary (1) • Accept / Accept modify:

– 624, 625 (by 624)– 622, 621 (by 622, and accept also the suggested editorial changes

throughout the document)– 627– 979– 626

• Easy resolutions which may be rejected:– 623 (Reason: Members wanted to know where the RS group it is used)– 978 (Reason: Line 19, page 199 already indicates that the RS shall not

forward an incorrectly decoded burst to its subordinate stations)- 1055 (Agreed that RS group has a single parent station no subordinate

RSs for simplicity)• Withdrawn (again double-check with the authors):

– 629, 630, 633, 635

Summary(2)• Easy to decide:

– 436, 810, 438 (decide the best way to incorporate 810 in 436)– 811– 636, 638, 639 and first portion of 637 (rephrase the section with the

correct section references)– 975 (needs more clarification)

• Pending decisions:– 632, 634 (HARQ), 644 (RS-CD)

• Need more discussions:– 301, 306 [533]– 628– 637– 673– 683– 977, 976

RS Grouping and corporate Relaying – Adhoc (Marked in Red are not assigned to this adhoc)

Comment

Description Harmonized suggestion Action Recommended

301 Merge the RS_CDC-REQ message into the RS_Config-REQ (Mike)

Accept modify. Agreeable. Need discussion.

306 (1) Table # 109 to be replaced by 183a, (2) [change 6.3.2.3.xx to 6.3.2.3.86 on line 4 page 41] (3) The MR-BS shall indicate the effective number of ....", where does this effective antenna is defined, how MR-BS (4) Where will the configuration indicated in RS_CDC-REQ_message be effective? Does it last till the next configuration?

(1) And (2) are superseded by 304.

(3) And (4) need to be discussed.

Need discussion.

356 proposes to change the text in the RS grouping section (page 104) and unicast RSID and multicast ID in the RS-CD, RS-config_msg message [Network Entry Adhoc]

Accept modify – some changes in the text may be needed. - Contribution #07-469r1

Accept modify Contribution #07-469r1

360 Unicast RSID => RS Basic CID,

[Network Entry Adhoc]

Include in #356 with multicast RSID Muticast RS CID

Superseded by modified #356

(Contribution #07-469r1)

361 Same as above 360 in the table 183f

[Network Entry Adhoc]

Accept Modify with 16 bits in both lines for multicast CID. Include in #356

Superseded by #356

362 [Network Entry Adhoc] Multiacst RSID field – 8 to 16 bits in Fig 183f (multicast RSID is 16 bits)

Further additions to #361 Superseded by #356.

624, 625

Change a single bulleted item in 6.3.9.16.3.1 Multicast RSID to mulicast CID, unicast RSID to basic CID. (Adrian), 360(Gamini)

Superseded by modified #356.

Since #356 is not in this adhoc, this can be seperately accepted.

Accept 624, Supersede 625 by 624

Harmonization of RS Grouping and corporate Relaying Related Comments (6)

Comment

Description Harmonized suggestion Action Recommended

436 RS member update list to be changed to be byte aligned? – but this suggest a greater change than what is currently in.

Needs more discussion. Accept modify contribution #07-488.

Comment #810 too modify this message to include “access RS” , Accept modify to include #810:

Accept modify to

(include #810 & 811).

438 To remove one field in the message. What is currently in is different,

Superseded by #436 Superseded by#436

621 Move 6.3.9.16.3.1 (RS Grouping) to a new section, e.g.. to 1.4.3 & delete system in RTS system, NTRS system (Erik)

Include a high level description in 1.4.3. Deletion of “system” - Addressed move as in 622.

Part superseded by 622; accept also the editorial changes throughout the document.

622 Move 6.3.9.16.3.1 to another section. {Mike}

Accept Modify {Move section as 6.3.7} and renumber other section. Move subclauses 6.3.9.16.3.1.1 and 6.3.9.16.3.1.2 to appropriate network entry (T-RS or NTRS) after text modifications..

Accept 622

Other parts supersede by 637, 642:

617 [Network Entry Adhoc] 6.3.9.16.3 Add summary of network entry para. where RS group configuration is also described.

Ready to go (no replies). Discuss in the network entry??

623 Benefits are unnecessary to include first para and bullets in 6.3.9.16.3.1 (Jiamin Lu)

This was added in #50 as members wanted where RS group is used. Need to clarify this and see authors view.

Discuss as it is: Reject

626 BSID is limited to RS group with different preamble than parent. (1) accept modify due to misunderstanding? (Adrian)

Accept Accept

Harmonization of RS Grouping Related Comments (8)Comment Description Harmonized Change Action

627 Eugene – to use MS power correction term to correct Open Loop Power control

Accept – relate to 1050 Accept

628 Assign one group member as a designated RS for certain functions such as ranging, special data forwarding, etc.(Gamini), This also supports the existing definition of access RS (see 810).

Need. Discussion. Seem to agree in the discussion to accept.

(1, accept, 1 reject sashi).

Relate to 810. Need to discuss.

629 Transmission of same information to different MSs by RSG members. How this is done – request delete (Erik), Gamini – reject, Okuda san (accept)

Discussed and clarified.

would be withdrawn

Withdraw

630 Obviously data can be sent to two RSs (Jiamin Lu) Same as above for different reason – not obvious how it is achieved. – discussed

Withdraw

632 6.3.17.4.2.2 – Data forwarding can be done using HARQ procedure for multiple T-RS (Eugene) –1 Accept

Accept or move to HARQ session. Accept: Pending on HARQ

633 6.3.9.16.3.1 page 104, line 53 (UL tx in RS group): Distributed diversity combining is not enabled. Author seem to misunderstand this as distributed diversity combining. This is cooperate diversity. {Eugine}

To be withdrawn as it is not really soft combining. More clarifications may be done in a later meeting.

Withdraw

634 Data forwarding can be done using HARQ procedure for T-RS (Eugine}-

Accept or move to HARQ session. Accept: Pending on HARQ

635 Remove lines for data forwarding sighting obviously data can be sent to two RSs (Jiamin Lu) in the same time

This is not obvious and may need explanation – discussed

Withdraw

RS Grouping Related Comments (7)Comment Description Harmonized Change: Action:

636, 637, 638, 639

Either correct text (parent super ordinate), remove or move this section.6.3.9.16.3.1.1] (Gamini, Erik, Adrian, Hyunjeong, Yousuf)

Section has not changed after RS configuration changes in #50. Contribution 503 (comment #637) may be modified to incorporate changes.

Accept harmonized #637 (C07-503r1): 636,638,639 and fist portion on 637 easy to harmonize.

2nd part of 637 more discussion.

642

640, 641, 643

[Delete: 6.3.9.16.3.1.2] and add following sentence in configuration section. The MR-BS can configure the RS as a transparent RS, non-transparent RS, or as a member of an existing or new RS group. [Network Entry Adhoc]

Accept { this is part of configuration}. Accept 642

644 (clear editorial mistake done in Meeting #50).

Replace "RS_Configuration_REQ/RSP" with "RS_Config-REQ/RCM“, Replace "RS_Config-RSP from "RS_Config-RCM

However, RS-config message consolidation with RS-CD may have an impact. Either we can accept this or wait till comment 358.

Clear mistake. pending RS_CD

669 When a mobile moves its new anchor station needs to be changed. For this procedure is described in Section 6.3.22.5.2.

[Mobility management Adhoc]

Accept

{ Already noted as superseded by #565 (contribution 459r6 which seems to be not the case)

Already superseded

673 Designated RS for ranging.

The movement of MS within RS group can be accepted as it is obvious.

Designated RS part can be discussed with 810. The movement of MS can be accepted.

Part accept.

Part discuss with 810.:more discussion

683 Designated RS for ranging message forwarding..

The movement of MS within RS group can be accepted as it is obvious.

Designated RS part can be discussed with 810. the movement of MS can be accepted.

Part accept.

Part discuss with 810.: more discussion

RS Grouping Comments

Comment Description Harmonized Change Action

975 Scheduling of synchronous burst transmissions can be performed according to the MBS scheduling strategy in Section 6.3.23.3

need discussion Easy to resolve – :easy, more clarification

976 The difference between source diversity and RS grouping? Remove corporate source diversity?

See below 977. see 977

977 Corporate source diversity applicable to NTRS as well? Otherwise it is same as RS group. Remove restriction and add clarification.

Accept Accept more discussion

978 What happens in case of decoding error at the antenna for STC?

Move to HARQ? reject

979 Editorial – move some text from figure title to the text area. (Mike)

Accept

1055 RS group can have a chain of RSs and path needs to be defined.

The general agreement was all members have single parent (single hop).

Reject.

Corporative Relay Comments - 6

Comment Description Harmonized Change Action

810/811 811 was discussed in meeting 51 and issue was to find a suitable name. for “access RS” 6.3.22.5.2

810: Change in Table 183z,(6.3.2.3.84 to include “access RS”

{811 is in mobility management adhoc}

811 superseded by 810 Change the table entry to “designated RS”

Modify “Access RS” to designated RS and “Non-Access” RSs to “Non-designated” RSs in 6.3.22.5.2

Accept Modify 810