Re: [STDS-802-16] [MMR-AH-UM] Announcing 6/1/06 Meeting of MultihopRelay Usage Model Ad Hoc Group
Dear "J" and all,
I agree that this sentence may be problematic. We discussed changing it
in the last meeting, and one of the suggestions we discussed was to
remove it. I'm OK to remove it if the rest of the group agrees. I'll put
this on the agenda for our discussion tomorrow.
Jerry
-----Original Message-----
From: J Kim [mailto:macsbug@RESEARCH.ATT.COM]
Sent: Wednesday, June 21, 2006 8:02 AM
To: STDS-802-16@listserv.ieee.org
Subject: Re: [STDS-802-16] [MMR-AH-UM] Announcing 6/1/06 Meeting of
MultihopRelay Usage Model Ad Hoc Group
In light of the discussions so far (assuming I follow them well enough),
I suggest removing
"It should be noted that even when multiple routes are enabled between
the RSs, the overall topology is still tree-like because all data
communications are between the MMR-BS and MSs and this usage does not
violate the scope as defined in the 802.16j PAR."
From Section 5.3 in the C80216j-06_UMAHtemp_r4.doc.
As far as 16j is concerned, a language explicitly prohibiting
non-tree-like data path and MS-RS-MS, MS-BS-MS (and any combinations
like that) is also out of scope.
16J may work on only tree-like data paths that come back all to BS (if
proposals happen to cover only that), but prohibiting others would go
too far.
I don't agree 16J PAR in fact prohibits such.
For example, those interested in RS in bus or train may not be too keen
to the idea that all traffic inside a bus or train (gaming or what not)
has to come back out to some BS and go back in.
Bests.
"J" Kim
-----Original Message-----
From: Phillip Barber [mailto:pbarber@BROADBANDMOBILETECH.COM]
Sent: Saturday, June 03, 2006 12:43 PM
To: STDS-802-16@listserv.ieee.org
Subject: Re: [MMR-AH-UM] Announcing 6/1/06 Meeting of MultihopRelay
Usage Model Ad Hoc Group
802.16k is a bridging conformance amendment to 802.1D. It is just
putting
conformance language specifying how 802.16 adheres to the 802.1D
bridging
standard. As such, it defines conformance at the Convergence Sublayer of
the
MAC.
It should be possible for a BS to bridge the flow between two MS on the
same
access network provided there is a discovered path between them
(discovery
and spanning tree). May be somewhat constrained by network design (i.e.
if
L2 packets are tunneled from the BS to another network entity like a
gateway, for data path processing, then the gateway would have to be the
host for bridging, not the BS). Note that this requires classification
of
the flows in the Convergence Sublayer. Even for two MS serviced by the
same
BS, communication will have to process through the Convergence Sublayer
and
out of the CS-SAP so that they can be appropriately attributed to a L2
bridge or L3 address.
Thanks,
Phillip Barber
Chief Scientist
Broadband Wireless Solutions
Huawei Technologies Co., LTD.
----- Original Message -----
From: "Guo-Qiang Wang" <guoqiang@NORTEL.COM>
To: <STDS-802-16@listserv.ieee.org>
Sent: Saturday, June 03, 2006 11:09 AM
Subject: Re: [STDS-802-16] [MMR-AH-UM] Announcing 6/1/06 Meeting of
MultihopRelay Usage Model Ad Hoc Group
> Actually 802.16k is working on bridging of 802.16 at MAC layer, which
> would bridge
> two MS via BS. But my understanding is .16k bridging function is at
> convergence sublayer,
> not at CID connection layer.
> Regards,
> G.Q, Wang
>
> -----Original Message-----
> From: Sydir, Jerry [mailto:jerry.sydir@INTEL.COM]
> Sent: Friday, June 02, 2006 9:12 PM
> To: STDS-802-16@listserv.ieee.org
> Subject: Re: [STDS-802-16] [MMR-AH-UM] Announcing 6/1/06 Meeting of
> MultihopRelay Usage Model Ad Hoc Group
>
>
> Byoung-Jo,
>
> In 802.16e MS-BS-MS communication is out of the scope of the standard
> because the standard defines only the link between BS and MS. If MS1
> wants to communicate with MS2 there is a bridging or routing function
> that causes data from MS1 to be sent to MS2. If the two MSs are
> connected to the same BS, that bridging or routing function may be
> implemented within the BS (within the same box), but it is not
specified
> by 802.16e and from the perspective of 802.16e there are two
independent
> connections, one between the BS and MS1 and one between the BS and
MS2.
>
> My understanding is that the purpose of 16j is to define a relay
> function for relaying data between BS and MS. Connections span from
the
> BS to the MS through zero or more RSs. MS to MS connections go
> MS-RS-BS-bridging_routing_function-BS-RS-MS. I agree that this is not
> explicitly stated in the cryptic PAR text.
>
> Regards,
> Jerry Sydir
>
> -----Original Message-----
> From: macsbug@research.att.com [mailto:macsbug@research.att.com]
> Sent: Thursday, June 01, 2006 6:41 AM
> To: Sydir, Jerry; STDS-802-16@listserv.ieee.org
> Subject: RE: [MMR-AH-UM] Announcing 6/1/06 Meeting of MultihopRelay
> Usage Model Ad Hoc Group
>
> May I offer a slightly different interpretation.
>
> I don't read "Subscriber station specifications are not changed." as
> excluding MS2MS via RS, since for MS, RS would look like BS for MS
does
> not operate differently for RS per PAR.
>
> Thus, MS-RS-MS would not look any different from MS-BS-MS or
> MS-RS-BS-MS, etc..
>
> Undoubtedly, MS to MS direct communication is not in scope.
>
> I would have preferred some sort of backward support clause for
> RS-unaware MS, instead of "Subscriber station specifications are not
> changed.", but of course, the PAR is fixed now. However, we need not
> voluntarily restrict the scope even further beyond the text of PAR.
>
> Bests.
>
> Byoung-Jo "J" Kim
>
> -----Original Message-----
> From: Sydir, Jerry [mailto:jerry.sydir@INTEL.COM]
> Sent: Wednesday, May 31, 2006 8:58 PM
> To: STDS-802-16@listserv.ieee.org
> Subject: Re: [MMR-AH-UM] Announcing 6/1/06 Meeting of MultihopRelay
> Usage Model Ad Hoc Group
>
> Peng-Yong,
>
> This is the text for section 13 of the PAR:
>
> 13. Scope of Proposed Project:
> This document specifies OFDMA physical layer and medium access control
> layer enhancements to IEEE Std 802.16 for licensed bands to enable the
> operation of relay stations. Subscriber station specifications are not
> changed.
>
> My understanding is that this rules out MS to MS communications
whether
> direct or through an RS.
>
> Regards,
> Jerry
>
> -----Original Message-----
> From: Peng-Yong Kong [mailto:kongpy@I2R.A-STAR.EDU.SG]
> Sent: Tuesday, May 30, 2006 7:18 PM
> To: STDS-802-16@listserv.ieee.org
> Subject: Re: [STDS-802-16] [MMR-AH-UM] Announcing 6/1/06 Meeting of
> MultihopRelay Usage Model Ad Hoc Group
>
> Dear Jerry,
> Could you please point me to the part of 802.16j PAR that prevents
> peer-to-peer? I think peer-to-peer is probably also possible in a PMP
> network.
>
> rgds,
> Peng-Yong Kong
>
> -----Original Message-----
> From: Sydir, Jerry [mailto:jerry.sydir@INTEL.COM]
> Sent: Wednesday, May 31, 2006 9:37 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
>
>
> Dear Peng-Yong,
>
> Thanks for reviewing and commenting on the current draft. I've entered
> some responses inline (prefaced with [JJS]).
>
> Regards,
> Jerry Sydir
>
> -----Original Message-----
> From: Peng-Yong Kong [mailto:kongpy@i2r.a-star.edu.sg]
> Sent: Tuesday, May 30, 2006 3:44 AM
> To: Sydir, Jerry; 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
>
>
> Dear Jerry & all,
> I have some comments:
> 1) In section 3, the current text is "... to provide coverage
extension
> at the edge of the cell, to provide sufficient link budget for indoor
> penetration, to provide coverage to users in coverage holes that exist
> due to shadowing and in valleys between buildings, to provide access
to
> mobile users, and to provide access to clusters of users outside the
> coverage area of the BS". I suggest to add "... to provide temporary
> coverage extension and/or capacity improvement".
>
> [JJS]
> [JJS] I agree that the text that introduces the figure needs to be
made
> complete. (We also need to update the figure).
>
> 2) Is there a difference between usage model and usage scenario? One
may
> describe the following usage scenario: "David is at home and fell
> boring. He decides to go to the downtown for the New Year Party where
> many people dance on the street. He does not want to drive and thus
> takes the subway. He dances for a while before receiving a text
message
> on phone that a friend is inviting him to a pub on nearby street.
David
> leaves the part and go to the pub". From the scenario, we may then
> decide the technical challenges. For example, we may want the subway
> train be covered by a RS. So as the party area be covered by some RSes
> each forming a hotspot. Then, we know the need of handover between
> RS-and-BS, RS-RS, BS-BS. In the case of David receiving a text message
> in a hotspot, we may consider if we want the text to arrive via BS or
> peer-to-peer.
>
> [JJS] In general a usage scenario is more specific than a model. A
usage
> model should encompass multiple specific usage scenarios. We probably
> don't want to describe all such scenarios, but we do want to capture
> major usage models. I think that the scenario that you describe points
> out one thing that is currently not explicitly mentioned in the
> document. In your scenario, the user receives coverage while moving
from
> indoor coverage to coverage on a mobile platform, to temporary
coverage
> (at the party).
>
> 3) In section 3.4, should we not limit to 2 hops while 3.1 to 3.3 can
> have more than 2 hops?
>
> [JJS] I tried to capture the information from session 43 contributions
> without changing it. This limit was specified in the contribution from
> which I drew the model. We should discuss whether this is a consensus
> position.
>
> 4) Let peer-to-peer be defined as communication between two MS without
> going through BS and this communications may or may not be across
> multiple hops. Should we consider supporting peer-to-peer in dot-16j?
>
> [JJS] I believe that this is out of the scope of the PAR for 802.16j.
> [JJS]
>
> rgds,
> Peng-Yong Kong
>
> -----Original Message-----
> From: Sydir, Jerry [mailto:jerry.sydir@INTEL.COM]
> Sent: Sunday, May 28, 2006 1: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
>
>
> ------------ Institute For Infocomm Research - Disclaimer
-------------
> This email is confidential and may be privileged. If you are not the
> intended recipient, please delete it and notify us immediately. Please
> do not copy or use it for any purpose, or disclose its contents to any
> other person. Thank you.
> --------------------------------------------------------