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