16jm Ad Hoc Group Report

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

IEEE C802.16m-08/242Date Submitted:

2008-03-17Source: Ad Hoc Group Chairs

Rakesh Taori , Voice: +82-31-280-9635Samsung Advanced Institute of Technology E-mail: rakesh.taori@samsung.com Mt. 14-1 Nongseo-Dong, Ginheung Gu, Yongin-si, 446-712, South Korea

Peiying ZhuNortel Networks

Source: Base documentVenue:

.Orlando, Florida (USA)Base Contribution:

NonePurpose:

For discussion in TGm Notice:

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 >.

16jm Ad Hoc Group Report

16jm Ad Hoc Group Chairs16jm Ad Hoc Group Chairs

Rakesh Taori and Peiying ZhuRakesh Taori and Peiying Zhu

Outline

• Charter of the 16jm Ad Hoc Group• Executive Summary• Recommendations of the AHG

(Not yet confirmed by the AHG)• Detailed summary of the E-mail discussions

Charter of the 16jm Ad Hoc Group

• Conduct Discussions on1. Support of 16j relay station (RS) in 16m2. Scope of 16m relay

• Deliverables– Recommendation on the issues mentioned above.

Executive Summary (1/2)

• On the issue of “Support of 16j RS in 16m”– Consensus: A 16m BS should support 16j RS.

• One objection from Hadad (Runcom).

– Recommendations for the group• Text drafted for inclusion in the SDD

– Three (similar) proposals. To be finalized in the TGm/TGj joint session.

– Topics still under discussion• Exactly which connections should be supported.

– Options drafted. To be discussed in the TGm/TGj joint session.• Modifications to SDD architecture diagram to align with the text

– Initial Figure proposed. To be discussed in the TGm/TGj joint session.

Executive Summary (2/2)

• On the issue of “Scope of 16m Relay”– Discussed the relay scope using Relay attributes.– There were comments about discussing usage

models prior to discussing attributes.– No specific recommendation.– Survey of preferences for Scope

• 19 responses• Inputs summarized to facilitate discussion.

– 5 attributes show clear support to be considered further.– 2 Attributes show no support except from the proponents.

AHG Recommendations on the issue of

“Support of 16j Relay Station in 16m”

SDD Text Proposal for Legacy (16j) RS support

• A 16m BS that is capable of supporting a 16j RS, shall communicate with the 16j RS in the "legacy zone". The 16m BS is not required to provide 16j protocol support in the "16m zone". The 16m relay link protocols used in the "16m zone" may be different from 16j protocols used in the "legacy zone".

• Last sentence: – Option 1:The 16m relay link protocols used in the "16m zone" may be

different from 16j protocols used in the "legacy zone".– Option 2: The design of 16m relay protocols should be based on the

design of 16j wherever possible, although 16m relay link protocols used in the "16m zone" may be different from 16j protocols used in the "legacy zone".

AHG Recommendations on the issue of

“Scope of 16m Relay”

Recommendations on 16m Relay Attributes

• Consider (No opposition)– Duplexing Scheme (Support TDD and FDD)– MS awareness of Relay– Multicarrier support– In-band and Out-of-band– Tree Infrastructure topology

• Do not consider (No support except proponent)– Support for direct connection between MS– Cooperative relay utilizing MS relay

• More discussion needed on the remaining attributes.

Still under discussionon the issue of

“Support of 16j RS in 16m”

Worth taking the view of the group

16m BS 16MR- BS

16m RS 16j RS

16m MS 16e MS

(O)(O)

(O)(O)(O)

X

X

(?)

Case Path

1 16m BS to 16m RS O

2 16m BS to 16j RS O

3 16MR-BS to 16m RS X

4 16MR-BS to 16j RS O

5 16m RS to 16m MS O

6 16m RS to 16e MS ?

7 16j RS to 16m MS X

8 16j RS to 16e MS O

Connection Configuration

Change proposal to SDD Network Architecture

802.16eMS

802.16mMS

802.16eMS

802.16mMS

802.16mRS

802.16mBS

802.16mBS

802.16mBS

802.16mBS

802.16jRS

Alignment of the SDD Architecture Diagram with the proposed text for 16j RS support in 16m

AHG inputs on the issue of “Scope of 16m Relay”

Attribute Title 16j Attribute (Choices) Attribute Summary

1 Number of Hops ≥2 hops (a) Limit to 2-hops(b) ≥ 2 hops.

#Responses: 19#a: 8#b: 8#Undecided: 3

2Topology of

Infrastructure Stations

Tree (a) Tree(b) Mesh.

#Responses: 19#a: 14 + 5 (5 chose

Both)#b: 0 + 5 (5 chose

Both)#Undecided: 0

3 Transparent and Non-Transparent RS Both

(a) Non-Transparent RS only

(b) Support both.

#Responses: 19#a: 9#b: 9#Undecided: 1

4Centralized and/or

Distributed scheduling

Both(a) Distributed Scheduling

only (b) Support both.

#Responses: 18#a: 7#b: 11#Undecided: 0

5Centralized and/or

Distributed Control

Centralized(a) Centralized control only

(b) Support both.

#Responses: 17#a: 4#b: 6#Undecided: 7

6 Fixed/Nomadic RS and/or Mobile RS All (a) Fixed RS only

(b) Support both.

#Responses: 18#a: 6#b: 12#Undecided: 0

7Centralized and/or

Distributed security

Both(a) Centralized security

model only(b) Support Both.

#Responses: 17#a: 4#b: 9#Undecided: 416

m R

elay

Attr

ibut

es S

umm

ary

(1/3

)

Attribute Title 16j Attribute (Choices) Attribute Summary

8 MS Awareness of Relay Out of scope (a) Support

(b) Do not Support

#Responses: 18#a: 15#b: 0#Undecided: 3

9 Cooperative Relay Supported (a) Support(b) Do not Support

#Responses: 18#a: 15#b: 2#Undecided: 1

10 Duplexing Scheme TDD only?

(a) TDD only(b) Support TDD and FDD (including H-FDD MSs)

#Responses: 18#a: 0#b: 17#Undecided: 1

11 Multicarrier Support Not Supported (a) Support(b) Do not Support

#Responses: 17#a: 13#b: 0#Undecided: 4

12Intra-Cell Relay to Relay direct communication

Not supported (a) Support(b) Do not support

#Responses: 17#a: 6#b: 8#Undecided: 3

13Inter-Cell Relay to Relay direct communication

Not supported (a) Support(b) Do not support

#Responses: 17#a: 4#b: 10#Undecided: 3

14

Duplexing of relay link and access link (Half duplex relaying (HDR) or Full duplex relaying (FDR))

Supports only HDR. No specific FDR support.

(a) HDR(b) HDR and FDR

#Responses: 15#a: 2#b: 8#Undecided: 516

m R

elay

Attr

ibut

es S

umm

ary

(2/3

)

Attribute Title 16j Attribute (Choices) Attribute Summary

15 Out-of-band relay Supported (a) Support(b) Do not Support

#Responses: 14#a: 14#b: 0#Undecided: 0

16 MS relaying data for another MS Out of scope

(a) Support(b) Do not support(c) For Future Study

#Responses: 15#a: 3#b: 5#Undecided: 7

17Support for direct connection between MS

Out of scope(a) Support(b) Do not support(c) For Future Study

#Responses: 14#a: 1#b: 4#Undecided: 9

18Intra-Cell Virtual MIMO using Cooperative relay

Supported (a) Support(b) Do not support

#Responses: 15#a: 14#b: 1#Undecided: 0

19Inter-Cell Virtual MIMO using Cooperative relay

Not supported (a) Support(b) Do not support

#Responses: 14#a: 8#b: 4#Undecided: 2

20 Cooperative relay utilizing MS relay Out of scope

(a) Support(b) Do not support(c) For Future Study

#Responses: 13#a: 1#b: 6#Undecided: 6

21 RS group Supported (a) Support(b) Do not Support

#Responses: 12#a: 8#b: 3#Undecided: 116

m R

elay

Attr

ibut

es S

umm

ary

(3/3

)

E-mail Discussion Details

• Support of 16j RS in 16m• Scope of 16m Relay

E-mail discussions: In response to the Kick Off Message…(1)

• Shyy (Mitre): Expressed concern about using slide 10 of 802.16m/065 as the starting point. Why use attributes in slide 10 of 065 are "automatically“, while others need who wish to add, modify or delete these attributes need to justify the action with a contribution. Suggested to start fresh with the attributes.

• Zeira (Interdigital): Premature to try to discuss mandatory/optional features. Determine the benefits and complexity of a set of features in the context of 16m first. Suggests not to discuss mandatory/optional at this stage.

• Sydir (Intel): (In response to Shyy): List on slide 10 of 802.16m/065 represents the major choices made in the definition of 16j. In defining the scope of relay in 16m it makes sense to start with 16j and thinks that the list is a reasonable starting point. Thinks that instead of starting from scratch, more productive to discuss what attributes need to be added/removed. If there are attributes in the list that a majority of particiapnt feel should not be there, they will be removed.

• Eklund (NSN)– Support of 16j RS in 16m: 1. Expressed that .16 and WiMAX will need a relay solution for selected use cases much

earlier than 16m will be available i.e. based on 16j. Believes that 16 WG should give a loud and clear signal that the support for deployed relays will be maintained in future releases. Recommended that 16m should provide means to support 16j RSs, especially the ones that will have been deployed by operators. Expressed concerns against getting in to 16j profiling or feature pruning. Expressed that the system reference model of 16m in early phases should show 16j support (Functionality or lack thereof should not be extrapolated from the SDD reference model). If we could agree (or even explicitly formulate any disagreement) on the above statements I believe we have made some progress.

– Scope of 16m relay: Believes that t he SRD leaves room for defining a relay beyond what is defined in 16j. At the current time we need to make provisions for the relays in 16m.Now from a 16m point of view the trade offs to support relays (16j and others) must be reasonable and should not lead in to a plethora of alternative mutually non-coexisting designs. Also I see the discussion on the new relay functionality to be captured into the SDD happening at a date after the per-SRD-mandatory functionality has been discussed and settled in 16m. So my expectation is that relay will not feature prominently on the 16m agenda for some time. Recommended to consult the 16m dev timeline for guidance on when to discuss the new 16m relays.

E-mail discussions: In response to the Kick Off Message…(2)

• Humbert (Sprint): (in response to Eklund): Expressed that 16m SRD has relay as a low priority item and may delay 16m. Reminded people the need to focus on meeting all of the SHALL items in the SRD before spending months debating SHOULD requirements. Pointed that 16m SRD is vague on the requirements for Relay Stations and expressed (by means of examples) that a considerable effort to clarify what exactly are the requirements for a 16m relay station. Expressed that Eklund’s statements may be based on some fundamental assumptions that may or may not be part of what the WG decides to add into the 16m SRD for RS's. Recommended that the ad-hoc needs to focus on developing a set of requirements and then the 16m task group can decide what can and can not be developed in the agreed upon timeline.

• Saifullah (NSN): Expressed in response to Humbert’s message that some of the SHALL items need to consider relay up front, e.g.frame structure. Agreed with Eklund to refrain from making this effort a relay profiling activity. Concerned that distilling the complete list of attributes, including new attributes from new relay scenarios may take long time to converge. Recommeded to dentify and converge on those attributes for relay needed for the immediate task in hand, such as architecture and frame structure.

• Shyy (Mitre): (In response to Sydir): Offered two alternatives to handle attrubutes (1) Accept more attributes without the need of any contribution. (2) Delete all the attributes that have not bee agreed in 16j.

• Eklund (NSN): IN response to Humbert: Clarified that I am trying to accomplish is to not have every .16m meeting turn into a discussion on relays, and thus allow 16m to make timely progress”. Expressed that 16j is likely to be approved as a standard soon and that some flavor of it will be deployed before 16m will be deployed. Expressed the concern that offering no support for the deployed incarnation of 16j is likely to introduce significant delay in the adoption of 16m. Recoemmended the group to be proactive on the 16j support issue. Main goal is not to conclude to 100%, but signal intent to support a flavor of 16j even though we don't know which exact constellation of j will be relevant to support. Regarding the specifics of new relaying features of 16m, he expressed the belief that these “SHALL only be discussed in 16m at time when the discussion on the mandatory features.”

E-mail discussions: In response to the 2nd Message from the chairs (Topic: Two key issues to focus on)…(1)

• Summary of the 2nd message– Reminded to keep focus on the charter of the AHG (1) Support of 16j RS in 16m (b) Scope of 16m relay– Emphasized to keep the focus on attributes that are relevant to the architecture.– Noted from e-mails that there is no objection raised against “Support of 16j RS in 16m”. Invited additional views in

favour and against.– Based on e-mail discussions, initiated a attribute list and invited comments on attributes.

• Sydir (Intel): – Support of 16j RS in 16m: Agreed in principle that 16m BSs should provide legacy support to 16j RSs. Expressed the

need to agree more precisely on what this means. Reminded the group about the various options available in 16j and profiling of these options is not within the control of the 802.16 TG. Expressed that “It is my opinion that legacy support for 16j RSs should be provided in 16m in a way that allows the selection of the specific 16j features (the creation of the profile) to be supported by the 16m BS to occur outside of 16m and to potentially occur after the definition of 16m. It is important that the 16m schedule not depend on the completion of this profile”. Concluded that the implication of this requirement on the 16m frame structure is that 16j RSs need to be supported within the legacy zone of the frame. Since 16j is backwards compatible with 16e, it should be possible to support any subset of 16j features in the legacy zone, thus allowing the profile for 16j RSs to be defined on a decoupled schedule.

– Attribute list: Provided a spreadsheet indicating preferences on the list of attributes and proposed adding extra attributes. Wondered about the exact meaning of the attribute titled “Centralized/Distributed Control”. Provided explanatory note on the attributes “MS awareness of RS” and “Multi carrier Support”.

• Shen (Alcatel Shanghai Bell Co.)– Support of 16j RS in 16m: The multi-hop relay in 16m shall support both legacy 16e MS and new 16m MS. For more

than two years of standardization efforts, 16j is the best solution available for multi-hop relay supports with backward compatibility. So I think that 16m should support 16j RS for the purpose of providing multi-hop relay for 16e MS. For 16m MS, an advanced multi-hop relay with some new attributes is required with performance enhancement compared to 16j.

– Attribute list: 2, Agreed with Jerry that awareness of RS may benefit relay-related procedures, e.g. MS handover. Expressed that “If this awareness is not allowed in 16m, the relay performance in 16m can not overwhelm that we have had in 16j (no difference).” Expressed concern about simply copying some attributes from 16j into this spreadsheet. Recommended that new attributes may be used instead of simple reusing what we have in 16j. Proposed that 16m should consider both TDD and FDD relay to be consistent with 16m requirement.

E-mail discussions: In response to the 2nd Message from the chairs (Topic: Two key issues to focus on)…(2)

• Son (Samsung): Provided a spreadsheet indicating preferences on the list of attributes and proposed adding a new attribute (Full Duplex relaying) with a short expanation.

• Kang (Samsung): Agreed with Jerry regarding te definition of the 'Centralized and/or distributed control' attribute. Provided a document with criteria for what can be classified as centralized control and what can be classified as distributed control. Suggested that based on the classification, the protocol structure for 16m RS can be defined. Solicited feedback on definition, classification and the idea of a separate protocol stack for RS.

• Shyy (Mitre): Provided a spreadsheet indicating preferences on the list of attributes. Proposed to add attributes: Intra-cell relay to relay direct communication, Inter-cell relay to relay direct communication, Intra-cell virtual MIMO using cooperative relay, Inter-cell virtual MIMO using cooperative relay. Noted that Contribution C802.16m-08/047 provides explanation on these attributes.

• Shekalim (Runcom), Reddy (US Army), Chou (ITRI), Lee (LGE), Liu (ZTE): Provided a spreadsheet indicating preferences on the list of attributes.

• Tao (Mitsubishi): Provided a spreadsheet indicating preferences on the list of attributes and proposed addition of 2 additional attributes. Clarified that the attribute titled intra-cell relay to relay direct communication is possible in a tree topology, it may can also imply a mesh topology.

• Yan (Huawei): Sought clarification of the attributes (e.g.  "Centralized and/or Distributed scheduling" and "Centralized and/or Distributed Control“).

• Hadad (Runcom): Expressed the following “Since 16j is limited (TDD) and not finish, I believe 16jm has to start from the beginning. Adaptations of Ideas from 16j are welcome for consideration. At this moment we need to focus and to put hooks on the 16m frame structure before it will approve and fly. I hop the group or someone will come with such contribution for next meeting please consider wider scope then 16j ...real Mesh?? User to user connection...push to talk etc.”

E-mail discussions: In response to the 2nd Message from the chairs (Topic: Two key issues to focus on)…(3)

• Fong (nortel): – On the issue of 'Support of 16j RS by 16m BS', Expressed that it is important that 16m BS provides legacy support to 16j

RS. The legacy support should be done in such a way that the dependency on the profile of 16j relay, which is yet to be defined in forums outside of TGm, should be minimized. Recommended the group to focus on discussing/agreeing on the issue of 16m BS support for16j RS and the method to provide legacy support, e.g. in the legacy zone of the 16m frame structure

– Scope of 16m relay: Recommended the group to first discuss and agree on the usage models of 16m relay before going into defining the detailed attributes. Pointed out that 16m relay may have the same or different usage models than 16j in order to meet IMT-Advanced requirements. Argued that if the 16m usage model is the same as that of 16j, not to re-invent the wheel but limit to necessary enhancements that will provide performance gain. Suggested to avoid the situation of ending up with two entirely different sets of protocol operation/procedures for 16m MS support and legacy MS support. Pointed that “It is important that in TGm, we first establish a good foundations on the PHY and lower MAC enhancements on the access link before we work on the relay links.”. Recommended to focus on aspects that would impact the fundamentals of the 16m frame structure as listed in the Frame Structure Rapporteur Group spreadsheet .

• Sun (Toshiba): – Support of 16j RS by 16m BS: Considered 2 aspects (a) Specific legacy zone in 802.16m frame structure and (b) Absence

of specific legacy zone in 802.16m frame structure. (no particular preference was expressed) – Scope of 16m relay: Provided a spreadsheet indicating preferences on the list of attributes. Agreed with Fong’s view. In

addition, we also need to define the basic requirements of 16m relay with its usage models. Recommended that the group should establish the basis of the multihop relay in 16m before getting into depth.

• Emeott (Motorola): Provided a spreadsheet indicating preferences on the list of attributes. Proposed to add 3 attributes: MS relaying data for another MS, Support for direct connection between MS, Clarified that all the three attributes affect the network architecture and frame structure, as a new interface must be defined between MS to support one MS relaying data for another as well as to permit data transfers between two MS.

• Loa (III): Provided a spreadsheet indicating preferences on the list of attributes and proposed to add additional attributes Agreed in principle with the two hops limitation to the 16m relay as the starting point in order to reduce the complexity of the relay control plane, which was a lesson we learned from 16j. Suggested that the group should consider coverage with the relay by the RS group. Clarified that “BS – RS Group - MS” scenario and noted that the control and scheduling within the RS group is centralized in this scenario.

E-mail discussions: In response to the 2nd Message from the chairs (Topic: Two key issues to focus on)…(4)

• Sydir (Intel) Agreed with most of Kang’s document, but wondered how it helps to define the meaning of the single attribute (centralized/distributed control) in an explicit enough manner. Suggested a definition “Distributed control is the case where an RS makes all control decisions independently from the BS. Centralized control is the case where the BS coordinates or controls the actions of the RSs associated with it, although individual control functions still may be performed in a partially distributed fashion.” Asked the chairs if that was the intention.

• Zhu (Nortel): Indicate that Sydir’s interpretation seems to be in line with the 16j PAR.

• Saifullah (NSN): Provided a spreadsheet indicating preferences on the list of attributes. Highlighted that they have filled the attributes related to the architecture and frame structure. Emphasized that the March meeting should focus only on the attributes related to the architecture and frame structure. Expressed concern that extending discussion to all the different possible attributes may result in no harmonization at all.

• Yuefeng/Hart (NEC/PCCW):   Provided a spreadsheet indicating preferences on the list of attributes. Agreed with Saifullah about focusing on the main features related to the architecture and frame structure in this stage. Proposed a new attribute “Out-of-band relay & in-band relay", and provided a short explanation.

E-mail discussions: In response to the 3rd Message from the chairs (Topic: Next Steps)…(1)

• Sydir (Intel): – Legacy Support Text: Agreed with chairs’ conclusion on legacy support and the intetion of the chairs to draft some text

that the ad hoc can recommend for insertion into the SDD. Found the drafted text (in the e-mail) adequate. No modifications suggested.

– 16j relation with 16m: Agreed with Fong’s comments not to create that creates two completely different relay solutions. It makes sense to base 16m protocols on 16j, while making targeted improvements that improve performance and efficiency and align relay support with other 16m changes. We should be clear that although we are saying that the 16m relay protocols may be different than the legacy 16j protocols, this does not mean that they should be designed from scratch.

– Recommended to put together a collated version of the spreadsheet that includes all of the proposed attributes and allow folks to make another pass at filling in values for attributes that have been suggested by others.

• Hadad (Runcom): Indicated that he doesn’t agree with legacy support of 16j at this time under 16m. He thinks it is batter to wait and see where 16m is going before adding hooks. Expressed that in his opinion, 16j development will take long time to harmonize and develop within WiMax and manufactures. Further expressed that “I agree that if 16m will come as two solution dual mode 16e and green 16m then we may converge to two solution 16j with 16e and 16 mj with green 16m. in this case one want the freedom to chose which solution to support and not two. another word, If one will implement 16m then I probably chose 16m +legacy Wimax +relay on the new 16m part, if one develop only 16e then he may add 16j to develop boss relay standard is out of question.”

• Fong (Nortel): Proposed the following text for Legacy support “A 16m BS that is capable of supporting a 16j RS, shall communicate with the 16j RS in the "legacy zone". The 16m BS is not required to provide 16j protocols support in the "16m zone", although 16m relay support should be based on similar protocols design as 16j where applicable.”

E-mail discussions: In response to the 3rd Message from the chairs (Topic: Next Steps)…(2)

• Kang (Samsung): Expressed that several connection configurations are possible when talking about legacy support. Put forward a presentation showing different connections and their interpretation of what is supported and what is not. Emphasized that this is important for Frame Structure and Legacy Support issues.

• Sydir (Intel): Felt that Kang’s picture is very useful. Expressed his opinion that case 6: 16m RS to 16e MS should be supported as well.

• Koo (Samsung): Interested in knowing what the consensus view is regarding the different links expressed in the slide sent out by Kang.

• Sydir (Intel): Presented a more elaborate view on individual connections.• Sydir (Intel): in response to Fong’s comments: “I had contemplated making similar changes, but thought

that the original text did not say that 16m relay had to be different than 16j. The SRD already says that 16m support should be based on 16j and when we use words like "should" and "when applicable" the statements don't really have any binding meaning. I do agree with the intent, as I had indicated in my previous email. Alternative suggestion for the legacy support wording: “A 16m BS that is capable of supporting a 16j RS, shall communicate with the 16j RS in the "legacy zone". The 16m BS is not required to provide 16j protocol support in the "16m zone". The 16m relay link protocols used in the "16m zone" may be different from 16j protocols used in the "legacy zone", although the design of 16m relay protocols should be based on the design of 16j wherever possible.”

• Sun (Toshiba): Pointed that it is untrue that 'The SRD already says that 16m support should be based on 16j'. It might be also an assumption, at this moment, which seems/implies that 16m frame structure has already defined 'legacy zone‘ and '16m zone'.

• Sydir (Intel): Agreed with Sun’s finidings.• Fong (Nortel): Agreed with Sydir’s proposed Legacy text.• Sun (Toshiba): Proposed yet another alternative text (only for the last sentence): “The design of 16m relay

protocols should be based on the design of 16j wherever possible, although 16m relay link protocols used in the "16m zone" may be different from 16j protocols used in the "legacy zone".”

• Sydir (Intel): Thought that Sun’s wording on the Legacy Support Text is also fine.

E-mail discussions: In response to 1st consolidated attribute list and call for clarifications of attributes

• Kang (Samsung): Requested clarification as to why “cooperative relay” affects the architecture. And wondered whether relay to relay direct communication can already be covered by the "Topology" attribute (#2).

• Shyy: Replied to Kang’s question on relay-to-relay direct communication. “In principle, the topology attribute can cover attributes 12 & 13. But I think the topology attribute is to describe the topology of relays within a cell since that is what 16j has. For attributes 12 & 13, they specifically differentiate the intra-cell and inter-cell cases. Hence, I think attributes 12 & 13 should be kept unless the scope for topology attribute is expanded to both intra-cell and inter-cell.”

• Sydir (Intel) Responded to Kang’s question on clarification on how “cooperative relay” impact sthe architecture. “I believe that attribute 9 cooperative relay has an effect on the network architecture in that cooperative relay requires an MS to have a simultaneous connection to more than one RS at one time.”

• Son (Samsung): Provided explanation for the FDR/HDR attribute. Wondered if some attributes can be seen as a subset of some other attributes, e.g. Cooperative relay could probably cover the V-MIMO attributes.

• Loa (III): Provided clarification for the "RS group" as to how it impacts. "RS group" is defined as a group of relay that an MS connects simultaneously, which has impacts on the hop count definition and relay architecture. His interpretation on the two-hop 16m relay includes both "BS-RS-MS" and BS-RS group-MS" scenarios, which are two distinct relay architectures. He also considers that the RS group is a "16m RS group" to replace "cooperative relay" or "inter-cell/intra-cell virtual MIMO".

• Kolzewski (Huawei): Wanted to add new attributes (MIMO for Fixed Relay Stations, Relay Station Resource Reuse) and provided some reasoning for why these attributes should be added.