U.S. patent application number 11/388888 was filed with the patent office on 2006-10-26 for defragmentation of communication channel allocations.
This patent application is currently assigned to Olympus Communication Technology of America, Inc.. Invention is credited to Stanislaw Czaja, Ghobad Heidari-Bateni.
Application Number | 20060239272 11/388888 |
Document ID | / |
Family ID | 36763738 |
Filed Date | 2006-10-26 |
United States Patent
Application |
20060239272 |
Kind Code |
A1 |
Heidari-Bateni; Ghobad ; et
al. |
October 26, 2006 |
Defragmentation of communication channel allocations
Abstract
Approaches scheduling and allocation of communication bandwidth
across a communication channel provide the opportunity for improved
network utilization. According to one embodiment, a method of
allocating communication bandwidth among a plurality of network
devices scheduling and conducting communication activities within
the communication network in a communication network is provided.
The method comprises the steps of: a first network device
determining allocations of other network devices operating in the
communication network; the first network device preempting a
scheduled allocation of a second network device; and the first
network device scheduling its communication activities on the
communication network. Additionally, the first network device can
also determine whether a conflict exists between its desired or
required allocation and an allocation of the second network
device.
Inventors: |
Heidari-Bateni; Ghobad; (San
Diego, CA) ; Czaja; Stanislaw; (Cardiff, CA) |
Correspondence
Address: |
MORRISON & FOERSTER LLP
12531 HIGH BLUFF DRIVE
SUITE 100
SAN DIEGO
CA
92130-2040
US
|
Assignee: |
Olympus Communication Technology of
America, Inc.
San Diego
CA
|
Family ID: |
36763738 |
Appl. No.: |
11/388888 |
Filed: |
March 23, 2006 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60715220 |
Sep 7, 2005 |
|
|
|
60675296 |
Apr 26, 2005 |
|
|
|
60674806 |
Apr 25, 2005 |
|
|
|
60673836 |
Apr 22, 2005 |
|
|
|
Current U.S.
Class: |
370/395.21 ;
370/431 |
Current CPC
Class: |
H04W 28/06 20130101;
H04W 28/20 20130101; H04W 72/00 20130101; H04W 74/04 20130101; H04N
21/64738 20130101; H04W 72/1247 20130101; H04W 72/0453 20130101;
H04N 21/238 20130101 |
Class at
Publication: |
370/395.21 ;
370/431 |
International
Class: |
H04L 12/56 20060101
H04L012/56 |
Claims
1. A method of allocating communication bandwidth among a plurality
of network devices scheduling and conducting communication
activities within the communication network in a communication
network, the method comprising the steps of: a first network device
determining allocations of other network devices operating in the
communication network; the first network device preempting a
scheduled allocation of a second network device; and the first
network device scheduling its communication activities on the
communication network.
2. The method of claim 1, further comprising the step of the first
network device determining whether a conflict exists between its
desired or required allocation and an allocation of the second
network device.
3. The method of claim 1, wherein the scheduled allocation of the
second network device that is preempted by the first network device
comprises one or more network time or channel slots.
4. The method of claim 1, wherein the step of preempting comprises
the step of adjusting a threshold to provide increased bandwidth
availability to the first network device.
5. The method of claim 1, wherein the step of preempting comprises
the steps of: the first network device informing the second network
device of the preemption and of its scheduling requirement; and the
second network device reallocating its bandwidth in a manner that
does not conflict with the first network device.
6. The method of claim 1, wherein the step of preempting comprises
the steps of: the first network device informing the second network
device of its scheduling requirement; and the second network device
determining whether its own scheduling requirement is in conflict
with the first network device.
7. The method of claim 6 further comprising the step of the second
network device reallocating its bandwidth in a manner that does not
conflict with the first network device.
8. The method of claim 1, wherein the step of preempting comprises
the step of causing the second network device to reallocate some or
all of its scheduled bandwidth to a different communication window
or channel.
9. The method of claim 1, further comprising the steps of
determining a relative priority of the network devices and further
determining whether a given network device can preempt another
network device based on the relative priority.
10. A network device configured to operate within a communication
network, the network device comprising: a housing; at least one of
a transmitter and receiver in the housing; and control logic within
the housing and configured to schedule communication activities
across the communication network, determine allocations of other
network devices operating in the communication network, and preempt
a scheduled allocation of a second network device that is in
conflict with the allocation of the network device.
11. The network device of claim 10, wherein the control logic is
further configured to determine whether a conflict exists between
its desired or required allocation and an allocation of the second
network device.
12. The network device of claim 10, wherein the control logic
comprises at least one of hardware, software and firmware.
13. The network device of claim 10, wherein the allocation of the
second network device that is preempted by the first network device
comprises one or more network time or channel slots.
14. The network device of claim 10, wherein the control logic is
further configured to adjust a threshold to provide increased
bandwidth availability to the first network device.
15. The network device of claim 10, wherein the control logic is
further configured to communicate the network device's scheduling
requirement to other network devices, and to reallocate the network
device's allocation in response to a request for preemption from
another network device.
16. The network device of claim 10, wherein the control logic is
further configured to communicate the network device's scheduling
requirement to another network device, and wherein the other
network device is configured to determine whether its own
scheduling requirement is in conflict with the first network
device.
17. The network device of claim 10, wherein the control logic is
further configured to reallocate some or all of the network
device's scheduled bandwidth to a different communication window or
channel.
18. The network device of claim 10, wherein the control logic is
further configured to determine a relative priority of the network
device with respect to other network devices and to determine
whether the network device can preempt another network device based
on the relative priority.
19. An executable program product including a body of program code
executable by a processor for dynamically allocating the bandwidth
utilization of a first network device, the executable program
product comprising: program code for determining allocations of
other network devices operating in the communication network;
program code for preempting a scheduled allocation of a second
network device that is in conflict with the allocation of the first
network device; and program code for scheduling communication
activities of the first network device on the communication
network.
20. The program product of claim 19, further comprising the step of
the first network device determining whether a conflict exists
between its desired or required allocation and an allocation of the
second network device.
21. The program product of claim 19, wherein the scheduled
allocation of the second network device that is preempted by the
first network device comprises one or more network time or channel
slots.
22. The program product of claim 19, wherein the program code for
preempting comprises program code for adjusting a threshold to
provide increased bandwidth availability to the first network
device.
23. The program product of claim 19, wherein the program code for
preempting comprises program code for informing the second network
device of the preemption and of its scheduling requirement; whereby
the second network device reallocates its bandwidth in a manner
that does not conflict with the first network device.
24. The program product of claim 19, wherein the program code for
preempting comprises program code for informing the second network
device of its scheduling requirement; whereby the second network
device reallocates its bandwidth in a manner that does not conflict
with the first network device.
25. The program product of claim 19, wherein the program code for
preempting comprises program code for causing the second network
device to reallocate some or all of its scheduled bandwidth to a
different communication window or channel.
26. The program product of claim 19, further comprising program
code for determining a relative priority of the network devices and
further determining whether a given network device can preempt
another network device based on the relative priority.
Description
CROSS REFERENCE To RELATED APPLICATIONS
[0001] This application claims priority to the following U.S.
patent provisional applications Ser. No. 60/715, 220, filed on Sep.
7, 2005; Ser. No. 60/675,296, filed on Apr. 26, 2005; Ser. No.
60/674,806, filed on Apr. 25, 2005; and Ser. No. 60/673,836, filed
on Apr. 22, 2005, the disclosures of which are herein incorporated
by reference in their entirety.
FIELD OF THE INVENTION
[0002] The present invention relates generally to communication
channels, and more particularly to a system and method for
coordinating communications activities on a communications
channel.
BACKGROUND OF THE INVENTION
[0003] With the many continued advancements in communications
technology, more and more devices are being introduced in both the
consumer and commercial sectors with advanced communications
capabilities. Additionally, advances in processing power and
low-power consumption technologies, as well as advances in data
coding techniques have led to the proliferation of wired and
wireless communications capabilities on a more widespread
basis.
[0004] For example, communication networks, both wired and
wireless, are now commonplace in many home and office environments.
Such networks allow various heretofore independent devices to share
data and other information to enhance productivity or simply to
improve their convenience to the user. One such communication
network that is gaining widespread popularity is an exemplary
implementation of a wireless network such as that specified by the
WiMedia-MBOA (Multiband OFDM Alliance). Other exemplary networks
include the Bluetooth.RTM. communications network and various IEEE
standards-based networks such as 802.11 and 802.16 communications
networks, to name a few.
[0005] Architects of these and other networks, and indeed
communications channels in general, have long struggled with the
challenge of managing multiple communications across a limited
channel. For example, in some environments, more than one device
may share a common carrier channel and thus run the risk of
encountering a communication conflict between the one or more
devices on the channel.
[0006] Over the years, network architects have come up with various
solutions to arbitrate disputes or otherwise delegate bandwidth
among the various communicating devices, or clients, on the
network. Schemes used in well known network configurations such as
token rings, Ethernet, and other configurations have been developed
to allow sharing of the available bandwidth. In addition to these
schemes, other techniques have been employed, including for example
CDMA (code division multiple access) and TDMA (time division
multiple access) for cellular networks.
[0007] FDM (Frequency Division Multiplexing) is another technology
that enables multiple devices to transmit their signals
simultaneously over a communication channel in a wired or wireless
setting. The devices' respective signals travel within their
designated frequency band (carrier), onto which the data (text,
voice, video, or other data.) is modulated. With adequate
separation in frequency band spacing, multiple devices can
simultaneously communicate across the same communication channel
(network or point-to-point).
[0008] Orthogonal FDM (OFDM) spread spectrum systems distribute the
data over a plurality of carriers that are spaced apart at precise
frequencies. The spacing is chosen so as to provide orthogonality
among the carriers. Thus, a receiver's demodulator recovers the
modulated data with little interference from the other carrier
signals. The benefits of OFDM are high spectral efficiency,
resiliency to RF interference, and lower multi-path distortion or
inter symbol interference (ISI). OFDM systems can be combined with
other techniques (such as time-division multiplexing) to allow
sharing of the individual carriers by multiple devices as well,
thus adding another dimension of multiplexing capability.
[0009] However, even with various multiplexing schemes available to
network and other communication channel designers, there can still
be inefficiencies in bandwidth allocation due to factors such as
fragmentation. Fragmentation can occur, for example, where short
durations of network bandwidth are separated by unavailable network
time slots, making it difficult for a communication process to
properly allocate its communication packets in an efficient manner.
As users come and go, the unoccupied slots within a communication
window can easily get fragmented to the point that a user may not
be able to find the required or the optimal configuration of the
slots (whether they desire contiguous or uniformly distributed
slots, or otherwise) to meet their needs.
BRIEF SUMMARY OF THE INVENTION
[0010] According to one embodiment, a method of allocating
communication bandwidth among a plurality of network devices
scheduling and conducting communication activities within the
communication network in a communication network is provided. The
method comprises the steps of: a first network device determining
allocations of other network devices operating in the communication
network; the first network device preempting a scheduled allocation
of a second network device; and the first network device scheduling
its communication activities on the communication network.
Additionally, the first network device can also determine whether a
conflict exists between its desired or required allocation and an
allocation of the second network device.
[0011] The preempting operation can be performed in a number of
different ways. For example, in one embodiment, preemption
comprises the step of adjusting a threshold to provide increased
bandwidth availability to the first network device. In another
embodiment, the step of preempting comprises the steps of the first
network device informing the second network device of the
preemption and of its scheduling requirement; and the second
network device reallocating its bandwidth in a manner that does not
conflict with the first network device. In a further embodiment,
the step of preempting comprises the steps of the first network
device informing the second network device of its scheduling
requirement, and the second network device determining whether its
own scheduling requirement is in conflict with the first network
device. In this embodiment, the second network device can
reallocate its bandwidth in a manner that does not conflict with
the first network device.
[0012] Additionally, preemption in accordance with an embodiment of
the invention can result in the second network device reallocating
some or all of its scheduled bandwidth to a different communication
window or channel. It can also comprise the steps of determining a
relative priority of the network devices and further determining
whether a given network device can preempt another network device
based on the relative priority. Further, the scheduled allocations
of a network device can comprise one or more network time or
channel slots.
[0013] In accordance with another embodiment of the invention, the
above described features and functionality can be performed using
control logic disposed in a network device configured to operate
within a communication network, the network device can further
include a housing and a transmitter and receiver within the
housing; network device, and wherein the other network device is
configured to determine whether its own scheduling requirement is
in conflict with the first network device.
[0014] In yet another embodiment of the invention, an executable
program product including a body of program code executable by a
processor is provided to perform the described features and
functions of the invention. Thus, in one embodiment, the program
code causes the processor to dynamically allocate the bandwidth
utilization of a first network device in accordance with the
various features described therein.
[0015] Further features and advantages of the present invention, as
well as the structure and operation of various embodiments of the
present invention, are described in detail below with reference to
the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
[0016] The present invention, in accordance with one or more
various embodiments, is described in detail with reference to the
following figures. The drawings are provided for purposes of
illustration only and merely depict typical or example embodiments
of the invention. These drawings are provided to facilitate the
reader's understanding of the invention and shall not be considered
limiting of the breadth, scope, or applicability of the invention.
It should be noted that for clarity and ease of illustration these
drawings are not necessarily made to scale.
[0017] FIG. 1 is a block diagram illustrating one possible
configuration of a wireless network that can serve as an example
environment in which the present invention can be implemented.
[0018] FIG. 2 is a diagram illustrating one possible configuration
of a communication window that can serve as an example environment
in which the present invention can be implemented.
[0019] FIG. 3 is an operational flow diagram illustrating one
method for dynamic allocation in accordance with one embodiment of
the invention.
[0020] FIG. 4 is diagram illustrating an example allocation of
communication activities in an example communication window.
[0021] FIG. 5 is diagram illustrating another example allocation of
communication activities in an example communication window.
[0022] FIG. 6 is an operational flow diagram illustrating one
method for bandwidth allocation in accordance with one embodiment
of the invention.
[0023] FIG. 7 is an operational flow diagram illustrating one
method for bandwidth allocation in accordance with one embodiment
of the invention.
[0024] FIG. 8 is diagram illustrating another example allocation of
communication activities in an example communication window.
[0025] FIG. 9 is diagram illustrating another example allocation of
communication activities in an example communication window.
[0026] FIG. 10 is diagram illustrating another example allocation
of communication activities in an example communication window.
[0027] FIG. 11 is diagram illustrating another example allocation
of communication activities in an example communication window.
[0028] FIG. 12 is diagram illustrating another example allocation
of communication activities in an example communication window.
[0029] FIG. 13 is diagram illustrating another example allocation
of communication activities in an example communication window.
[0030] FIG. 14 is diagram illustrating another example allocation
of communication activities in an example communication window.
[0031] FIG. 15 is diagram illustrating another example allocation
of communication activities in an example communication window.
[0032] FIG. 16 is diagram illustrating another example allocation
of communication activities in an example communication window.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0033] The present invention is directed toward a system and method
for providing defragmentation of communication channel allocations.
The communication channel can be that of a communication network or
other communication channel. One example communication channel is a
wireless network. An exemplary implementation of a wireless network
is a network as specified by the WiMedia-MBOA (Multiband OFDM
Alliance), although the invention can be implemented with other
networks and communication channels as well.
[0034] Before describing the invention in detail, it is useful to
describe an example environment in which the invention can be
implemented. One such example is a wireless beaconing network in
which multiple electronic devices (for example, computers and
computing devices, cellular telephones, personal digital
assistants, motion and still cameras, among others) can communicate
and share data, content and other information with one another. One
example of such a network is that specified by the WiMedia standard
(within WiMedia and Multi-Band OFDM Alliance). From time-to-time,
the present invention is described herein in terms of a distributed
network or in terms of the WiMedia standard. Description in terms
of these environments is provided to allow the various features and
embodiments of the invention to be portrayed in the context of an
exemplary application. After reading this description, it will
become apparent to one of ordinary skill in the art how the
invention can be implemented in different and alternative
environments. Indeed, applicability of the invention is not limited
to a distributed wireless network, nor is it limited to the MB-UWB
standard described as one implementation of the example
environment.
[0035] Most network standards specify policies or rules that govern
the behavior of network connected devices. The WiMedia standard
specifies the mechanism and policies that are to be followed by
W-USB and WiNet compliant devices in order to allow for an ad hoc
and distributed network of such devices to operate efficiently.
Policies, requirements, protocols, rules, guidelines or other
factors used to incentivize, recommend, specify, govern, control or
manage the behavior of devices operating in a communication network
are generally referred to herein as utilization policies.
[0036] In most distributed networks, the network of the devices is
maintained by requiring all devices to announce parameters such as
their presence, their capabilities and their intentions for
reserving transmission slots and so on. For example, with the
WiMedia standard, this can be done during what are referred to as
beacon period time slots. According to this standard, devices
joining the network are expected to monitor the beacon period to
learn about the network status and parameters before attempting to
use the network. In other network configurations, beacon periods
are similarly used to allow management of network devices as
described more fully below. Thus, beacon periods are one form of
window or network period during which scheduling or other
housekeeping activities can be conducted. Beacon periods in the
above-referenced standard, and other time periods used for
scheduling or other housekeeping chores in other network
configurations, are generally referred to as scheduling
windows.
[0037] Devices are typically allowed to enter a power save mode to
conserve power and possibly prolong operation. For example, battery
operated devices may enter a sleep mode or even a deep-sleep mode,
wherein one or more of their functions are diminished or shut down
in order to conserve power. Depending on the environment, devices
may be allowed to enter into a sleep mode for short or long periods
of time. For example, a sleep mode can be an energy-saving mode of
operation in which some or all components are shut down or their
operation limited. Many battery-operated devices, such as notebook
computers, cell phones, and other portable electronic devices
support one or more levels of a sleep mode. For example, when a
notebook computer goes into one level of sleep mode, it may turn
off the hard drive and still allow the user to perform operations,
only powering up the hard drive when access is needed. In a deeper
level of sleep, the computer may further turn off the display. In
yet a further level of sleep, the computer may enter a hibernate
state. Likewise, other electronic devices communicating across a
communication channel may have similar sleep states and may power
down unnecessary or unused components, including an RF transceiver,
depending on a number of factors such as elapsed time, activities
and so on. As described below, in accordance with one embodiment,
devices may be prompted to enter a sleep mode upon completion of
scheduling or other housekeeping activities and be configured to
awaken for scheduled activities such as, for example, communication
activities.
[0038] FIG. 1 is a block diagram illustrating one possible
configuration of a wireless network that can serve as an example
environment in which the present invention can be implemented.
Referring now to FIG. 1, a wireless network 1020 is provided to
allow a plurality of electronic devices to communicate with one
another without the need for wires or cables between the devices. A
wireless network 1020 can vary in coverage area depending on a
number of factors or parameters including, for example, the
transmit power levels and receive sensitivities of the various
electronic devices associated with the network. Examples of
wireless networks can include the various IEEE and other standards
as described above, as well as other wireless network
implementations.
[0039] With many applications, the wireless network 1020 operates
in a relatively confined area, such as, for example, a home or an
office. The example illustrated in FIG. 1 is an example of an
implementation such as that which may be found in a home or small
office environment. Of course wireless communication networks and
communication networks in general are found in many environments
outside the home and office as well. In the example illustrated in
FIG. 1, wireless network 1020 includes a communication device to
allow it to communicate with external networks. More particularly,
in the illustrated example, wireless network 1020 includes a modem
1040 to provide connectivity to an external network such as the
Internet 1046, and a wireless access point 1042 that can provide
external connectivity to another network 1044.
[0040] Also illustrated in the example wireless network 1020 are
portable electronic devices such as a cellular telephone 1010 and a
personal digital assistant (PDA) 1012. Like the other electronic
devices illustrated in FIG. 1, cellular telephone 1010 and PDA 1012
can communicate with wireless network 1020 via the appropriate
wireless interface. Additionally, these devices may be configured
to further communicate with an external network. For example,
cellular telephone 1010 is typically configured to communicate with
a wide area wireless network by way of a base station.
[0041] Additionally, the example environment illustrated in FIG. 1
also includes examples of home entertainment devices connected to
wireless network 1020. In the illustrated example, electronic
devices such as a gaming console 1052, a video player 1054, a
digital camera/camcorder 1056, and a high definition television
1058 are illustrated as being interconnected via wireless network
1020. For example, a digital camera or camcorder 1056 can be
utilized by a user to capture one or more still picture or motion
video images. The captured images can be stored in a local memory
or storage device associated with digital camera or camcorder 1056
and ultimately communicated to another electronic device via
wireless network 1020. For example, the user may wish to provide a
digital video stream to a high definition television set 1058
associated with wireless network 1020. As another example, the user
may wish to upload one or more images from digital camera 1056 to
his or her personal computer 1060 or to the Internet 1046. This can
be accomplished by wireless network 1020. Of course, wireless
network 1020 can be utilized to provide data, content, and other
information sharing on a peer-to-peer or other basis, as the
provided examples serve to illustrate.
[0042] Also illustrated is a personal computer 1060 or other
computing device connected to wireless network 1020 via a wireless
air interface. As depicted in the illustrated example, personal
computer 1060 can also provide connectivity to an external network
such as the Internet 1046.
[0043] In the illustrated example, wireless network 1020 is
implemented so as to provide wireless connectivity to the various
electronic devices associated therewith. Wireless network 1020
allows these devices to share data, content, and other information
with one another across wireless network 1020. Typically, in such
an environment, the electronic devices would have the appropriate
transmitter, receiver, or transceiver to allow communication via
the air interface with other devices associated with wireless
network 1020. These electronic devices may conform to one or more
appropriate wireless standards and, in fact, multiple standards may
be in play within a given neighborhood. Electronic devices
associated with the network typically also have control logic
configured to manage communications across the network and to
manage the operational functionality of the electronic device. Such
control logic can be implemented using hardware, software, or a
combination thereof. For example, one or more processors, ASICs,
PLAs, and other logic devices or components can be included with
the device to implement the desired features and functionality.
Additionally, memory or other data and information storage capacity
can be included to facilitate operation of the device and
communication across the network. Software can include program code
that is executable by a processing device to perform the desired
functions.
[0044] Electronic devices operating as a part of wireless network
1020 are sometimes referred to herein as network devices, members
or member devices of the network or devices associated with the
network. In one embodiment devices that communicate with a given
network may be members or merely in communication with the
network.
[0045] Some communication networks are divided into periods or
frames that can be used for communication and other activities. For
example, as discussed above, some networks have a scheduling window
such as, for example, a beacon period, for scheduling upcoming
communication activities. Also, some networks have a communication
window during which such communication activities take place. In
the WiMedia-MBOA standard, the bandwidth is divided into
superframes, which in turn are divided into time slots for the
transmission and reception of data by the various electronic
devices associated with the network.
[0046] An example of such time slots are illustrated in FIG. 2.
Referring now to FIG. 2, in this exemplary environment, the
communication bandwidth is divided into superframes 104 (two
illustrated), each superframe 104 itself being divided into a
plurality of timeslots referred to as Media Access Slots 108. In
the example environment, there are 256 media access slots 108 in
each superframe 104, although other allocations are possible.
Additionally, at the beginning of each superframe 104 is a beacon
period 111, which is comprised of a plurality of beaconing slots.
In some networks, the beacon period 111 is a period during which
devices reserve timeslots and exchange other housekeeping or status
information. For example, in the WiMedia-MBOA distributed wireless
network, the superframes comprise a beacon period 111, during which
devices are awake and receive beacons from other devices.
Superframes in the above-referenced standard, and other time
periods used for communications among devices in other network
configurations, with or without scheduling windows, are generally
referred to herein as communication windows. As noted above, for
clarity of description the present invention is described in terms
of the example environment, and thus is at times described using
the terms superframe and beacon period. As would be apparent to one
of ordinary skill in the art after reading this description, the
invention applies to other communication formats, including the
more general case utilizing scheduling windows and communication
windows. Additionally, the invention is not limited to applications
where the bandwidth is divided into frames or windows, but can be
generally applied to communication channels and networks of various
protocols and configurations.
[0047] Having thus described an example environment in which the
invention can be implemented, various features and embodiments of
the invention are now described in further detail. Description may
be provided in terms of this example environment for ease of
discussion and understanding only. After reading the description
herein, it will become apparent to one of ordinary skill in the art
that the present invention can be implemented in any of a number of
different communication environments (including wired or wireless
communication environments, and distributed or non-distributed
networks) operating with any of a number of different electronic
devices and according to various similar or alternative protocols
or specifications.
[0048] In the example environment of the WiMedia-MBOA network, the
wireless network is a distributed wireless network, which is
typically defined as a network having no designated master or host
to control traffic on its channels. Thus, instead of a host
controlling bandwidth access for example, these networks typically
rely on self policing, or self-control on the part of the various
electronic devices associated with the network to conform to
network policies, guidelines or standards. In this example network,
each electronic device associated with the network can reserve
certain time slots of each superframe to transmit its packets based
on its Quality of Service or power conservation requirements. As
such, the network load is dynamically distributed and can be
changed within a superframe as time progresses. As users come and
go, the unoccupied slots within a superframe can easily get
fragmented to the point that a user may not be able to find the
required or the optimal configuration of the slots (either
contiguous or uniformly distributed, or otherwise) to meet their
needs. This problem can also exist in other types of networks or
scheduled communication channels where access slots become
fragmented. However, the problem and the solutions provided by the
present invention are not limited to communication channels
scheduled on the basis of time. Fragmentation can also exist with
channels having bandwidth access shared on the basis of frequency
division, code division, spatial division and other mechanisms. As
such, the solutions presented herein, can be applied across these
various forms of communication channels.
[0049] This problem can be similar to fragmentation problem that
often occurs on hard drives, which could hurt performance if not
addressed. However, because the network's bandwidth allocation
space (for example, a superframe in the case of an MBOA channel) is
usually much smaller than a typical hard drive in capacity, this
problem can arise relatively quickly in the case of a communication
channel. Additionally, the problem could become debilitating for
some electronic devices that may desire or even require a
particular slot configuration for proper operation. In a highly
fragmented network, even if there are plenty of slots open, without
defragmentation or without proper allocation and reallocation
schemes, a user's use of the network could become hampered or
rendered impossible.
[0050] Utilization policies can be implemented to define
appropriate bandwidth utilization among devices, as well as other
network behavior. Utilization policies can help with
defragmentation of the network, which is preferably implemented so
as to take place without disrupting service, or with only minimal
disruption. Defragmentation can be implemented in various ways,
depending on the network devices and the communication goals and
objectives. For example, defragmentation might be accomplished by
providing a communication device with the ability to combine its
reservations in contiguous time slots. As another example,
defragmentation can encompass providing reservations slots in a
predetermined pattern or other basis. As these examples illustrate,
other allocations can be sought as an outcome of the
defragmentation process to allow for improved utility of the
available capacity for the various devices, users or applications.
Because defragmentation or other reallocation is possible in a
number of ways but there is a possibility that it could be quite
time consuming or disruptive, it is preferable that it be kept
simple and effective.
[0051] For each communication channel or communication network,
depending on what type of applications are expected on that
network, the term defragmentation can take on different meanings.
The terms "defragmentation" and "defragmented" do not necessarily
refer to complete defragmentation. In other words, these terms do
not necessarily imply that all of the reserved slots are packed
together as contiguously as possible. In other words, there can be
varying degrees of fragmentation or defragmentation. In fact, in
some embodiments, it may be preferable to be defragmented in such a
way so as to distribute some or all of the reservations of one or
more devices in such a way as to let other such applications
receive their desired service interval. This can arise, for
example, where a device or class of devices may have certain
limitations on its or their service intervals. Thus, the term
defragmentation and its variants can also refer to reallocation of
bandwidth among devices.
[0052] According to one embodiment of the invention,
defragmentation can be implemented to take place by mandate, where
network devices are required to defragment according to one or more
policies. In accordance with another embodiment of the invention,
network devices are incentivized to follow utilization policies,
including defragmentation practices. That is, a device can be
either obligated or required to adjust its timeslot utilization or
it can be given incentives to adjust its utilization--for example,
positive to do so, or negative incentives for not doing so. Thus,
for example, a device can be either obligated to move its slot
reservations to a more optimal location within the window of slots
within a certain period of time. Alternatively, policies or
procedures could be adopted or implemented in such a way that
rather than mandating a device to move its slots, there may be
penalties (for example, performance penalties) that it could incur
by not moving its slots or benefits (for example, performance
benefits) gained by so moving its slots.
[0053] Additionally, a hybrid approach is provided, wherein a
combination of requirements and incentives (positive or negative
incentives) can be provided to manage the defragmentation process.
For example, a network may operate in such a way as to allow
incentivized defragmentation where the network is operating well
within its capacity, and switch to a mandated or obligatory
defragmentation during periods of heavy utilization where bandwidth
is at a premium. Thus, the network can be monitored in real time or
near real time based on factors such as, for example, current
channel loading, network performance, or other factors.
[0054] FIG. 3 is an operational flow diagram illustrating a process
for implementing a hybrid approach to incentive defragmentation in
accordance with one embodiment of the invention. Referring now to
FIG. 3, in a step 122 communications activities are conducted
across the channel. For example, network devices conduct normal
activities communicating with other network devices across the
network.
[0055] In a step 126, one or more network conditions are monitored
to detect conditions that could indicate operational concerns.
Several examples are highlighted to illustrate such possible
conditions. For example, bandwidth utilization can be monitored to
determine whether the network is at or near capacity, or over
utilized. As another example, the status of network devices can be
monitored to determine whether a device is operating out of
conformance with network parameters, requirements, protocols or
other such utilization policies. Additionally, levels of
defragmentation on the network can be monitored. As these examples
indicate, other network conditions can also be monitored to
determine whether current defragmentation policies are acceptable,
or whether a change is mandated. The monitoring can take place by a
network master, where such device exists, by one or more devices
associated with a distributed network, or by each device on its own
based on the policies of a standard protocol.
[0056] Where it is determined that the network is operating out of
tolerance or acceptable bounds for one or more of the network
conditions, the network can transition from an incentivized mode to
a mandated mode (or remain in a mandated mode), requiring devices
to implement defragmentation policies at least to a certain extent.
This is illustrated by steps 128 and 130 in FIG. 3. Alternatively,
where the network is operating within defined bounds, the network
devices are instructed to transition to (or are allow to remain in)
incentivized mode, such that the network devices can make their own
determinations as to the level of defragmentation implemented. This
is illustrated by steps 128 and 132 in FIG. 3.
[0057] Incentive approaches for defragmentation can be implemented
in a number of different ways. A network device may be requested to
move or adjust its slot allocation to help the system maintain or
improve its level of defragmentation. This can be accomplished, for
example, inherently through protocols, usage requirements or other
such utilization policies, or explicitly by request of other
devices/hosts. In this example, the device in question may be
rewarded with increases in bandwidth allocation, for example, for
conforming to the request. As indicated, in another embodiment, the
device in question may be penalized by, for example, limiting
future bandwidth allocations if the device does not conform to the
request.
[0058] In such incentivized approaches, the system can provide the
freedom of choice with the device such that if an application is
necessarily unable to move its reservation slots due to some
unforeseen circumstances, that it can continue its operation
without disruption, but perhaps at a cost of performance.
Additionally, the incentivized form of defragmentation can be
implemented so as to place certain burdens on the offending devices
such that they would be opting for non-offensive reservations
within the network whenever possible. This extra burden could be in
the form of extra monitoring tasks, extra reporting effort,
limitation in bandwidth utilization, etc.
[0059] In one embodiment, the choices of particular penalties or
rewards as well as choices between penalties and rewards may be
made dynamically based on a current status or health of the
network. Thus, where bandwidth is particularly tight during a given
period, for example, it may be determined that the incentive is a
bandwidth penalty for non-compliance with the request. In
furtherance of this example, and in terms of the example
environment, network devices may be implemented so as to detect
bandwidth utilization, and to self-impose predetermined penalties
for not conforming to defragmentation guidelines depending on the
network condition.
[0060] In another embodiment, dynamic incentives can be implemented
to vary based on the magnitude of the offense; the frequency,
quantity or number of times a given device has committed offenses;
the status of the network or any of a number of other factors.
Thus, for example, penalties can become more severe for a device
that frequently ignores requests, or more severe as network
conditions degrade. For example, where bandwidth is becoming
increasingly tight, the bandwidth penalty (or other incentive) for
non-compliance can be increased accordingly. Thus, as network
conditions become more severe, the incentives become greater. In
furtherance of this example, and in terms of the example
environment, network devices may be implemented so as to detect
bandwidth utilization, and to self-impose increasing levels of
predetermined penalties for not conforming to defragmentation
guidelines as network conditions dictate.
[0061] Various techniques can be used to enforce the incentives as
may be desired or appropriate for the network application. For
example, in the example WiMedia network and others a methodology
(for example, within the Medium Access Control layer) can be
implemented to announce the offending reservations of a device to
other network devices. Thus, the other network devices receiving
announcement of such reservations can determine whether and to what
extent to preempt the offending devices out of their slots. The
above-described preemption mechanism can be accomplished in a
number of different ways. For example, the preemptor can announce
allowable reservations that overlap with the preemptible
reservations of the offending device. This overlap can be detected
by the offender and indicate to the offender that it should move or
remove its reservations.
[0062] In another embodiment, a network master can be provided with
the ability to deny bandwidth requests from the offending device or
to otherwise appropriately allocate bandwidth among network devices
in accordance with the policies as may be in effect. In yet another
embodiment, network devices can be implemented so as to be self
policing in that they impose their own penalties for
non-conformance with defragmentation guidelines. For example, a
network device may opt to not follow defragmentation guidelines and
in return not utilize an appropriate amount of bandwidth as
indicated by the guidelines. Additionally, a device may dynamically
monitor the network conditions and defragment or change its
reservations, if monitored conditions change (for example, more
users join the network, available bandwidth becomes tighter, or
levels of fragmentation reach a predetermined threshold).
[0063] In one embodiment, a device can be identified as being an
offending device vis-a-vis the reservations using any of a number
of different techniques. For example, the device's reservation
request can be compared relative to what reservations are permitted
or acceptable to determine whether the device is violating the
reservation protocol. As another example, a device may identify or
announce its reservation request and the other devices are
configured to determine whether the reservation is an offense. A
further example of one scenario where a device may be considered an
offending device is a situation where a device designated to
operate in an unrestricted region of the communication channel
requests reservations that extend into the restricted region.
[0064] Offending devices can be configured to notify others that
they are in violation of the reservation protocol or utilization
policy. One way to accomplish this is for the offending device to
set a flag (for example, it can set a bit to a designated state)
indicating that it is in violation of the policy. Another way is to
announce the offense to other devices during the beacon period so
that other devices are aware that the device is out of conformance.
The device may also provide details of the offense such as, for
example, an identification of requested slots that are out of
conformance. Other devices may, depending on the network
configuration, be able to preempt the offending device. Examples of
such preemption are discussed further herein in one embodiment.
[0065] In one embodiment, until preemption or other penalties takes
place, the offending device may be permitted to continue with its
reservations without modifying its behavior. The network device can
be implemented so as to be aware that as long as it continues its
offending behavior, it may be subject to preemption by other
devices or other penalties. Thus, the network devices can be
implemented to, over time and as other slots become empty,
transition its reservations or modify its behavior so that it is
out of the danger of penalties. This very act of voluntary movement
of slots can lead to defragmentation of the communication
window.
[0066] In one embodiment, defragmentation can be implemented to
allow for flexibility of slot reservation and usage as well. For
example, one compromise that can be implemented is to let the
network devices choose any reservation they like or need, as long
as there are no other users contending for some or all of those
slots. Once a contention for those slots occurs, then the offending
device is expected to move its reservations, and can be asked to,
required to or incentivized to move its reservations. This approach
allows for freedom of choice on per-device basis, but also gives
the network in general the ability to manage resources. In this
embodiment, the network can be described as having veto power
(whether implemented by a master, by self policing of devices, by
other network devices pre-empting the offending device or
otherwise), when necessary, to force an offending device out of an
offensive slot. This veto power can be implemented so as to ensure
that network performance is maintained to a desired level and that
available bandwidth is equitably distributed among all devices.
[0067] As the above example illustrates, one advantage of the
incentivized approach is that devices can be given the freedom to
make certain choices to optimize their performance, and in hybrid
embodiments or embodiments where incentives are dynamic, network
performance can be assured, at least to a certain level. For
example, a device with certain power constraints and with
relatively low bandwidth requirements may opt for a particular
fragmentation that conserves power by maximizing sleep time at the
cost of having a lower bandwidth allocation.
[0068] As noted above, in one embodiment the devices are self
regulating in that they are implemented so as to follow the
prescribed reservation policies and to yield to other devices in
accordance with those policies. One technique for ensuring
compliance with these policies is to require interoperability
testing for the devices as part of a certification process.
[0069] One approach to implementing the above is to split the
channel (for example, a superframe of timeslots) into zones, where
the zones can be pre-designated for certain applications or types
of applications or for utilization by certain types or classes of
devices, or designated from time-to-time for allocation and
reallocation to certain types of applications or for utilization by
certain types or classes of devices. Zones can also be
pre-designated to more than one application or device (or class
thereof) such that a designation might be shared among multiple
entities. This sharing can be done on an equal footing basis, where
the designated entities share the slots on par with one another, or
on a weighted or priority basis. For example, the sharing can be
done on a priority basis wherein one of the sharing entities takes
priority over another sharing entity and they both take priority
over all other non-sharing entities.
[0070] As one example, certain timeslots may be designated for
real-time content delivery devices, such as for example video
devices. In this example, a video device can preempt other
non-video devices from utilizing certain zones or groupings of
slots. For example, the network might be implemented such that a
DVD player and a video recorder on the network could preempt other
non-video devices from their designated slots or zone of slots. As
a further example, a DVD player tasked with playing video content
in real time (for example streaming video to an HDTV monitor) might
be designated as taking priority over a video recording downloading
content for storage or archival purposes to a network drive. Thus,
in this further example, the DVD player would have the ability to
preempt the video recorder from the DVD player's designated slots
or zone of slots. However, because network users do not always have
a priori knowledge of what types of applications or devices will be
using the network in each instance and location, in order to allow
for maximum network utility, each device can be given the freedom
to use any slots it can or prefers without regard to the
pre-designated zone.
[0071] As the above example illustrates, network devices designed
for a particular application can have different requirements in
terms of data rate, throughput, power consumption, etc. In order to
perform their functions and provide efficiency in terms of
complexity, cost and power management, network devices can be
implemented so as to enable flexible allocation of bandwidth (such
as, for example, the allocation of MAC superframe slots in the
example environment).
[0072] For example, some network devices routinely transfer large
amounts of data (such as FTP transfers, media transfers, and so on)
to and from storage devices and other devices. Such devices often
benefit from a reservation policy allowing continuous transfer.
However, continuous transfers of large amounts of data can tie up
network resources at the expense of other network devices. Thus, in
one embodiment, the network can be configured to allow such devices
to wait for an appropriate transfer window, deliver all the desired
data at once, or in large blocks, and then go into a sleep mode or
other power saving mode. For example, large transfers can be
scheduled for periods of quiet time or periods where network
utilization is at a minimum.
[0073] Another type of network device, for example a video playback
device, may deliver time sensitive data in small but continuous
blocks. The data can be divided into blocks and distributed across
multiple windows, but some level of continuity is desired. For
example, for video playback, the content information does not
always need to be delivered all at once, but can be delivered as it
is played, preferably with some buffer amount, and with continuity.
Therefore, in one embodiment, such devices are allowed to reserve
MAC slots at specific intervals. Furthermore, in another embodiment
the invention can be implemented to provide a dynamic allocation
and re-allocation policy allowing devices that benefit from a
continuous transmission to allocate the required MAC slot resources
while defining policy to release those continuous slots when
devices with strict timing requirements (and as such, higher
priority) request some of the super-frame slots.
[0074] In one embodiment, the window (for example, a superframe
104) can be divided into sections. For example, the communication
window can be divided into two sections--a restricted section and
an unrestricted section. In one embodiment, a network device making
reservations in the unrestricted areas is permitted to allocate
several consecutive slots within that zone. In one embodiment, the
allocation can be made up to the slot boundaries, and those
boundaries are hard-defined and cannot be moved. This embodiment,
however, can result in restrictive and inefficient utilizations.
For example, a scenario may arise that unnecessarily restricts the
operation of time sensitive devices even when no device operates in
the unrestricted area.
[0075] Although a dynamic implementation can be utilized that
allows adjustment of the boundary between the zones, difficulties
may arise with this solution. For example, rules can be defined to
specify and allow for the boundary between restricted and
unrestricted areas to be adjusted or moved dynamically adjusting
the amount of bandwidth allocated among device types. For an
illustration of a difficulty that may arise with this second
solution, consider an example hypothetical allocation of a
superframe 104 as presented in FIG. 4. In this example scenario the
communication portion of superframe 104 is divided into a
restricted region 212 and an unrestricted region 214. For purposes
of illustration, assume there are a limited number of device types
operating within the two-dimensional slot allocation table (shaded
regions 204, 206, and 208). In this depiction, vertically
contiguous slots are contiguous in time. The areas marked 202 are
pre-designated for contention-based allocation and are not
available for reservation-based allocation. In this example the
time sensitive devices 204 occupy less then 8% of the total
allocation with an additional 23% of the available bandwidth
occupied by the remaining devices (designated as shaded areas 206,
208) and contention-based allocations 202.
[0076] To further illustrate, consider what could happen when an
additional device with the preferred mode of operation as
unrestricted enters the network. Assume that to satisfy its
bandwidth requirements, the added device needs to reserve 11 media
access slots per superframe 104. This is illustrated in FIG. 5 as
shaded regions 210. To minimize its power consumption, the
preferred mode of operation for the new device is sending all
packets 210 in a continuous mode (vertically) and as close to the
beacon period 111 as possible. However, this allocation is not
allowed under either of the above solutions. Even though in the
illustrated scenario, almost 70% of the available bandwidth is not
used--and may never be used--these solutions would cause the device
to distribute its slots in different zones across the channel to
some extent, and thus have to "wake up" at least three times (or
remain awake for a longer period of time) in order to satisfy its
bandwidth requirements. In other words, the device would have to
break up its transmissions into smaller vertical chunks to fit
within the unrestricted region 214.
[0077] To address this potential shortcoming, one embodiment of the
invention provides for dynamic allocation of reservations. More
particularly, in one embodiment, the invention provides a dynamic
allocation of reservations for timeslots that are required or
preferred to be contiguous (e.g., vertical reservations in the
superframe representation illustrated in FIGS. 4 and 5). Such
allocation can be reallocated in one embodiment to give preference
to delay sensitive devices that prefer to have their bandwidth
distributed over the superframe relatively evenly (e.g., horizontal
reservations).
[0078] To illustrate dynamic allocation, consider an example
defined in terms of the example environment. In this environment, a
WiMedia-MBOA device as defined by the WiMedia-MBOA specifications
can be configured to send and receive a beacon frame before any
transmission activities. Within this beacon frame, each device can
define its capabilities, transmission requirements (i.e.,
reservation of MAC slots), control information, etc. In one
embodiment, dynamic allocation of vertical reservations can be
permitted while still providing some level of bandwidth protection
for the delay sensitive devices. This can be accomplished, for
example, by requesting release of the additional MAC slots 108 from
the restricted area 212.
[0079] In the example environment, the MAC specification document
version 0.95, the DRP Allocation field is redefined from the
settings in Table 1 below to the settings in Table 2 below.
TABLE-US-00001 TABLE 1 Octets: 2 2 Zone Bitmap MAS Bitmap
[0080] TABLE-US-00002 TABLE 2 Octets: 1 1 2 UMR Zone Map MAS
Bitmap
[0081] Because there are only 15 zones in the example environment,
the zones can be encoded using only four bits from the Zone Bitmap
field while leaving the remaining four bits reserved for future
use. Furthermore, the first octet can be designated for the
Unrestricted Mode Request (UMR). In one embodiment, the
unrestricted mode request is defined as shown in Table 3. In this
embodiment, the UMR includes an unrestricted Reservation Request
field (URR) and a field for the requested number of sets above
restricted threshold (RNS). For example, URR can have the bit
definition: 0001--UMR; all other--Reserved. The RNS can be used to
define the required number of additional horizontal sets the
Unrestricted Mode device is requesting to be released.
TABLE-US-00003 TABLE 3 UMR bit7-bit4 bit 3-bit0 RNS URR
[0082] Each device can be implemented so as to (or can be required
to) check the DRP Allocation field within the beacon period before
transmission in the current superframe 104, and the superframe
allocation can be adjusted if appropriate. FIG. 6 is an operational
flow diagram illustrating an example of this in accordance with one
embodiment of the invention. Referring now to FIG. 6, the
allocation field is checked to determine whether the device is
operating in the restricted or the unrestricted mode. This is
illustrated by steps 304 and 308.
[0083] If the device is operating in the restricted mode, for a
given communication window (e.g., Superframe.sub.n) and for a given
communication zone (e.g., Zone.sub.k), the allocation is checked to
determine whether it is requesting slots that would conflict with
an unrestricted device's request for additional allocation. In one
embodiment this is done by checking to see whether its
DEV_ALLOCATION.gtoreq.RESTRICTED_THR+RNS, and is illustrated by a
step 310. If so, in a step 316, the slots up to RESTRICTED_THR+RNS
are released by the restricted device for the next communication
window (for example, in Superframe.sub.n+1). Otherwise, operation
continues as normal. If the device is operating in the unrestricted
mode, in one embodiment it does not need to perform this operation.
In this example, preference is given to the delay sensitive devices
operating in the restricted mode, and the delay sensitive devices
are asked to release only their unused slots, and only when such
slots are designated as requested by an unrestricted device. In one
embodiment, this can be done on a zone-by-zone basis, wherein the
requests for each zone are evaluated.
[0084] In one embodiment, however, certain devices, can be given
superstatus, where they may be permitted to trump delay sensitive
devices and be given slots that would otherwise be used by the
delay sensitive devices. This may be desirable, for example, where
the power sensitivity of a given device or class of devices is high
and the device is critical to the network. Additionally, various
devices' status (or status of classes of devices) can be weighted,
and the determination of whether to release used or unused slots
can be made, at least in part, based on the relative weighting of
devices contending for the slots.
[0085] There are several ways the restricted zone threshold can be
defined in implementing dynamic allocation. For example, one
embodiment allows implementation without additional signaling or
parameters. In one embodiment, each device may be required to
implicitly extract this threshold from the MAS Bitmap field.
[0086] In another embodiment, the upper nibble of the ZONE_BITMAP
may be allocated to indicate the device zone restricted threshold.
One advantage that may be gained by this method is that the
threshold may be different in every zone. As such this methodology
can offer enhanced flexibility and MAC super-slot utilization.
[0087] In yet another embodiment, one or more octets can be
allocated to indicate the current restricted threshold for the next
communication window. This may be a compromise with the
conventional solutions for dynamic allocation. This threshold can
be set by last device within the beacon period.
[0088] In another embodiment of the invention, a methodology can be
implemented that considers preferred thresholds of multiple devices
when setting the threshold for one or more upcoming communication
windows. This can be in such a way as to allow for a dynamic
threshold (in some cases, completely dynamic) between restricted
and unrestricted areas of the allocation table. FIG. 7 is an
operational flow diagram illustrating an example implementation of
this method in accordance with one embodiment of the invention.
[0089] Referring now to FIG. 7, in a step 404, the current
threshold, THRc, can be set to a default value. For example, a
default threshold can be set at eight. This is the threshold used
in the current communication window. In a step 408, in the beacon
period 111, interested devices announce the preferred threshold,
THRp, they would like to have in the next communication window
(e.g., in the next superframe 104). They can also be requested or
required to announce the current value of the threshold, THRc, and
the next value of threshold, THRn.
[0090] In a step 412, the new threshold can be calculated based on
the various requested preferred thresholds (THRp's) of the
interested devices. For example, in one embodiment, each device can
calculate the next threshold, THRn, to be the greater of the
default threshold (eight in the example described) and the smaller
of all preferred thresholds in the beacons. This example
methodology can be used to ensure a certain level of performance to
restricted devices. Other criteria can be used to compute the next
threshold. For example, a network designer may determine that power
conservation is more critical than delay sensitive device
performance, and as such, may select the next threshold to
accommodate the maximum requested threshold.
[0091] The network devices can then adjust their next threshold,
THRn, in their Beacon within mMaxLostBeacons to the newly
calculated threshold. Once every device has updated their next
threshold, THRn, to the new common threshold, each device can use
that threshold in the next superframe as the new current threshold,
THRc. (so, THRc and THRn in the beacon will be identical at that
point.) The preferred thresholds can be reexamined every
superframe, and the next threshold, THRn, adjust as necessary, with
a max adjustment delay of mMaxLostBeacon superframes. Certain
restrictions may be put on the range of the thresholds THRc/p/n.
For example, in one embodiment they may be only in the range of
4-15.
[0092] To implement the above, the DRP EE frame format can be
changed from the format shown in Table 4 to the format shown in
Table 5. TABLE-US-00004 TABLE 4 Original DRP IE format octets: 1 1
2 2 4 4 Element ID Length (=4 + 4 .times. N) DRP Control
Target/Owner DevAddr DRP Allocation 1 . . . DRP Allocation N
[0093] TABLE-US-00005 TABLE 5 Modified DRP IE format octets: 1 1 2
2 2 4 4 Element Length DRP Target/Owner Allocation Zone DRP
Allocation 1 . . . DRP Allocation N ID (=4 + 4 .times. N) Control
DevAddr Thresholds
[0094] The Allocation Zone Thresholds field is further defined as
shown in Table 6. TABLE-US-00006 TABLE 6 Allocation Zone Thresholds
field format bits: b15-b12 b11-b8 B7-b4 B3-b0 Reserved THRp THRn
THRc
[0095] In another embodiment of the invention, two types of
thresholds are defined to allow flexibility in assigning bandwidth
to various devices or classes of devices. For example, in one
implementation a hard threshold and a soft threshold are
implemented. Preferably, the hard threshold is established and
typically would not change. The hard threshold can be set to
provide a certain level of guaranteed performance to a class of
devices. For example, the hard threshold can be established to
ensure that delay sensitive devices have sufficient bandwidth for
delay sensitive activities, even if it is at the expense or
inconvenience of power sensitive devices. In one embodiment in the
example environment, the hard threshold can be established as the
conventional boundary between the restricted region 212 and the
unrestricted region 214. The unrestricted region up to the hard
threshold in one embodiment can be referred to as the hard
unrestricted region. In one embodiment, the hard unrestricted
region may change from time to time and under certain circumstances
as for example occurs with conventional implementations of the
WiMedia specification.
[0096] The soft threshold can be defined as one that can change
based on changing conditions or circumstances of the network and
its devices. In one embodiment, network devices can request changes
to the soft threshold, and such changes are arbitrated or otherwise
decided upon according to various techniques. The unrestricted
region beyond hard unrestricted region and up to the soft threshold
can be referred to as the soft unrestricted region for purposes of
discussion. In one embodiment, vertical allocations up to the soft
threshold (even where extending beyond the hard threshold) are
allowed, but have lower priority in soft unrestricted region.
[0097] As stated above, the soft threshold can change increasing or
decreasing the size of the soft unrestricted region, dynamically
altering the allocation among devices. For example, in one
embodiment delay sensitive devices are given priority and thus if a
horizontal allocation is requested by a network device, the soft
threshold may be changed to allow more bandwidth for the delay
sensitive device(s). Any vertical allocations that may exist or
have been requested within the soft unrestricted region can be
re-distributed/re-allocated to allow for and adjustment of the soft
threshold and to permit the horizontal allocation within what was
the soft unrestricted region prior to adjustment. Thus, in this
example, bandwidth is reallocated from the unrestricted region to
the restricted region.
[0098] Additionally, should the demand for a horizontal allocation
of bandwidth subsequently decrease such that there is un-requested
or unallocated bandwidth in the restricted region, the system can
be configured so as to adjust the soft threshold downward,
reallocating bandwidth that was previously dedicated to
delay-sensitive devices, making that bandwidth available to
power-sensitive devices. The adjustment of the soft threshold up
and down can be done based on the allocation requirements for a
device or class of devices. Certain devices or classes of devices
can be given a higher priority or a relative weighting to allow
flexibility in determining when and by how much to adjust the soft
threshold. For example, in one embodiment the soft threshold can be
adjusted based primarily on requirements of delay-sensitive
devices. In this example, as delay-sensitive devices require
allocations, the soft threshold can be moved so as to increase the
bandwidth available in the restricted region, at the expense of the
unrestricted region. Thus, vertical allocations in the unrestricted
region have a greater likelihood of being broken up or fragmented
into smaller pieces across the available bandwidth.
[0099] Depending on the goals of the network implementation,
certain limitations or restrictions can be placed on the
redistribution of the soft threshold. For example, in one
embodiment, the redistribution, or reallocation, of bandwidth is
implemented only if after redistribution there are a certain number
of unallocated media access slots in the hard unrestricted region
and soft unrestricted region. For example, in one embodiment, the
number of slots required to remain in the unrestricted region can
be set to 30 although other allocations are possible. This
limitation may be desirable to ensure that there are sufficient
allocations remaining in the unrestricted region to allow a certain
level of flexibility and network operation. Additionally, it could
be required that there be a sufficient number of media access slots
remaining for delay-sensitive devices to use after the
redistribution of media access slots for power-sensitive devices
into the soft unrestricted region.
[0100] As yet another example, there can be restrictions placed on
the number of communication windows or superframes across which a
device can be expected to reallocate its bandwidth. For example,
there may be requirements that a device not be required to
reallocate its vertical access for a given superframe across
multiple superframes. As these examples illustrate, it is
contemplated that there be flexibility in allowing a network
designer to determine the placement of hard and soft thresholds and
the allocation and reallocation of bandwidth based on the movement
of one or more of these thresholds as network conditions and
priorities may change over time. Thus, it would be apparent to one
of ordinary skill in the art after reading this description, how to
implement other criteria, conditions and requirements for
allocation of bandwidth in accordance with these embodiments.
[0101] Additionally, as some of the above examples illustrate,
priority or preference may be given to delay-sensitive devices as
disruptions in bandwidth for delay-sensitive devices tend to have
effects that are noticeable by users or that may be detrimental to
the overall goals of the network devices. However, as discussed
above, it is contemplated that in alternative embodiments, priority
can be given to power-sensitive devices should concerns for the
power-sensitivity of these devices outweigh concerns for
performance of the delay-sensitive devices. Additionally, there can
be other classes or type of devices to which bandwidth is allocated
and around which arbitration decisions are made. Of course, within
classes of devices there may be subclasses and thus, classes,
subclasses and individual devices can be given relative priorities
in bandwidth allocation considerations. Thus, for example even
where one class of devices typically takes priority over a second
class of devices, there may be a device or a subclass of devices in
the second class that would trump or take priority over devices in
the first class.
[0102] A number of mechanisms can be implemented to allow
arbitration of the bandwidth between the restricted and
unrestricted regions. A few examples of these methodologies are
discussed to illustrate the possibilities that can exist for such
allocation. For example, in one embodiment, a network device which
is implemented so as to request horizontal reservations within the
soft unrestricted region even if one or more of the requested media
access slots within the soft unrestricted regions are already
reserved for or allocated to vertical allocations. This can be
done, for example, by requesting the allocation during the beacon
period in the example environment or during other like periods in
alternative environments. Once such a request for bandwidth in the
soft unrestricted region is made, a determination can be made as to
whether to reallocate that bandwidth to the devices operating in
the unrestricted region. In other words, it can be determined
whether to adjust the soft threshold to provide the requested
reallocation of bandwidth.
[0103] In one embodiment, when such requests are detected by
devices having vertical allocations utilizing media access slots in
the soft unrestricted region, these devices automatically initiate
a redistribution of their allocations to allow for an adjustment of
the soft threshold and thus an increase in the restricted region.
This typically requires the devices with vertical allocations to
chop up these allocations into multiple separate vertical
allocations as is illustrated by examples described below. In one
embodiment, network devices with the deepest allocations within the
soft unrestricted region are requested to initiate the
redistribution procedure first. Thus, the redistribution procedure
can be done on an iterative basis until the soft threshold is set
so as to accommodate the device requesting the horizontal
reservations.
[0104] As yet another example of the various ways the allocation
can be determined, in one embodiment, devices requesting the soft
unrestricted region for a horizontal allocation are required to
announce the current values of the soft and hard thresholds. This
embodiment may be desirable in that it can reduce the complexity
for low-latency (horizontal) devices to calculate hard and soft
thresholds. These thresholds can be added in the DRP as additional
fields to announce in the beacons.
[0105] To better illustrate dynamic allocation, a few examples are
now described. FIG. 8 is a diagram generally illustrating a portion
of network bandwidth, which, in the example environment, can be
referred to as a superframe 104. Referring now to FIG. 8, the
communication frame includes a beacon 111 and a communication
window having a restricted region 212 and an unrestricted region
214. In the illustrated example there are eight PCA set-asides 222,
each having a vertical allocation of four media access slots,
although this configuration can vary. The example in FIG. 8 also
illustrates the hard threshold 240 and soft threshold 242 both
being set at a default value of seven (i.e., eight media access
slots), evenly splitting restricted region 212 and unrestricted
region 214. In this illustration, the soft unrestricted region is
zero.
[0106] FIG. 8 also illustrates two different classes of devices
requesting an allocation of bandwidth within the illustrated
communication window. Particularly, the example illustrates a first
device (for example, a delay-sensitive device) requesting a
horizontal allocation of bandwidth in the restricted region as
illustrated by shaded region 224. Additionally, the example
illustrates another network device requesting a vertical allocation
of 12 media access slots illustrated by shaded region 226. This
device, for example, can be a power-sensitive device where it is
desirable to allocate its bandwidth in one contiguous block such as
to reduce its power-up time enabling conservation of power.
[0107] In a scenario where the first device is not requesting
bandwidth region 228, there is sufficient room within the
communication window to allow the second device to have a 12-slot
vertical allocation. Thus, in this scenario, the soft threshold can
be changed to 15 (i.e., the hard, unrestricted region and soft
unrestricted region comprise 16 media access slots). However,
because the first device is requesting a horizontal allocation as
illustrated by shaded region 226 and 228, there is a conflict where
both devices are requesting access to the same media access slot.
This is illustrated by shaded region 228. Because of this conflict,
the available bandwidth should be reallocated such as to allow both
devices to perform the desired network activities within the given
communication window.
[0108] As described above, in one embodiment, in one embodiment the
device operating in the restricted region requests its bandwidth
allocation as illustrated in FIG. 8 by shaded region 224 and this
allocation that it requests also includes shaded region 228.
Further following the example set forth above, because the second
device is now aware of the conflict and because it is utilizing
bandwidth within the soft unrestricted region, the second device
begins a redistribution of its slots such that the first device can
be given its horizontal allocation as requested. Of course, as
would be apparent to one of ordinary skill in the art after reading
this description, the priority could be set otherwise.
[0109] One option for redistribution of the vertical allocation is
illustrated in FIG. 9, although other reallocations are possible.
In the illustrated option, the second device reallocates its
bandwidth to zones 06 and 14 wherein each zone has a vertical
allocation of six media access slots. These are illustrated by
shaded portions 226 in FIG. 9. As a result of this reallocation,
there is no longer a conflict between the first and second device
and both devices are given their desired bandwidth allocation. In
this example, however, the device operating in the restricted
region was given priority and is allowed to conduct its network
activities are requested at the expense of the device operating in
the unrestricted region 214. Thus, in this example, the
unrestricted device would now be required to conduct its network
activities in two separate timeframes, potentially requiring
awakening from a power-save mode and additional time. In one
embodiment, the reallocation of bandwidth can be made such that the
reallocated bandwidth pieces are close in time so as to reduce the
wake-up time required for a power-sensitive device.
[0110] To further illustrate the redistribution of the soft
threshold, consider a more congested scenario where several network
devices are operating within both the restricted and unrestricted
regions. Such an example scenario is illustrated in FIG. 10,
although other scenarios are certainly possible. For the purpose of
discussion, consider that the hard and soft thresholds are
initially set at the same level, equally dividing the unrestricted
and restricted regions. Now consider an example scenario wherein a
new device requires a vertical allocation of eight media access
slots as illustrated by shaded regions 322 in FIG. 11. Based on the
network utilization, it is determined that these eight slots can be
allocated in two zones and to accommodate this the soft threshold
242 can be moved such that the soft unrestricted region is two
slots deep as illustrated in FIG. 11. As a result of this
reallocation, the new unrestricted region encompassing the hard
unrestricted region and the soft unrestricted region is now 10
slots deep, the requesting device is provided its allocation of
eight vertical slots in two zones, and the devices utilizing the
horizontal allocation in the restricted region are not impacted by
this change.
[0111] Continuing with the example illustrated FIG. 11, further
consider that a second network device operating in the restricted
region requests a horizontal allocation of 15 media access slots.
As illustrated in FIG. 12, based on the current communication
loading, these horizontal access slots would occupy row 9 as
illustrated by shaded region 334 (and including shaded region 336).
As illustrated, by shaded region 336, the reservation request
conflicts with the first device operating in the vertical mode. In
an example where the horizontal mode has priority, the first device
recognizes the conflict with its current utilization of the soft
unrestricted region, and sets out to reallocate its current
utilization of bandwidth. This reallocation can take place in a
number of different ways based on network availability and one such
example is illustrated in FIG. 13. Referring to FIG. 13, as this
example illustrates, the soft threshold 242 is once again
coincident with hard threshold 240 and the vertical allocations of
the first device illustrated by shaded regions 322 are now split
into three zones, thus allowing the second device its uninterrupted
horizontal allocation as illustrated by shaded region 324.
[0112] As another example, consider the possible scenario
illustrated in FIG. 14, wherein two independent vertical
allocations illustrated by shaded regions 332, 334 are utilizing
the soft unrestricted region, and the soft threshold 242 is set at
10. Now consider an example where a third device needs an
allocation of 31 slots as illustrated in FIG. 15 as shaded region
336 (including shaded region 338). As this example illustrates,
shaded region 338 is at conflict. In an example scenario where the
device operating in the horizontal allocation would have priority,
the first device operating in shaded region 332 would move its
allocation and the soft threshold 242 would be adjusted after the
reallocation. In one example, the table may appear as the example
illustrated in FIG. 16, with the allocation of the first device
split into two zones 332 and the soft threshold adjusted
accordingly.
[0113] Note that in one embodiment, the soft threshold 242 does not
need to be adjusted to ensure that none of the horizontal
allocations are made in the soft unrestricted region. As the
example illustrated in FIG. 16 depicts, there is a vertical
allocation 334 extending into the soft unrestricted region as well
as the horizontal allocation 336, extending into the soft
allocation region. However, because these do not conflict, in one
embodiment, the soft unrestricted region is allowed to remain as
allocated such that the vertical allocation 334 does not need to be
unnecessarily reallocated.
[0114] In yet another embodiment of the invention, the system can
be implemented with the capability to calculate transmitter and
receiver thresholds, including, for example, hard and soft
thresholds. Because a network device may have different
communication requirements relative to the various other network
devices, thresholds for a receiver may be calculated from each of
the receiver's and transmitter's own point of view of the network,
which could be different from one another. Thus, in one embodiment,
each of the receiver and the transmitter can be configured to
determine, for example, the amount by which a given reservation or
group of reservations exceeds a given threshold. In one embodiment,
each of the receiver and the transmitter can be requested to
announce their thresholds during a setup period such as, for
example, the beacon period in the example environment. Thus, as a
result of these announcements, other devices operating in the
network know the status and requirements of the given receiver and
transmitter.
[0115] In one embodiment, a network device having a proper level of
priority, can utilize these numbers to preempt another device where
appropriate. For example, in a network where horizontal allocations
have priority over vertical allocations, a network device
communicating with horizontal allocations can look at vertical
allocations of another device and determine whether a conflict
exists and, if so, preempt the other device from one or more slots
in conflict. As illustrated above, the preemption can take the form
of adjusting the soft threshold such as to decrease the soft
unrestricted region thereby requiring all devices having a vertical
allocation to remain within the reallocated boundaries. In other
embodiments, the preemption can merely require that the offending
device reallocate its requested bandwidth in a manner that does not
conflict with other devices or other higher priority devices.
Although it may be desirable for the preempted develop to
reallocate its bandwidth in the current communication window (for
example, superframe 104 in the example environment), such a
constraint is not always a requirement. Indeed, a preempted device
may be permitted to or may be forced to reallocate a portion of its
desired network activities to subsequent communication windows. As
would be apparent to one of ordinary skill in the art after reading
this description, a number of different preemption mechanisms can
be implemented to achieve the desired goals.
[0116] While various embodiments of the present invention have been
described above, it should be understood that they have been
presented by way of example only, and not of limitation. Thus the
breadth and scope of the present invention should not be limited by
any of the above-described exemplary embodiments, but should be
defined only in accordance with the following claims and their
equivalents. Additionally, the invention is described above in
terms of various exemplary embodiments and implementations. It
should be understood that the various features and functionality
described in one or more of the individual embodiments are not
limited in their applicability to the particular embodiment with
which they are described, but instead can be applied, alone or in
some combination, to one or more of the other embodiments of the
invention, whether or not such embodiments are described and
whether or not such features are presented as being a part of a
described embodiment.
[0117] Terms and phrases used in this document, and variations
thereof, unless otherwise expressly stated, should be construed as
open ended as opposed to limiting. As examples of the foregoing:
the term "including" should be read as mean "including, without
limitation" or the like; the term "example" is used to provide
exemplary instances of the item in discussion, not an exhaustive or
limiting list thereof; and adjectives like "conventional,"
"traditional," "normal," "standard," and terms of similar meaning
should not be construed as limiting the item described to a given
time period or to an item available as of a given time, but instead
should be read to encompass conventional, traditional, normal, or
standard technologies that may be available now or at any time in
the future. Likewise, a group of items linked with the conjunction
"and" should not be read as requiring that each and every one of
those items be present in the grouping, but rather should be read
as "and/or" unless expressly stated otherwise.
* * * * *