Re: [STDS-802-16] [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.
> --------------------------------------------------------