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