Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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