16jm Ad Hoc Group Report
IEEE 802.16 Presentation Submission Template (Rev. 9)
Document Number:
IEEE C802.16m-08/242
Date Submitted:
2008-03-17
Source: Ad Hoc Group Chairs
Rakesh Taori
,
Voice:
Samsung Advanced Institute of Technology
E-mail:
Mt. 14-1 Nongseo-Dong, Ginheung Gu, Yongin-si, 446-712, South Korea
+82-31-280-9635
rakesh.taori@samsung.com
Peiying Zhu
Nortel Networks
Source:
Base document
Venue:
.Orlando, Florida (USA)
Base Contribution:
None
Purpose:
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 Chairs
Rakesh 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 on
1. Support of 16j relay station (RS) in 16m
2. 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 discussion
on the issue of
“Support of 16j RS in 16m”
Worth taking the view of the group
Connection Configuration
16MR- BS
16m BS
(O)
(O)
16m RS
(O)
16m MS
X
X
(O)
16j RS
(?)
(O)
16e MS
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
Change proposal to SDD Network Architecture
802.16e
MS
802.16j
RS
802.16m
BS
802.16m
MS
802.16m
RS
802.16m
BS
802.16e
MS
802.16m
BS
802.16m
MS
802.16m
BS
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”
16m Relay Attributes Summary (1/3)
Attribute Title
1
2
Number of Hops
Topology of
Infrastructure
Stations
3
Transparent and NonTransparent RS
4
Centralized and/or
Distributed
scheduling
5
Centralized and/or
Distributed
Control
6
Fixed/Nomadic RS
and/or Mobile RS
7
Centralized and/or
Distributed
security
16j
Attribute (Choices)
Attribute
Summary
≥2 hops
(a) Limit to 2-hops
(b) ≥ 2 hops.
#Responses: 19
#a: 8
#b: 8
#Undecided: 3
Tree
(a) Tree
(b) Mesh.
#Responses: 19
#a: 14 + 5 (5 chose
Both)
#b: 0 + 5 (5 chose
Both)
#Undecided: 0
Both
(a) Non-Transparent RS
only
(b) Support both.
#Responses: 19
#a: 9
#b: 9
#Undecided: 1
Both
(a) Distributed Scheduling
only
(b) Support both.
#Responses: 18
#a: 7
#b: 11
#Undecided: 0
(a) Centralized control only
#Responses: 17
#a: 4
#b: 6
#Undecided: 7
Centralized
(b) Support both.
All
(a) Fixed RS only
(b) Support both.
#Responses: 18
#a: 6
#b: 12
#Undecided: 0
Both
(a) Centralized security
model only
(b) Support Both.
#Responses: 17
#a: 4
#b: 9
#Undecided: 4
16m Relay Attributes Summary (2/3)
Attribute Title
8
9
10
MS Awareness of
Relay
Cooperative Relay
Duplexing Scheme
16j
Attribute (Choices)
Attribute
Summary
Out of scope
(a) Support
(b) Do not Support
#Responses: 18
#a: 15
#b: 0
#Undecided: 3
Supported
(a) Support
(b) Do not Support
#Responses: 18
#a: 15
#b: 2
#Undecided: 1
TDD only?
(a) TDD only
(b) Support TDD and
FDD (including H-FDD
MSs)
#Responses: 18
#a: 0
#b: 17
#Undecided: 1
(a) Support
(b) Do not Support
#Responses: 17
#a: 13
#b: 0
#Undecided: 4
(a) Support
(b) Do not support
#Responses: 17
#a: 6
#b: 8
#Undecided: 3
11
Multicarrier Support
Not Supported
12
Intra-Cell Relay to
Relay direct
communication
13
Inter-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: 5
Not supported
16m Relay Attributes Summary (3/3)
Attribute Title
15
Out-of-band relay
16
MS relaying data for
another MS
17
Support for direct
connection between
MS
18
Intra-Cell Virtual
MIMO using
Cooperative relay
19
Inter-Cell Virtual
MIMO using
Cooperative relay
20
Cooperative relay
utilizing MS relay
21
RS group
16j
Attribute (Choices)
Attribute
Summary
Supported
(a) Support
(b) Do not Support
#Responses: 14
#a: 14
#b: 0
#Undecided: 0
Out of scope
(a) Support
(b) Do not support
(c) For Future Study
#Responses: 15
#a: 3
#b: 5
#Undecided: 7
Out of scope
(a) Support
(b) Do not support
(c) For Future Study
#Responses: 14
#a: 1
#b: 4
#Undecided: 9
Supported
(a) Support
(b) Do not support
#Responses: 15
#a: 14
#b: 1
#Undecided: 0
Not supported
(a) Support
(b) Do not support
#Responses: 14
#a: 8
#b: 4
#Undecided: 2
Out of scope
(a) Support
(b) Do not support
(c) For Future Study
#Responses: 13
#a: 1
#b: 6
#Undecided: 6
(a) Support
(b) Do not Support
#Responses: 12
#a: 8
#b: 3
#Undecided: 1
Supported
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
–
–
–
–
•
Sydir (Intel):
–
–
•
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.
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):
–
–
•
Sun (Toshiba):
–
–
•
•
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 reinvent 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 .
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 “Outof-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 groupMS" 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.