GRIDMAN Teleconference Minutes
12 August 2010
GRIDMAN Task Group Chair – Tim Godfrey (EPRI)
Agenda – complete acceptance review of SRS baseline doc 80216gman-0024r1 – review and accept
contributions into document
1. Contributions from Interdigital, Samsung
2. Arthur and Eldad’s text for Services section (5.3).
3. We still need to process (review and accept from merging) these sections in baseline SRD:
Section 1 - this text for the Overview section has not been accepted into the baseline
Section 3 - two proposed changes to the definitions have not been accepted into the
baseline
Section 6.5 and 6.6 have not been discussed and accepted.
Attendees
Tim Godfrey - EPRI
Youngbin Chang – Samsung
K Kim - Samsung
Jack - Samsung
Eldad Ziera - Interdigital
SungCheol Chang - ETRI
Haiguang Wang - I2R
Arthur Wang - LinQuest
Contribution C80216gman-10_0030.ppt by Eldad Ziera
Proposes the adoption of the name “HR-MMD: High Reliability Multi-Mode Device” to designate
the new type of device that that can change mode dynamically. Normal state is HR-MS. Not all
HR-MS need to be HR-MMD.
HR-MMS may have limited capacity, compared to normal BS. A MS would not know the HRMMS is not a normal BS or RS. There may be additional functionality (related to the
transitioning behavior, local source and sink, etc).
Youngbin would prefer the term HR-MMD be changed to something with “mobile” in
the name.
Suncheol proposes just adding M for multimode in the existing definitions instead of
defining a new term. Eldad is OK with that, and he will make the appropriate text
proposal.
Terminology related to link existence – defines DC-HR-MS for “direct communicating HR-MS”.
Does this mean the DC-HR-MS has a different connection type than the normal HR-MS
to HR-BS or HR-RS connection. Not every device has the DC capability. This DC capability
is not a full base station at all. I.E.
The baseline case for DC is a collection of HR-MS devices that only communicate among
themselves and there is never a BS or RS. The DC air interface is not backward
compatible to a BS or RS air interface. It is only supported by HR devices with the DC
connectivity function implemented. Some consider this is a “walkie talkie” function, but
it can be more than that.
The DC function can extend coverage to provide a higher reliability – maybe an order of
magnitude.
Not all HR-MS have to implement DC capability.
Arthur says DC is a unique connectivity service, but it doesn’t have to be tied to a
specific device type. When an HR-MS is operating in DC mode, does it get a new name
or just call it a mode. We agree that we call the DC functionality a mode. It is not a
unique device type. We are not trying to form a new type of mesh network independent
of existing 802.16 air interface specifications. The only case for non-BS operation is in
case of disruption.
Contribution C80216gman-10_0031.doc - Samsung
Discussion on 6.2.3 changes remving the first line of “VoIP service” leaving only the line with
Emergency Calls. Everyone is OK with that change.
Tim asks if there is any objection to accepting this document. We have unanimous approval to
accept this contribution and apply to the SRD.
Arthur asks about the term PTT – is it meant to be only a voice service – does it need to be
generalized to a term like “half duplex services”. PTT came from Open Mobile Alliance. The
OMA idea is that PTT already encompasses all data services as well as voice.
Discussion on Services paragraph (5.3)
Arthur was assigned to provide draft text for the Services section along with input from Eldad.
Proposed Text from Arthur and Eldad:
IEEE 802.16n should support services that require a higher degree of assurance of
maintaining sufficient connectivity than can be provided by IEEE 802.16 legacy systems.
Examples of such services can be found in PPDR (Public Protection and Disaster
Recovery) and M2M (Machine to Machine) communication networks for utility
monitoring and control.
This text is accepted into the SRD for section 5.3
Arthur says this does not specify or constrain, but just gives the idea to give the picture for
interpreting the SRD.
Conclusion:
We are considering a GRIDMAN ad-hoc in September prior to session #69 (Sunday afternoon or
Monday morning) to continue refining the baseline SRD. Our preference is Monday AM, but we
will need to verify room availability, etc. We are not making a decision today, but we want
people to consider this as they make their travel plans.
SRD baseline after today’s edits have been uploaded as 80216gman-10_0024r2.doc
Teleconference is adjourned