Transcript 80216-09_0023 - IEEE 802 LAN/MAN Standards Committee

IEEE 802.21 MEDIA INDEPENDENT HANDOVER
DCN:21-09-0043-02
Title: Responses to 802.21c PAR comments
Date Submitted: March 11, 2009
Presented at IEEE 802.21 session #31 in Vancouver
Authors or Source(s): James Han, Junghoon Jee, H Anthony Chan
Abstract: Responses to comments received from the different IEEE
802 working groups on the 802.21c PAR and 5C.
21-09-0043-02
1
•
•
•
IEEE 802.21 presentation release statements
This document has been prepared to assist the IEEE 802.21
Working Group. It is offered as a basis for discussion and is not
binding on the contributing individual(s) or organization(s). The
material in this document is subject to change in form and content
after further study. The contributor(s) reserve(s) the right to add,
amend or withdraw material contained herein.
This is a contribution by the National Institute of Standards and
Technology and is not subject to copyright in the US. The
contributors do not have the authority to override the NIST policy
in favor of the IEEE 802.21 policy.
The contributor is familiar with IEEE patent policy, as stated in
Section 6 of the IEEE-SA Standards Board bylaws
<http://standards.ieee.org/guides/bylaws/sect6-7.html#6> and in
Understanding Patent Issues During IEEE Standards
Development http://standards.ieee.org/board/pat/faq.pdf>
21-09-0043-02
2
802.16 Comments (1/1)
The IEEE 802.16 Working Group has reviewed the draft P802.21c PAR and
offers the following comments.
• In general, we appreciate the exemplary quality of this document.
• We do have one concern. Namely, we believe that, with the amendment, the
scope of IEEE Std 802.21 would be expanded enough to make the title of
the standard obsolete. Therefore, we suggest that the PAR propose to
rename IEEE Std 802.21. Our suggestion is the following: “IEEE Media
Independent Handover and Multi-Radio Services.” We believe that this title
would provide for additional future amendments, without a title change,
should interest develop in other multi-radio services.
– We thank you for your comments, which are excellent. There will indeed
be more services which can be built above 802.21 beyond handover such as
multi-radio power management.
21-09-0043-02
3
802.11 Comments (1/4)
General comment:
• If you are managing Watts, then measure Watts.
• Power consumption is not generally available from Radio
interfaces, so it is not meaningful to manage power control
using measurements that are not available. (802.2 LLC does
not expose power consumption).
– Each technology defines its own power saving mechanisms to
reduce its own power consumption. MRPM will not change the
power saving mechanisms defined by that technology.
Therefore, MRPM’s approach is based on existing power
saving modes and does not need to measure Watts. MRPM will
provide the mechanism to manage and coordinate multi-radios
in the device and their networks to save power.
21-09-0043-02
4
802.11 Comments (2/4)
Multiple Radio Power Management does not belong in 802.21.
• Handover control is not the same as Power management.
– We think that 802.16’s comments, “Our suggestion is the
following: “IEEE Media Independent Handover and MultiRadio Services. We believe that this title would provide for
additional future amendments” are excellent and as a matter of
fact, there will be more services which can be built above
802.21 beyond handover such as multi-radio power
management.
• 802 EC agreed to create this study group with the
objective to create PAR and 5C in 802.21.
21-09-0043-02
5
802.11 Comments (3/4)
Power management in a client is truly an implementation issue
not a standardization issue
– We do not eliminate the ability of the client to manage power.
MRPM extends this ability through network support of
additional power saving options.
– Current standards have defined various power saving modes for
power management. Without such standards, the network and
the device from different vendors cannot achieve today’s talk
time and standby time. MRPM is built above these power
saving modes in their respective standards to coordinate and
manage multi-radio power.
21-09-0043-02
6
802.11 Comments (4/4)
The 5C provide insufficient justification for starting this project.
– We have added the following to section 17.5.1a Multiple
vendors and numerous users in the revised 5C: “Multi-radio
devices have already experienced battery life problems.”
– In addition, the need for the project is in Section 5.5 of the
PAR.
21-09-0043-02
7
Andrew Myles’ Comments (1/4)
The stated objective for the PAR is as follows:
"The purpose of this amendment is to enhance the user
experience by extending the battery operating life of multi-radio
mobile devices"
In reading the PAR/5C (in particular Clause 5.5 & Clause
17.5.4) the text suggests that the power improvement only
applies to multi-radio devices while only 1 radio is active.
The problem with focusing on saving power by choosing 1
radio over another is that it implies that the device may only
use 1 radio at a time for all applications running on the dual
mode device.
Several points are worth raising about this issue:
21-09-0043-02
8
Andrew Myles’ Comments (2/4)
• Comment 1: * Many dual radio devices operate today with both
radios active. Saving power while BOTH radios are active is a
major concern. However, this PAR ignores this use case by
suggesting that the solution to the power save problem is to
deactivate or disable the secondary radio. The PAR should not
suggest a solution to the dual-radio device power save problem
is to deactivate the secondary radio.
– We agree and the 4th paragraph in section 17.5.4 has been
amended into: Radios that are not in service in a mobile multiradio device may be turned off or put into a lower power state.
Should traffic be sent to one of the turned off radios then it is
desirable that the mobile client be notified of that traffic on an
active radio. Upon such notification, the mobile client may turn
on the target radio.
21-09-0043-02
9
Andrew Myles’ Comments (3/4)
• The proposed PAR suggests having the .21 "system" enable a
mechanism to switch between radios rather than enabling both
radios at the same time. It would seem that the .21 is forcing
itself into the data path of applications to ensure only one radio
is active at a time. It is not clear that this is practical and
scalable. The PAR needs to focus on saving power without
requiring devices switching between radios coordinated by the
.21 system. The PAR also suggests that the .21 will become the
entity that chooses the "right" network/radio. This is
inappropriate for a IEEE technology to create such a system.
– The MRPM is not an entity to choose the right network itself.
MRPM will define mechanisms for multi-radio power
management and coordination. The defined mechanisms can be
utilized by a network selection entity in choosing the right
network.
21-09-0043-02
10
Andrew Myles’ Comments (4/4)
• It is not clear how a .21 system knows what is the best power
saving option for each radio technology so in a practical sense
what
terms are defined in the PAR for saving power other than
shutting down radios?
• MRPM coordinates and manages multi-radio power management through
network support. It turns unused radios into lower power states. It enables an
off radio to be awakened through a different radio.
• It is not clear that the PAR is focused on the right problem to
saving power with dual radios active.
– We already answered that more than one radios may be in
service. However MRPM cannot provide power saving if all
radios need to be in service.
21-09-0043-02
11
Peter Ecclesine’s Comments (1/18)
Comments to section 8.1
• PAR language 8.1: “2. Enable the optimal power configuration
of different radios in a multi-radio mobile device: whether
radio is “on,” “off-available,” or “off-do-not-disturb.”
• Comments: There are more variations on power saving than
these three “configurations”, none of which are “optimal”.
– We thank you for your comment and have revised the above
sentence into:
– 2. Enable the power configuration of different radios in a multiradio mobile device to reduce power consumption: whether
radio is “on,” “off-available,” “off-do-not-disturb,” or in other
states.
21-09-0043-02
12
Peter Ecclesine’s Comments (2/18)
Comments to section 8.1
• PAR language 8.1: “3. Enable power management through coordination across multiple networks of different radios, taking
into account the power management functions in individual
radios and networks and QoS requirements.”
• Comments: You cannot put license-exempt bands in the same
power regime as licensed bands, as the reliability of
management communication is vastly different. Changing the
radio’s modulation and coding scheme has as large an effect on
power consumption as changing sleep strategy.
– We are not trying to change the existing modulations and
coding schemes. Our purpose is to manage and coordinate the
multi-radio device (either radios in licensed-exempt bands or
licensed bands) to reduce power consumption
21-09-0043-02
13
Peter Ecclesine’s Comments (3/18)
Comments to section 8.1
• PAR language 8.1: “3.1 Keep an energy efficient radio “on”
for receiving notification of incoming service.”
• Comments: not just energy efficient, but also able to receive
and communicate reliably. One also needs to know the power
consumption per service per radio in order to choose among
radios for a requested service.
– The optimization goal can include reliability and power
consumption or their weighted combinations. We revise this
sentence in section 8.1 to:
– 3.1 Keep an energy efficient and reliable radio “on” for receiving
notification of incoming service.
21-09-0043-02
14
Peter Ecclesine’s Comments (4/18)
Comments to section 8.1
• PAR language 8.1: “4. Reduce or avoid futile
scanning by unused radios.”
• Comments: Psychic management of the unused radios
in accord with the known traffic is not a formula for
success with bursty traffic. Scanning usually refers to
available channels, not traffic streams.
– We agree and have revised into:
– “4. Reduce or avoid futile scanning in out-of-coverage
areas.”
21-09-0043-02
15
Peter Ecclesine’s Comments (5/18)
Comments to section 17.5.1 Broad Market Potential
• 5C language a) Broad sets of applicability: “One major bottleneck in the
implementation of multi-mode terminals for any application area is the
overall power management mechanism for different radios, each with its
own mechanism. We expect multi-radio devices to depend on 802.21
services that should be extended to improve the power efficiency of multiradio mobile devices.”
• Comments: Power management mechanisms are specific to device types and
services, not radio interfaces. The claim than an 802.21 API would allow
better power management than current schemes is not supported by any
reference in these 5C.
– Power management includes many aspects, such as, radio communication,
display, services, background light, etc. The power management of multiradio device investigated here focuses on multiple radio communication
issues. It will reduce the power consumption caused by multiple radios’
communication.
21-09-0043-02
16
Peter Ecclesine’s Comments (6/18)
Comments to section 17.5.1 Broad Market Potential
• 5C language c) Balanced costs (LAN versus attached stations).: “Multiradio equipment is accepted as having balanced costs. The addition of multiradio power management capabilities will not increase the costs of devices
significantly.”
• Comments: It would increase the message traffic between radio types,
without proven benefit.
– The control signaling traffic will increase slightly for the specific radio. The
gain is in power consumption reduction in the other radios. There are
published papers showing the net gain such as.
• Shih, E., Bahl P., and Sinclair, M.J., “Wake on Wireless: an event driven energy
saving strategy for battery operated devices,” in Proc. ACM Int. Conf. Mobile
Computing and Networking, 2002.
• Agarwal, Y., Schurgers C., and Gupta R., “Dynamic Power Management using On
Demand Paging for Networked Embedded Systems,” in Proc. of Asia-South Pacific
Design Automation Conference (ASPDAC), 2005.
21-09-0043-02
17
Peter Ecclesine’s Comments (7/18)
Comments to section 17.5.2 Compatibility
• 5C language: “Consideration will be made to ensure
compatibility with the IEEE 802.21 and IEEE 802 wireless
architectural models.”
• Comments: The IEEE 802 O&A does not provide management
plane standardization for power consumption. Name the IEEE
802 radio standards that expose power consumption
measurands today, and relates those measurands to traffic
streams.
– As mentioned before, MRPM will not change the power saving
mechanisms defined by each individual radio technology and its
approach is based on existing power saving modes. MRPM
does not need to do power measurements.
21-09-0043-02
18
Peter Ecclesine’s Comments (8/18)
Comments to section 17.5.4 Technical Feasibility
• 5C language: “The ability to save power has been proven in various
wireless access technologies such as IEEE 802.11 power saving mode, IEEE
802.16e idle mode and sleep mode, and cellular power saving modes in
3GPP/2.”
• Comments: No two are the same, and each trades latency for power saving.
There is nothing in the management interfaces of 802.11 that reveal the
power consumed in transmission, in frame reception, in idle or in sleeping.
Regardless of 802.21’s technical algorithms, no power consumption
measurand input equals a psychic management scheme..
– It is true that no two are the same. This is the reason why we need MRPM to
manage and coordinate multiple radios to reduce the power consumption.
The measurements are not the necessary condition for power reduction
approach in MRPM. Each technology already worked out the relative power
consumption for various power saving modes. The MRPM can use these
information to develop efficient power saving approaches.
21-09-0043-02
19
Peter Ecclesine’s Comments (9/18)
Comments to section 17.5.4 Technical Feasibility
• 5C language: “The ability to locate and page a single-radio
mobile device in dormant mode is also a proven and tested
technology in various networks such as 3GPP/2.”
• Comments: This observation has nothing to do with the
technical feasibility of multi-radio power management of
unlicensed band radios, which do no paging.
– It is true that there is no paging in unlicensed band radios. But
there are power-saving modes: such as PS mode and extended
PS mode. The MRPM does not only deal with radios with
paging, but also deal with unlicensed-band radios without
paging.
21-09-0043-02
20
Peter Ecclesine’s Comments (10/18)
Comments to section 17.5.4 Technical Feasibility
• 5C language: “Methods of coordinating the operating modes of multiple
independent radio interfaces as well as comparing the relative energy
consumption of those radio interfaces can be defined as extensions of IEEE
802.21 which is an extensible protocol and which supports multiple radio
interfaces.”
• Comments: 802.21 is not chartered to define power consumption metrics for
streams in radios defined in other standards, nor to request interfaces that
provide that information, nor to control power consumption. Without
changing the management interfaces of unlicensed radios, no methods of
power consumption coordination are technically feasible.
– The power consumption measurements are not a necessary condition for
MRPM as mentioned before.
21-09-0043-02
21
Peter Ecclesine’s Comments (11/18)
Comments to section 17.5.4 Technical Feasibility
• 5C language: “All but one radio in a mobile multi-radio device may be turned off to
save power. Should traffic be sent to one of the turned off radios then it is desirable
that the mobile client be notified of that traffic on its active radio. Upon such
notification, the mobile client may either turn on the target radio or route the traffic
over the currently active interface. The correct choice depends on the anticipated
traffic, the performance characteristics of the radios, and on a policy. Regardless, an
MRPM entity must coordinate with an entity in each radio’s network in order to
update its routing information to reflect the current interface power modes. This
operation is similar to the Mobile IP routing update normally required by mobile
nodes. Mobile IP is an established routing protocol and a similar update mechanism
and demonstrates the feasibility of this approach.”
• Comments: This observation ignores the cost of maintaining and communicating
traffic over each of the radios, as all but one may be turned off. This text does not
acknowledge the fact that multi-radio power management costs more energy to
perform than single radio power management does. Balancing traffic among
sleeping radios is not technically feasible without changing the management
interfaces of unlicensed radios.
 (Response in next slide)
21-09-0043-02
22
Peter Ecclesine’s Comments (12/18)
– The specific radio traffic will increase slightly for the other
radios due to the small amount of control signaling. However,
we can expect more gain in power consumption reduction.
• MRPM needs to know the power saving status of unlicensed
radios but does not need to change the management interface.
21-09-0043-02
23
Peter Ecclesine’s Comments (13/18)
Comments to section 17.5.4 Technical Feasibility
• 5C language: “IEEE 802.11 supports a power saving mode that is effective when
confronted with isochronous traffic flows. “Always on” applications and bulk data
transfers reduce the effectiveness of the 802.11 power save mechanism. Because of
its high data rates, 802.11 is also an economical choice when a host needs to
transfer large volumes of data. These observations have been noted in the literature
with several suggestions that a cross-layer power savings can be obtained by
intermittently running the radio interface at full speed and otherwise leaving it
turned off. Access network entities such as Intermediate-TCP have been proposed to
facilitate this sort of periodic power operation and their effectiveness has been
demonstrated in actual implementations.”
• Comments: This observation is a judgment, as some want two-second sleep time to
be supported by access points. There is no provision in the 802.11 standard for
access points to start isochronous traffic flows for sleeping stations. This operation is
not technically feasible without changing the management interfaces of unlicensed
radios.
 (Response in next slide)
21-09-0043-02
24
Peter Ecclesine’s Comments (14/18)
 We agree with your comment and have deleted this paragraph.
21-09-0043-02
25
Peter Ecclesine’s Comments (15/18)
Comments to section 17.5.4 Technical Feasibility
• 5C language: “There may be a tradeoff between the service availability of always-on
connectivity and battery life. Yet existing platform- and network-specific power
managers that operate independently without considering the overall power
consumption of a multi-radio mobile device may result in shortened battery
operation life, which according to user experience is contradictory to a reliable
service. This project to enhance battery life is trying to enhance such user
experience. In addition, no specific new hardware technology is introduced, so
hardware reliability should not be an issue.”
• Comments: 802.21 has not provided anything that shows a general power
management algorithm would work as well as those currently employed by
manufacturers of multi-radio devices. Until 802.21 posts some white paper or
analysis that shows what improvement is possible, the technical feasibility is
unknown.
 (Response in next slide)
21-09-0043-02
26
Peter Ecclesine’s Comments (16/18)
 Currently multi-radio devices have already experienced battery life problem
and are using proprietary protocol to solve the problem.
 802.21 provides Information service, event service, and command service
for heterogeneous networks. MRPM coordinates and manages multi-radio
power using these services.
21-09-0043-02
27
Peter Ecclesine’s Comments (17/18)
Comments to section 17.5.5 Economic Feasibility
• 5C language: “Sections of this work simply represent an incremental cost in
enhancing the baseline implementation of IEEE 802.21. Additional costs will be
incurred owing to facilitating network coordination. Where coordination with core
network entities is required, the capital and operational costs should be similar to
that of installing Mobile IP servers. Where coordination between the mobile device
and access network is required, the capital and operational costs will be similar to
that of installing an operating system utility at an access point.”
• Comments: These statements do not account for the operating costs of
communicating power consumption to an 802.21 management mechanism, and
taking direction from it. By definition, such traffic is in addition to normal operation.
 First, the amount of traffics and messages are relatively very small in addition to
normal operation. Second, the extra power consumption related to the additional
traffics and messages is much less than the power consumption to make the extra
radio “on”.
21-09-0043-02
28
Peter Ecclesine’s Comments (18/18)
Comments to section 17.5.5 Economic Feasibility
• 5C language: “IEEE 802.21 is uniquely positioned to provide a coordinating role in
radio power management. IEEE 802.21 already provides a uniform set of services
that work across heterogeneous networks. ”
• Comments: 802.21 required the 802.11u amendment to create new elements in the
802.11 MAC and expose them to 802.21. This PAR does not provide energy
management hooks in 802.11 at all, and without them, this PAR does not provide any
value to 802.11.
– The power consumption measurements are not a necessary condition for MRPM as
mentioned before. The energy management hooks in 802.11 are not needed. The
MRPM manages and coordinate multiple radios to achieve the reduction of power
consumption. It does not try to reduce power consumption within 802.11. Therefore,
the power measurements within 802.11 are not necessary.
21-09-0043-02
29